8 ms·
How HTTPS Handshake Happens
- mrkurt 9y agoThere 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 session resumption lets clients reuse existing sessions after the first connection. TLS 1.3 has a 0rtt handshake, which is pretty baller. It's just not widely deployed.
- amenghra 9y ago0rtt is only for resuming sessions. I believe the first handshake won't be any faster with 1.3. Still neat.
- colmmacc 9y agoTLS1.3 does speed up non-0RTT handshakes too, at least the ones that use forward secrecy; which is nearly all these days. It reduces them to 1RTT instead of the 2RTT we have today.
- nodesocket 9y agoAny idea when TLS 1.3 will be supported in NGINX? What browsers support it as well?
- a012 9y agoThe problem is not in Nginx part, you must wait for TLS 1.3 implementation in OpenSSL, LibreSSL, etc.
- deleted 9y ago[deleted]
- detaro 9y agoIt already is, if you build 1.13 with the right OpenSSL. https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_... https://github.com/tlswg/tls13-spec/wiki/Implementations https://github.com/tlswg/tls13-spec/wiki/Implementations
- valarauca1 9y agoTLS 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_ approved. Until then nobody smart will touch it. --- 0RTT is only supported by Cloud-Flare and Google. Cloud-Flare makes you track 0RTT yourself so a fair number of sites are insecure. Google does SSL tick synchronization across data centers because their arrogant and is extremely vulnerable to timing att-
- jopsen 9y agoWouldn'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.
- valarauca1 9y agoYou are assuming * The TLS connection is instantly closed after the GET ends * A new 0RTT ticket isn't created * No session information is transmitted (most GET's even have session information for ads/metrics).
- bogomipz 9y ago>"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. Clients have to send 2 packets across the world and wait for a reply, which can add >100ms before any actual work happens." What is a "global load balancer"? A load balancer doesn't avoid any round trips. The "work" of TLS begins as soon as the client sends a ClientHello which is during the second round trip. On a new connection the total round trips is 4 if you include the GET request. It's 3 round trips if you only consider the TCP hand shake and the TLS handshake. This is true whether there is a load balancer or not.
- TheSwordsman 9y agoI 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.
- bogomipz 9y agoSure, 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.
- kelnos 9y agoThe OP didn't claim using a "global" LB would eliminate round-trips, just that you should use one because of the round trips.
- bogomipz 9y agoThe 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.
- mozumder 9y agoIt would be nice if the DNS lookup also provided the certificate for the site.
- raimue 9y agoThis is possible with TLSA records as specified by DANE.
- cabaalis 9y agoGenuinely curious, as HTTPS is something I do not fully understand even with this simplification: If the browser's symmetric key is encrypted with icicibank's public key, why can't a sniffer unlock it by also requesting icicibank's public key and decrypting the key sharing message?
- lmz 9y agoOnly the private key can decrypt it. This is the difference between asymmetric and symmetric encryption algorithms.
- usmannk 9y agoThe payload is encrypted with the bank's public key but it can only be decrypted with their private key. This is the basis of public key cryptography [1]. [1] https://en.wikipedia.org/wiki/Public-key_cryptography https://en.wikipedia.org/wiki/Public-key_cryptography
- schoen 9y agoIt's quite counterintuitive that this is possible at all. We didn't even know a way to make it work until the 1970s!
- theEXTORTCIST 9y agoWhen talking HTTPS it's important to note that the protocol uses both asymmetric and symmetric key encryption. Asymmetric key exchange for secure session setup / authentication Symmetric key for secure session data encryption https://tools.ietf.org/html/rfc4346#section-1 https://tools.ietf.org/html/rfc4346#section-1
- nitinreddy88 9y agoyou can encrypt with public key, but it cant be decrypted with same key. its assymetric encryption.
- valarauca1 9y agoPublic Key encryption is like a bank deposit box. Anyone can encryption (put things in), but only the Private Key (the bankers) can decrypt (see whats inside).
- calebbrown 9y agoDoesn't cover perfect forward secrecy (PFS). Without PFS if the server's private key was stolen (e.g. by hacking the server) then all traffic sniffed in the past could be decrypted. See: https://en.wikipedia.org/wiki/Forward_secrecy https://en.wikipedia.org/wiki/Forward_secrecy
- nishs 9y agoCan someone explain what "any of my trusted keys" in the graphic is referring to? (on the browser)
- btmiller 9y agoCertificate authorities. Think VeriSign, InCommon, Let's Encrypt, etc. The folks that we generally implicitly trust to authenticate popular websites. Your laptop comes distributed with many certificate authorities that are configured to be trusted by default.
- sdevlin 9y agoIt's impossible to bootstrap a secure connection without some preexisting trusted relationship. Otherwise, you'd always be vulnerable to middle-person attacks. Browsers solve this problem by bundling a number of trusted root certificates. (This is what they mean by "my trusted keys".) When you connect to some web site, the server sends you their certificate along with a chain of signing certificates up to some root of trust. Assuming the root certificate is among those your browser trusts, you can verify the signature chain and establish a trusted connection.
- prdonahue 9y agoThe word "unlock" here is a misnomer. Would have been better to say something like "let me see if I can match the signature to any known signatures I have on file".
- had2makeanacct 9y agohttp://sudhakar.online/visualization/2011/10/11/wedding-invite.html http://sudhakar.online/visualization/2011/10/11/wedding-invi... Found this on this site, parallax.js wedding invitation. This is cool, how hard is it to learn how to do this?
- usaphp 9y agoPretty simple actually, you have 3 images stacked on top of each other, then you track mouse movement and change absolute position of those images in relation to each other depending on mouse movement. p.s. In this example they are changing margins and top/bottom/left/right positions, which is not really a good way to do it, a better way to it is using transform: translate(), it's less resource intensive and especially when you use translate3d. You can read more about the performance difference between using top/left/bottom/right and translate() : https://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/ https://www.paulirish.com/2012/why-moving-elements-with-tran...
- apathetic 9y agoCurious how you ended up asking on this thread.
- uhhfcuvv 9y agoIf you read his past comments, he's either 15, Indian, or both.
- had2makeanacct 9y agoSo fucking what. I can't ask questions?
- lowleveldesign 9y agoIf 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 interesting scripts (the chapter on using OpenSSL and creating your own PKI is available for free: https://www.feistyduck.com/books/openssl-cookbook/ https://www.feistyduck.com/books/openssl-cookbook/). I spent some time studying TLS and wrote two blog posts [3][4], in which I decrypt the network traces of the TLS sessions. Maybe someone will find them interesting too. [1] https://www.amazon.com/Implementing-SSL-TLS-Using-Cryptography/dp/0470920416 https://www.amazon.com/Implementing-SSL-TLS-Using-Cryptograp... [2] https://www.amazon.com/gp/product/1907117040 https://www.amazon.com/gp/product/1907117040 [3] https://lowleveldesign.org/2016/03/09/manually-decrypting-https-request/ https://lowleveldesign.org/2016/03/09/manually-decrypting-ht... [4] https://lowleveldesign.org/2016/05/10/tls-1-2-aes-gcm-and-net-network-trace/ https://lowleveldesign.org/2016/05/10/tls-1-2-aes-gcm-and-ne...
- dotancohen 9y agoI 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.
- lowleveldesign 9y agoI'm also against home-brew crypto, but the author clearly states that what he presents has only educational purpose. It's a bit like cryptopals - you also implement your own crypto in order to learn something.
- farax91 9y agoI don't think that's the point of the book. There is enormous benefit that can be gleaned from building a "workable" implementation from first principles, even if it's not actually production "workable". These types of books are rare and very challenging to write, will definitely be taking a look.
- crisp 9y agoLittle ironic the blog isn't under a valid SSL cert
- chr1sto14 9y agoYes! The blogger knows the theory, but not how to apply it.
- beefhash 9y agoIf you actually look at the details, that seems to be related to the blog being hosted on GitHub Pages. GitHub Pages does not support TLS for custom domains. See also: https://gist.github.com/coolaj86/e07d42f5961c68fc1fc8 https://gist.github.com/coolaj86/e07d42f5961c68fc1fc8 ("Please petition Github to support HTTPS on github pages") and comments
- skyisblue 9y agoEven 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?
- dfischer 9y agoCross region load balance is probably only thing, although I understand you've asked for far distance.
- 3pt14159 9y agoUnder 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.
- ivanr 9y agoAs 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 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.
- hueving 9y agoNote 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.
- ivanr 9y agoRight. 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).
- prashantswain 9y agoIf 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
- BrandoElFollito 9y agoI did not see it in the comments, so here is a great article on how the handshake happens : http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html http://www.moserware.com/2009/06/first-few-milliseconds-of-h...
- the_arun 9y agoSimilar articles for reference: 1. https://www.ssl.com/article/ssl-tls-handshake-overview/ https://www.ssl.com/article/ssl-tls-handshake-overview/ 2. https://msdn.microsoft.com/en-us/library/windows/desktop/aa380513(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... 3. https://hpbn.co/transport-layer-security-tls/ https://hpbn.co/transport-layer-security-tls/ Also note the delay created by each step in (3).