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

71–80 of 96 posts

Re: How HTTPS Handshake Happens

#71

Post by tptacek »

kasey_junk wrote: post #69
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.

> 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"?

I thought about that when I wrote that comment and my conclusion is, no: distributed systems protocols are notoriously hard, but they don't have adversaries. Crypto protocol flaws are marginally more complicated than distributed systems flaws, but also, a distributed system with a byzantine fault can be survivable, and a cryptosystem with a subtle flaw won't be.

Re: How HTTPS Handshake Happens

#72

Post by kasey_junk »

tptacek wrote: post #71
kasey_junk wrote: post #69

Earlier quoted context omitted.

> 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"?

I thought about that when I wrote that comment and my conclusion is, no: distributed systems protocols are notoriously hard, but they don't have adversaries . Crypto protocol flaws are marginally more complicated than distributed systems flaws, but also, a distributed system with a byzantine fault can be survivable, and a cryptosystem with a subtle flaw won't be.

I'd buy that having adversaries is what makes crypto different than other topics. Thats probably a better way to pitch your message as well.

Re: How HTTPS Handshake Happens

#73

Post by britcruise »

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…

Hey Ivan, thanks for sharing my video :)

Re: How HTTPS Handshake Happens

#74

Post by uhhfcuvv »

apathetic wrote: post #33
had2makeanacct wrote: post #23

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?

Curious how you ended up asking on this thread.

If you read his past comments, he's either 15, Indian, or both.

Re: How HTTPS Handshake Happens

#75

Post by schoen »

MyDogHasFleas wrote: post #55
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.

I have yet to buy it, but I've recommended it to five or six people who said they wanted to understand TLS, because I've never heard of someone being disappointed by it!

I think I'll buy my own copy today. :-)

Re: How HTTPS Handshake Happens

#76

Post by schoen »

ivanr wrote: post #70
Xeoncross wrote: post #68

Earlier quoted context omitted.

> 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, t…

As someone who's help create a certificate authority and helps people get certificates from it every day, I'm kind of amazed at how few people who are getting certificates know what they're for or could explain what they do, even at the level of "certificates protect site visitors against man-in-the-middle attacks". (Or even know that they possess private keys, which they've promised in their subscriber agreements to safeguard.)

Re: How HTTPS Handshake Happens

#77

Post by schoen »

snakeanus wrote: post #35
dotancohen wrote: post #27

Earlier quoted context omitted.

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.

It's not "home-brew crypto" if it is a well established protocol.

Nonetheless, even an implementation of a well-established protocol could have problems like a timing attack or an oracle attack, so it's worth being extremely careful.

Re: How HTTPS Handshake Happens

#78

Post by schoen »

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…

Can you suggest any compelling resource to encourage people to switch away from RSA key exchanges in their server configurations, assuming that they're not asking us? (When people ask me, I point them to the Mozilla configuration generator at https://mozilla.github.io/server-side-tls/ssl-config-generat...)

I just noticed two days ago that my bank, for example, uses an RSA key exchange and I was kind of dismayed about the non-forward-secret sessions. But I don't know what I could tell them as a customer that would make them care about this problem. (I don't think my theoretical knowledge of why their key exchange method is bad will really help, compared to some kind of industry or governmental guidance that says "this technology is obsolete and everyone should stop using it", or, even better, "this technology is obsolete and banks should stop using it".)

Re: How HTTPS Handshake Happens

#80

Post by mrkurt »

bogomipz wrote: post #61
mrkurt wrote: post #59

Earlier quoted context omitted.

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.

There are a bunch of relatively pure global load balancer services available out there. Google Cloud's load balancer, for example. It works pretty well to terminate SSL close to visitors then maintain connections from load balancers back to app instances.
Post reply on HN