Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How HTTPS Handshake Happens

sudhakar.online

Post reply on HN
Print view View original

51–60 of 96 posts

Re: How HTTPS Handshake Happens

#51

Post by hueving »

3pt14159 wrote: post #46
skyisblue wrote: post #41

Even with TLS 1.3 the fastest handshake for an initial connection is one round trip. That's around 250ms for someone connecting to a server in New York from Sydney Australia. Is there any other way to reduce this handshake time for visitors located geographically far from the server with end to end encryption?

Under what circumstances would the initial connection need to be faster than 250ms for arbitrary HTTPS access? I can think of maybe it mattering to people that work with financial data, but outside of that I can't really see it mattering.

Loading a bunch of assets from different servers in a serial or semi-serial (e.g. 6 at a time) gets really impacted by that.

Re: How HTTPS Handshake Happens

#52

Post by prashantswain »

If you seek legitimate hacking service ,contact hdmoore.hacks@gmail.com ...dude's a cyber guru, involved with cloning phones, hacked into my ex's gmail and facbook, what let me knowing she was infidel and also gave my nephew some really outstanding school scores which he upgraded himself, cool way to have financial freedom as well. Get your bank blank atm cards which could debit money from any a.t.m machine. Make $20,000 and more in a couple days. Bank transfers and wire transfers as well as Paypal jobs, hes that good, had to make him my personal hacker. You could mail him as well if you got issues, he's as discreet and professional too. He's kinda picky though so make mention of the reference

Re: How HTTPS Handshake Happens

#53

Post by ivanr »

hueving wrote: post #49
ivanr wrote: post #47

As others have already pointed out, this explanation focuses on the RSA key exchange, which has been deprecated. It's not recommended for use with the current line of protocols (TLS 1.2 and earlier) and it's been completely removed from TLS 1.3 (work in progress, but close to being finished). The key weakness of the RSA key exchange is that session encryption keys are transported over the network encrypted with the s…

Note that in most browser to web server communications that both sides don't usually sign the conversation during authentication, only the server does. This means the client knows it's the right server but the server doesn't know who the client is, which is why you have to use a username/password in some crappy web form for authentication.

Right. As you say, on most web sites the client is anonymous as far as TLS is concerned, and the server proves its right to respond to the requested hostname with a CA-backed certificate (and proof that it holds the private key that corresponds to the public key embedded in the certificate).

To drill deeper in the the handshake, however, both client and server do sign the initial handshake (with the final negotiated session secret, effectively). The idea is that you need to ensure that the handshake hasn't been tampered with. An active network attacker could have changed the original TLS connection request (ClientHello) to force usage of a particular cryptographic component they know how to break. For example, SSL v2 had no handshake protection which is why someone in control of the network could always enforce the weakest encryption (only 40 bits).

Re: How HTTPS Handshake Happens

#54

Post by GRiMe2D »

hueving wrote: post #51
3pt14159 wrote: post #46

Earlier quoted context omitted.

Under what circumstances would the initial connection need to be faster than 250ms for arbitrary HTTPS access? I can think of maybe it mattering to people that work with financial data, but outside of that I can't really see it mattering.

Loading a bunch of assets from different servers in a serial or semi-serial (e.g. 6 at a time) gets really impacted by that.

Loading bunch of assets from different servers to enter a site is a very bad idea.

Re: How HTTPS Handshake Happens

#55

Post by MyDogHasFleas »

ivanr wrote: post #47

As others have already pointed out, this explanation focuses on the RSA key exchange, which has been deprecated. It's not recommended for use with the current line of protocols (TLS 1.2 and earlier) and it's been completely removed from TLS 1.3 (work in progress, but close to being finished). The key weakness of the RSA key exchange is that session encryption keys are transported over the network encrypted with the s…

Ivan, I bought your book "Bulletproof SSL and TLS". It's excellent, and I recommend it to those who are charged with building, deploying, or managing a real world deployment that includes TLS.

Re: How HTTPS Handshake Happens

#57

Post by bengale »

ivanr wrote: post #47

As others have already pointed out, this explanation focuses on the RSA key exchange, which has been deprecated. It's not recommended for use with the current line of protocols (TLS 1.2 and earlier) and it's been completely removed from TLS 1.3 (work in progress, but close to being finished). The key weakness of the RSA key exchange is that session encryption keys are transported over the network encrypted with the s…

Would you recommend your book for someone with a rough understanding of how this works, but very light on detail?

Re: How HTTPS Handshake Happens

#58

Post by bogomipz »

kelnos wrote: post #40
bogomipz wrote: post #21

Earlier quoted context omitted.

Sure, you can reduce the RTT by moving the edge closer to the eyeballs but that's not the same as avoiding an RTT as the OP stated. That's what all I was commenting on. There are mechanisms however to do that such as sessions tickets/resumption but that's not something specific to load balancers.

The OP didn't claim using a "global" LB would eliminate round-trips, just that you should use one because of the round trips.

The OP stated:

>"There are some really cool "tricks" for avoiding the round trip — round trips are why everyone should be using a global load balancer for SSL."

"Avoiding" means not incurring them, so yes they did claim a "global" LB would eliminate round trips.

Re: How HTTPS Handshake Happens

#59

Post by mrkurt »

bogomipz wrote: post #58
kelnos wrote: post #40

Earlier quoted context omitted.

The OP didn't claim using a "global" LB would eliminate round-trips, just that you should use one because of the round trips.

The OP stated: >"There are some really cool "tricks" for avoiding the round trip — round trips are why everyone should be using a global load balancer for SSL." "Avoiding" means not incurring them, so yes they did claim a "global" LB would eliminate round trips.

That actually wasn't what I meant to claim, but it's too late to edit! It was an awkward sentence for sure.

The simpler sentence is: minimize round trip cost by getting close to users. Also avoid round trips if you can. :)

Re: How HTTPS Handshake Happens

#60

Post by [deleted] »

hueving wrote: post #50
bogomipz wrote: post #21

Earlier quoted context omitted.

Sure, you can reduce the RTT by moving the edge closer to the eyeballs but that's not the same as avoiding an RTT as the OP stated. That's what all I was commenting on. There are mechanisms however to do that such as sessions tickets/resumption but that's not something specific to load balancers.

You avoid an RTT to the web server by having TLS terminate in the load balancer.

[deleted]
Post reply on HN