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?
How HTTPS Handshake Happens
41–50 of 96 posts
Re: How HTTPS Handshake Happens
#42Even 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?
Cross region load balance is probably only thing, although I understand you've asked for far distance.
Re: How HTTPS Handshake Happens
#43If you are interested in details of the TLS protocol, check out these two books: - Implementing SSL / TLS Using Cryptography and PKI [1] - Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications [2] In the first one the author implements the protocol (RSA/DH) from scratch (without even using any crypto library). The second one is a classic and contains a lot of inte…
Thank you so much for those book suggestions. They will either be exactly what I wanted to know or a great reference down the road.
Re: How HTTPS Handshake Happens
#44If you are interested in details of the TLS protocol, check out these two books: - Implementing SSL / TLS Using Cryptography and PKI [1] - Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications [2] In the first one the author implements the protocol (RSA/DH) from scratch (without even using any crypto library). The second one is a classic and contains a lot of inte…
I haven't read the books, and I'm sure that they are fascinating, but I am wary of any attempt to home-brew crypto. I'm specifically worried that some corner-cutters might use the Implementing SSL book's code or ideas in production.
So a book that teaches a programming language with a "toy" software project does more harm than good? This is industry standard stuff.
Re: How HTTPS Handshake Happens
#45Earlier quoted context omitted.
What's the alternative, lock all books related to cryptography lest someone might do something in production? Educating is fine, and people reading relatively advanced technical books like this one should be considered as responsible, I think.
Not only reasonable, but it is a must. I think the "don't roll your own crypto" phrase is widely misunderstood. A better phrase would be - learn as much about crypto as you possibly can, to clearly understand why it is a bad idea to roll your own in production. This also means that after you learn it, you will have a much better idea which library, cypher or mode to pick for a particular task, and not just think "oh,…
People who are wanting to get into complex cryptography today have to start somewhere. Showing working models, with huge disclaimers, in blog posts and on github is a great way to lean, if you invite others to show you flaws and break your implementation.
Re: How HTTPS Handshake Happens
#46Even 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.
Re: How HTTPS Handshake Happens
#47As 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 server's public key. When the server's private key is compromised in some way, the attacker can passively decrypt all traffic, they can also "go back in time" to decrypt all previous conversations they might have recorded and kept.
For a more secure handshake approach, consider the Diffie-Hellman key exchange, which is a way for two parties to agree on a secret number (a very large number when used for encryption, of course) that third party can't discover from looking at the network traffic. It's a very simple and intuitive algorithm; there's a great video that explains it here: https://www.youtube.com/watch?v=YEBfamv-_do Today, we generally use the ephemeral elliptic curve DH variant (ECDHE), which has better security characteristics and works much faster.
However, DH is not sufficient, you must also authenticate the other party. Otherwise you could be negotiating your key exchange with the attacker and not the real recipient. This is where public cryptography comes in. After the key exchange, both parties use their private keys to sign the transcripts of the entire conversation up until that point. When this is verified you know that (1) you're talking to the right person and (2) that you have a secret (session keys) that you can use to efficiently protect the conversation.
Disclosure: I am the author of Bulletproof SSL and TLS, already mentioned in another comment here. Feel free to ask me anything.
Re: How HTTPS Handshake Happens
#48There are some really cool "tricks" for avoiding the round trip — round trips are why everyone should be using a global load balancer for SSL. Clients have to send 2 packets across the world and wait for a reply, which can add >100ms before any actual work happens. http2 helps because you can multiplex a bunch of requests into a single connection, less waiting on new connections to be established. TLS 1.2 with sessio…
TLS 1.3 has a 0rtt handshake, which is pretty baller. It's just not widely deployed. And it likely won't be. 0RTT Allows for replay attacks (I capture your packets, and replay them). Without a round trip this will always exist. Also 0RTT is only for re-connections not initial connections. The solution is only like 0RTT be executed once and only once, but this isn't part of TLSv1.3 and is waiting to _globally_ approve…
Wouldn't 0RTT be safe for GET requests that doesn't contain cookies or private data?
Granted I suppose such interpretation would have to be done by browsers.
And even then it could be used to figure out which site you are visiting.
Re: How HTTPS Handshake Happens
#49As 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.
Re: How HTTPS Handshake Happens
#50Earlier quoted context omitted.
I assume a load balancing / caching solution that is available on an anycast IP address. The TLS termination happens at the (ideally) closest point of presence (PoP). The idea is to reduce the RTT from client to its termination point. Think CloudFlare CDN or the Google Cloud Load Balancer. Edit Mistyped RTT as TTL.
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.