6 ms·

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 l

by ivanr 9y ago

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 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 ago
Note 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 ago
  Right. 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).
MyDogHasFleas 9y ago
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.
- schoen 9y ago
  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. :-)
  - schoen 9y ago
    As an update, I've ordered a copy and look forward to reading it.
bengale 9y ago
Would you recommend your book for someone with a rough understanding of how this works, but very light on detail?
- ivanr 9y ago
  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/ 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 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.
Xeoncross 9y ago
> 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?
- ivanr 9y ago
  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.
  - schoen 9y ago
    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.)
britcruise 9y ago
Hey Ivan, thanks for sharing my video :)
- ivanr 9y ago
  Hey, thanks for creating it. It's fantastic!
schoen 9y ago
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-generator/. 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".)
- ivanr 9y ago
  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.
  - schoen 9y ago
    > 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-requests-2015 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.
novaleaf 9y ago
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 :)
- ivanr 9y ago
  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.
  - novaleaf 9y ago
    thanks, i don't want to eavesdrop, but looking for technical docs on how a https proxy server really works :) .. something i can use to learn how to implement one.
WhiteSource1 9y ago
How much lag and delays do SSL handshakes take and what are some ways to remain secure while minimising latency.
- ivanr 9y ago
  Technically, a full handshake adds 2 RTTs, and it's only one RTT on a successful resumption. In practice, I think that most modern browsers currently use something called False Start, where they cheat and send some data early, so even the full handshake takes only one RTT. False Start works only with a well-configured server. In TLS 1.3, the full handshake is one RTT without any tricks; resumption also. There is also a 0-RTT resumption, but it sacrifices security for speed. Lots of people are unhappy about it.

by ivanr 9y ago

hueving 9y ago

Note 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 ago
Right. 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).

MyDogHasFleas 9y ago

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.

schoen 9y ago
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. :-)
- schoen 9y ago
  As an update, I've ordered a copy and look forward to reading it.

bengale 9y ago

Would you recommend your book for someone with a rough understanding of how this works, but very light on detail?

ivanr 9y ago
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/ 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 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.

Xeoncross 9y ago

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

ivanr 9y ago
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.
- schoen 9y ago
  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.)

britcruise 9y ago

Hey Ivan, thanks for sharing my video :)

ivanr 9y ago
Hey, thanks for creating it. It's fantastic!

schoen 9y ago

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-generator/. 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".)

ivanr 9y ago
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.
- schoen 9y ago
  > 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-requests-2015 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.

novaleaf 9y ago

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

ivanr 9y ago
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.
- novaleaf 9y ago
  thanks, i don't want to eavesdrop, but looking for technical docs on how a https proxy server really works :) .. something i can use to learn how to implement one.

WhiteSource1 9y ago

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

ivanr 9y ago
Technically, a full handshake adds 2 RTTs, and it's only one RTT on a successful resumption. In practice, I think that most modern browsers currently use something called False Start, where they cheat and send some data early, so even the full handshake takes only one RTT. False Start works only with a well-configured server. In TLS 1.3, the full handshake is one RTT without any tricks; resumption also. There is also a 0-RTT resumption, but it sacrifices security for speed. Lots of people are unhappy about it.