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

61–70 of 96 posts

Re: How HTTPS Handshake Happens

#61

Post by bogomipz »

mrkurt wrote: post #59
bogomipz wrote: post #58

Earlier quoted context omitted.

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. :)

If you are terminating TLS on an edge network then you are likely caching the content there as well so as not to incur the latency in fetching it from origin. This is called a CDN not a load balancer.

Re: How HTTPS Handshake Happens

#62

Post by ivanr »

bengale wrote: post #57
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?

In short, yes! But just to be 100% sure, I would encourage you to read the detailed table of contents (it's can be downloaded along the free first chapter from the book's homepage, in the right column: https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ ).

One important point I would make is that my book doesn't dissect the protocols in detail. There is only one chapter (about 50 pages) dedicated to the protocol and I wanted to cover it at a level that virtually everyone will want to understand. If you want more than that, hundreds of pages won't be enough; in the end you will have to dive into the dozens of RFCs, and so on. What I do do, is point to those RFCs so that you at least know where to find the additional documentation. IIRC there are more than 600 links in the book and they can all be found here (automatically extracted from the DocBook XML manuscript): https://fsty.uk/bulletproof-ssl-and-tls

My realisation was that, in practice, actual protocol flaws are not the weakest link. Instead, there are hundreds of different problems everywhere in the ecosystem, so you need to look at the issues in the protocol, but also in the certification authorities and the certificate issuance process, SSL/TLS stacks, clients, browsers, servers, libraries, development and configuration practices, and so on. My book is thus very practical and examines all these aspects that you need to understand at at least some level if you want to use TLS.

BTW, please note that I will send you a free digital copy of the book if you buy the paperback _anywhere_ and send me the receipt. The benefit of the digital edition is that it's typically much more current than the paperback. In fact, the digital edition is fully up to date at the moment. I published a complete revision just yesterday.

Re: How HTTPS Handshake Happens

#63

Post by beefhash »

crisp wrote: post #37

Little ironic the blog isn't under a valid SSL cert

If 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 ("Please petition Github to support HTTPS on github pages") and comments

Re: How HTTPS Handshake Happens

#64

Post by tptacek »

djsumdog wrote: post #45
pampa wrote: post #32

Earlier quoted context omitted.

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.

If you want to build complex cryptography, you must either obtain formal training, or learn how to break complex cryptography.

What you can't do is read a book or two about cryptography, the way you would a new programming language, and then bootstrap your own expertise from that. Cryptography is a lot trickier than most other topics in computer science.

Re: How HTTPS Handshake Happens

#65

Post by Kubuxu »

tptacek wrote: post #64
djsumdog wrote: post #45

Earlier quoted context omitted.

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.

If you want to build complex cryptography, you must either obtain formal training, or learn how to break complex cryptography. What you can't do is read a book or two about cryptography, the way you would a new programming language, and then bootstrap your own expertise from that. Cryptography is a lot trickier than most other topics in computer science.

There is enormous difference between rolling your own crypto primitives and using existing primitives to create a protocol.

Re: How HTTPS Handshake Happens

#66

Post by raimue »

mozumder wrote: post #39
mrkurt wrote: post #2

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. 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…

It would be nice if the DNS lookup also provided the certificate for the site.

This is possible with TLSA records as specified by DANE.

Re: How HTTPS Handshake Happens

#67

Post by tptacek »

Kubuxu wrote: post #65
tptacek wrote: post #64

Earlier quoted context omitted.

If you want to build complex cryptography, you must either obtain formal training, or learn how to break complex cryptography. What you can't do is read a book or two about cryptography, the way you would a new programming language, and then bootstrap your own expertise from that. Cryptography is a lot trickier than most other topics in computer science.

There is enormous difference between rolling your own crypto primitives and using existing primitives to create a protocol.

No, there isn't. Most crypto vulnerabilities happen in the joinery between primitives. If you rolled your own block cipher, it's less likely that the cipher would be broken than that your protocol would be broken with a vulnerability that would apply equally well to AES.

Obviously, don't make your own block cipher, either.

Re: How HTTPS Handshake Happens

#68

Post by Xeoncross »

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…

> After the key exchange, both parties use their private keys to sign the transcripts of the entire conversation up until that point.

I don't see how this proves anything as a MITM attack would be able to do this just fine. Perhaps you mean this is where the CA-Cert comes in as the client can then verify that the process has not be tampered as the attacker can not sign with the matching CA-cert?

Re: How HTTPS Handshake Happens

#69

Post by kasey_junk »

tptacek wrote: post #64
djsumdog wrote: post #45

Earlier quoted context omitted.

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.

If you want to build complex cryptography, you must either obtain formal training, or learn how to break complex cryptography. What you can't do is read a book or two about cryptography, the way you would a new programming language, and then bootstrap your own expertise from that. Cryptography is a lot trickier than most other topics in computer science.

> Cryptography is a lot trickier than most other topics in computer science.

Is that actually true? Or is it that most software development isn't really about topics in computer science. Like if you wanted to design your own distributed database wouldn't most of what you said above also apply?

Isn't this really a case where "hard topic is hard"?

Re: How HTTPS Handshake Happens

#70

Post by ivanr »

Xeoncross wrote: post #68
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…

> After the key exchange, both parties use their private keys to sign the transcripts of the entire conversation up until that point. I don't see how this proves anything as a MITM attack would be able to do this just fine. Perhaps you mean this is where the CA-Cert comes in as the client can then verify that the process has not be tampered as the attacker can not sign with the matching CA-cert?

No, the attacker can't sign anything using either client's or server's private keys. The process assumes these keys haven't been compromised. But, as a client, you do need to be able to reliably verify that the private key used for the signing genuinely belongs to the server. That's where certificates come in. In the certificate there is a public key. The server has a matching private key. As part of the handshake, the client verifies that the two match. That's why the MITM can't interfere.

But that's only where the chain of trust begins. As the next step, the client must now verify that the certificate had been issued by a CA they trust, and they do that by recursively verifying the signature of each issuer in the certificate chain (along a few other things) until they reach a CA that's trusted by default (because it's in the client's root store).

Just to complicate things further: TLS 1.2 and earlier support many key exchange options, which implement key agreement and authentication in potentially different ways. For example, some key exchanges don't use certificates but rely on pre-shared keys. Another example, in the RSA key exchange the server proves ownership of the private key by being able to successfully handshake, and so on. TLS 1.3 made some improvements in this area and the key exchange process has been streamlined. My point here is that there are many other details to take into account, but I am trying to keep my explanations at a higher level.

Post reply on HN