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

81–90 of 96 posts

Re: How HTTPS Handshake Happens

#81

Post by novaleaf »

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…

curious, do you know where I can find out how proxy servers negotiate/relay SSL without eavesdropping? I'm trying to figure out how secure proxies communicate but can't find details :)

Re: How HTTPS Handshake Happens

#82

Post by ivanr »

schoen wrote: post #78
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 abou…

I think SSL Labs could be an option, but its penalty for configurations that don't support forward secrecy is not strong enough. That's my fault (sorry!), but I'll hopefully fix it soon.

Ultimately, I think the only way to kill the RSA key exchange is via a protocol revision, which is exactly what they've done in TLS 1.3. Sure, it will take a few years, but it will happen eventually.

I think banks like the RSA key exchange because it allows them to deploy transparent TLS traffic decryption via private key sharing.

Re: How HTTPS Handshake Happens

#83

Post by ivanr »

novaleaf wrote: post #81
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…

curious, do you know where I can find out how proxy servers negotiate/relay SSL without eavesdropping? I'm trying to figure out how secure proxies communicate but can't find details :)

Well, the default is that TLS traffic cannot be decrypted or interfered with without detection, so no eavesdropping. A proxy can relay traffic at the TCP layer, but it won't be able to see any of the information (except for the parts that are not encrypted).

If you do want to eavesdrop, you have several options. For one, you can terminate the TLS traffic, access it, then create another entirely separate TLS session to send it elsewhere. This is easier with a reverse proxy, in which case the proxy is the server. If you want to transparently intercept client-initiated sessions you have to install your root CA key in each client device.

Going back to servers, another option is private RSA key sharing, which allows for passive decryption, but works only with the RSA key exchange. Finally, you can also play with session ticket keys. If you share those, and enable session tickets, you'll also be able to passively decrypt. This last option works even with DHE/ECDHE key exchanges.

Re: How HTTPS Handshake Happens

#84

Post by schoen »

ivanr wrote: post #82
schoen wrote: post #78

Earlier quoted context omitted.

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

I think SSL Labs could be an option, but its penalty for configurations that don't support forward secrecy is not strong enough. That's my fault (sorry!), but I'll hopefully fix it soon. Ultimately, I think the only way to kill the RSA key exchange is via a protocol revision, which is exactly what they've done in TLS 1.3. Sure, it will take a few years, but it will happen eventually. I think banks like the RSA key ex…

> I think SSL Labs could be an option, but its penalty for configurations that don't support forward secrecy is not strong enough.

It's amazing how strong a motivation a grade or ranking can sometimes be. We saw this a lot with EFF's privacy practices report

https://www.eff.org/who-has-your-back-government-data-reques...

where companies were sometimes willing to make real changes to earn an extra star.

> I think banks like the RSA key exchange because it allows them to deploy transparent TLS traffic decryption via private key sharing.

Oh yeah, that was something they complained about a lot with mandatory PFS in the TLSWG. :-(

Why do they need this for their consumer-facing sites, though? The theory over in the working group was about monitoring activities of bank employees on third-party web sites (I thought), rather than about monitoring activities of bank customers on the bank's own web site.

Re: How HTTPS Handshake Happens

#85

Post by thr0w__4w4y »

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…

Ivan - I have your book, I've read it (at least a year ago, if not more) - so sorry if this is covered and/or I should know the answers, but:

(1) Seems like the argument against RSA is "what happens when the server's private key is leaked?" But with ephemeral DH, it also requires private keys to be protected (now 2 of them!), these being signing keys. So isn't it simply trading one problem for another? Or perhaps the difference is that at least with DH, in theory only /new/ sessions can be attacked (MitM impersonating going forward), but older sessions can't be opened up.

(2) Doesn't this mean that now the client needs a keypair & certificate? Otherwise, how does the client sign? And where does the client key pair come from? I'm pretty sure my browsers (i.e., clients) don't have their own keys & certificates.

TIA for answering my silly questions.

Re: How HTTPS Handshake Happens

#86

Post by schoen »

schoen wrote: post #75
MyDogHasFleas wrote: post #55

Earlier quoted context omitted.

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

As an update, I've ordered a copy and look forward to reading it.

Re: How HTTPS Handshake Happens

#88

Post by ivanr »

thr0w__4w4y wrote: post #85
ivanr wrote: post #70

Earlier quoted context omitted.

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…

Ivan - I have your book, I've read it (at least a year ago, if not more) - so sorry if this is covered and/or I should know the answers, but: (1) Seems like the argument against RSA is "what happens when the server's private key is leaked?" But with ephemeral DH, it also requires private keys to be protected (now 2 of them!), these being signing keys. So isn't it simply trading one problem for another? Or perhaps the…

(1) Yes, that's the argument against the RSA key exchange. I can break into your server, bribe or blackmail your system administrators, or take you to court to get your private key. This last case happened to Lavabit, for example.

Handshake integrity validation is always done, no matter which key exchange is used, and with effectively throw-away keys. So there's nothing there to protect long-term; those keys are going to disappear after the TLS session is complete.

The key difference with the RSA key exchange is that it forever leaves behind a piece of data encrypted with the private key (that can be recovered). Other key exchange methods use signatures, which have no value once the TLS session is complete.

(2) Public cryptography is not well suited for dealing with high volumes of data. Abstracting a little bit, handshake integrity is done via a HMAC, using keys that are negotiated for each session separately. Once the session is complete, these keys also disappear.

Re: How HTTPS Handshake Happens

#89

Post by WhiteSource1 »

bogomipz wrote: post #15
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…

>"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 whi…

Why a load balancer and not a CDN? A CDN can definitely help.

Here's a good guide to an SSL handshake: https://www.incapsula.com/cdn-guide/cdn-and-ssl-tls.html#ssl...

The handshake adds 2+ additional round trips, so a CDN can definitely help this.

Re: How HTTPS Handshake Happens

#90

Post by WhiteSource1 »

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…

How much lag and delays do SSL handshakes take and what are some ways to remain secure while minimising latency.
Post reply on HN