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

31–40 of 96 posts

Re: How HTTPS Handshake Happens

#31

Post by marklgr »

dotancohen wrote: post #27
lowleveldesign wrote: post #26

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

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.

Re: How HTTPS Handshake Happens

#32

Post by pampa »

marklgr wrote: post #31
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.

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, crypto is complicated, i will just wrap everything in TLS and won't bother to check the certs"

Re: How HTTPS Handshake Happens

#34

Post by colmmacc »

amenghra wrote: post #3
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…

0rtt is only for resuming sessions. I believe the first handshake won't be any faster with 1.3. Still neat.

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

Re: How HTTPS Handshake Happens

#35

Post by snakeanus »

dotancohen wrote: post #27
lowleveldesign wrote: post #26

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

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

Re: How HTTPS Handshake Happens

#36

Post by prdonahue »

nishs wrote: post #17

Can someone explain what "any of my trusted keys" in the graphic is referring to? (on the browser)

The 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".

Re: How HTTPS Handshake Happens

#38

Post by theEXTORTCIST »

usmannk wrote: post #8
cabaalis wrote: post #5

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

The 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

When 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

Re: How HTTPS Handshake Happens

#39

Post by mozumder »

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.

Re: How HTTPS Handshake Happens

#40

Post by kelnos »

bogomipz wrote: post #21
TheSwordsman wrote: post #16

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

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