8 ms·

More Privacy, Less Latency – Improved Handshakes in TLS v1.3

81 points by ttaubert 11y ago

kardos 11y ago
Regarding more privacy: have they found a way to keep the SNI information private?
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- praseodym 11y ago
  SNI is the "server_name" extension in the ClientHello message, which is not encrypted. So no, looks like there are no changes to this in TLS 1.3. Theoretically it could be possible to encrypt it (using DHE) before server validation occurs (i.e. before the server's RSA certificate is needed). However, it would rigorously change the protocol and I can imagine it would make some load balancing applications a lot more complicated as well.
  - yuhong 11y ago
    Not to mention not compatible with TLS 1.2 and older.
- AndyMcConachie 11y ago
  I don't think this is possible. I can have different TLS configs for each vhost I set up on a single HTTP instance. And until the SNI is sent the server has no way of knowing which vhost to use. Also SNI needs to match the hostname specified in the X.509 part of the cert. Certs are issued based on DNS names which need to correspond to SNI. I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet.
  - quesera 11y ago
    > I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet. Destination IP will be the same for all sites on the server, SNI tells you exactly which site was asked for. Not meaning to be pedantic, sometimes the distinction isn't clear. But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address. You'd also need to trust DNS completely. RTT would inflate significantly. The CA system is a mess, but DNS is worse. Tying certs to bare IPs would create a deployment nightmare as well. SNI is imperfect, but it is a big improvement over the previous status quo, which was single-IP per https host, which obviously did nothing to obscure the site hostname either.
    - jimktrains2 11y ago
      > But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address. Why wouldn't a DH exchange be enough?
      - quesera 11y ago
        You're right, DH might be enough, depending on goals. The DH exchange would be MITMable, but not passively collectable. TLS is (ideally) neither, so DH wouldn't provide an equal level of privacy. Still, it would be a beneficial extension of the protocol. At the cost of an additional TCP RT.
        jimktrains2 11y ago
        Right, however, the MITM attack would also come at the cost of causing the rest of the connection to fail. You could also do fun stuff like sending the sha256-mac of the hostname using the DH key as the MAC key. There are lots of fun ideas!
    - deleted 11y ago
      [deleted]
  - mook 11y ago
emielm 11y ago
0rtt is going to make a huge perceived difference on high latency (mobile) links. Don't forget however that the syn/ack tcp connection setup also still has an additional 1rtt overhead. For this reason, I'm still rooting for Google's QUIC to get towards standardization and mainstream adoption.
- netheril96 11y ago
  QUIC is indeed nice. As a Chinese who frequently browses Google with a VPN and therefore high latency, the difference between loading Google in Chrome and in other browsers is palpable. But I have not seen any adoption of QUIC either in clients or servers, outside the Google's circle.
  - r1ch 11y ago
    I'm hoping once QUIC matures that Google will release some open source Apache / nginx modules to support it. Development without any commercial incentive seems to happen very slowly otherwise.
mc_hammer 11y ago
good tls more privacy > i dont believe u theres a open buffer overflow in the github repo supplementaluserdata for 1 year logjam. heartbleed. automatic downgraded encryption for non-US (or foreign proxies and TOR). + one or two other show stopping bugs (and n00b crypto bugs) previously like null nonce/re-using nonce shit the author of TLS even published a MITM exploit kit/template oh and they want us to run TLS now for all SSH and SSL/HTTPS? gentlemen this is government crypto. even the head of W3C published an article saying this is not https. its only being labeled https. [what is the definition of subversion?] IMHO: whats needed is two choices for HTTPS. and seperate crypto for SSH. also if they would freeze TLS for at least 3-6 months it could give Language/Library authors time to audit there code (and prove tls is not so buggy it needs a new version every week)
- dgoldstein0 11y ago
  all the problems you call out are implementation bugs, not specification bugs. If people can't implement it right, it's not the spec's fault - though we should definitely strive for "easy to implement". "Freezing TLS" doesn't really make sense either - you'll probably be able to use TLS 1.1/1.2 for years to come, and it takes a LONG time for a new version of the protocol to roll out and gain support. If a TLS implementation wanted to focus on bugs and quality instead of implementing new features, they totally could.
- viraptor 11y ago
  TLS is really just higher version of SSL. Your comment reads like there's some significant difference between them. Tls actually fixed known ssl issues, so whether you like it or not, originall SSL is just insecure. I'm not sure what you mean by running TLS for SSH - they're quite separate.
  - darkr 11y ago
    Yup, TLS 1.0 == SSL 3.1. So called as Netscape owns the patent to SSL, but granted a royalty free license to the IETF for their version of SSL, named TLS.
keeperofdakeys 11y ago
I'm wondering if the 0-RTT mode brings any issues with DDoS attacks. Since the request is sent in the initial TLS request, the server must buffer it, or create a response before it finishes the handshake. Admittedly it's not UDP, so you still need to successfully perform a TCP handshake (ie: verify the reverse path).
- stingraycharles 11y ago
  Wouldn't proper application design just wait to read the actual content / request from the socket? As in, this will most likely be buffered somewhere in the kernel TCP stack, and not in the application, making the situation comparable to 1rtt from a DoS perspective.
  - keeperofdakeys 11y ago
    Where is "somewhere", the kernel only has a finite amount of memory. It's still a denial of service, whether it occurs in the kernel, or a user-space program. The point is that in order to service legitimate clients, the initial request must be buffered somewhere. For the 1rtt case, the request isn't sent till the TLS connection has been established. The attackers would have to keep track of these TLS connections, so this doesn't seem like a DoS vector. For 0rtt the attackers might not need to keep track of state, allowing them to simply send TLS 1.3 requests, and overload the server's memory. My question is whether this is a legitimate concern.

81 points by ttaubert 11y ago

kardos 11y ago

Regarding more privacy: have they found a way to keep the SNI information private?

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
praseodym 11y ago
SNI is the "server_name" extension in the ClientHello message, which is not encrypted. So no, looks like there are no changes to this in TLS 1.3. Theoretically it could be possible to encrypt it (using DHE) before server validation occurs (i.e. before the server's RSA certificate is needed). However, it would rigorously change the protocol and I can imagine it would make some load balancing applications a lot more complicated as well.
- yuhong 11y ago
  Not to mention not compatible with TLS 1.2 and older.
AndyMcConachie 11y ago
I don't think this is possible. I can have different TLS configs for each vhost I set up on a single HTTP instance. And until the SNI is sent the server has no way of knowing which vhost to use. Also SNI needs to match the hostname specified in the X.509 part of the cert. Certs are issued based on DNS names which need to correspond to SNI. I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet.
- quesera 11y ago
  > I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet. Destination IP will be the same for all sites on the server, SNI tells you exactly which site was asked for. Not meaning to be pedantic, sometimes the distinction isn't clear. But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address. You'd also need to trust DNS completely. RTT would inflate significantly. The CA system is a mess, but DNS is worse. Tying certs to bare IPs would create a deployment nightmare as well. SNI is imperfect, but it is a big improvement over the previous status quo, which was single-IP per https host, which obviously did nothing to obscure the site hostname either.
  - jimktrains2 11y ago
    > But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address. Why wouldn't a DH exchange be enough?
    - quesera 11y ago
      You're right, DH might be enough, depending on goals. The DH exchange would be MITMable, but not passively collectable. TLS is (ideally) neither, so DH wouldn't provide an equal level of privacy. Still, it would be a beneficial extension of the protocol. At the cost of an additional TCP RT.
      - jimktrains2 11y ago
        Right, however, the MITM attack would also come at the cost of causing the rest of the connection to fail. You could also do fun stuff like sending the sha256-mac of the hostname using the DH key as the MAC key. There are lots of fun ideas!
  - deleted 11y ago
    [deleted]
- mook 11y ago

emielm 11y ago

0rtt is going to make a huge perceived difference on high latency (mobile) links. Don't forget however that the syn/ack tcp connection setup also still has an additional 1rtt overhead. For this reason, I'm still rooting for Google's QUIC to get towards standardization and mainstream adoption.

netheril96 11y ago
QUIC is indeed nice. As a Chinese who frequently browses Google with a VPN and therefore high latency, the difference between loading Google in Chrome and in other browsers is palpable. But I have not seen any adoption of QUIC either in clients or servers, outside the Google's circle.
- r1ch 11y ago
  I'm hoping once QUIC matures that Google will release some open source Apache / nginx modules to support it. Development without any commercial incentive seems to happen very slowly otherwise.

mc_hammer 11y ago

good tls more privacy > i dont believe u theres a open buffer overflow in the github repo supplementaluserdata for 1 year logjam. heartbleed. automatic downgraded encryption for non-US (or foreign proxies and TOR). + one or two other show stopping bugs (and n00b crypto bugs) previously like null nonce/re-using nonce shit the author of TLS even published a MITM exploit kit/template oh and they want us to run TLS now for all SSH and SSL/HTTPS? gentlemen this is government crypto. even the head of W3C published an article saying this is not https. its only being labeled https. [what is the definition of subversion?] IMHO: whats needed is two choices for HTTPS. and seperate crypto for SSH. also if they would freeze TLS for at least 3-6 months it could give Language/Library authors time to audit there code (and prove tls is not so buggy it needs a new version every week)

dgoldstein0 11y ago
all the problems you call out are implementation bugs, not specification bugs. If people can't implement it right, it's not the spec's fault - though we should definitely strive for "easy to implement". "Freezing TLS" doesn't really make sense either - you'll probably be able to use TLS 1.1/1.2 for years to come, and it takes a LONG time for a new version of the protocol to roll out and gain support. If a TLS implementation wanted to focus on bugs and quality instead of implementing new features, they totally could.
viraptor 11y ago
TLS is really just higher version of SSL. Your comment reads like there's some significant difference between them. Tls actually fixed known ssl issues, so whether you like it or not, originall SSL is just insecure. I'm not sure what you mean by running TLS for SSH - they're quite separate.
- darkr 11y ago
  Yup, TLS 1.0 == SSL 3.1. So called as Netscape owns the patent to SSL, but granted a royalty free license to the IETF for their version of SSL, named TLS.

keeperofdakeys 11y ago

I'm wondering if the 0-RTT mode brings any issues with DDoS attacks. Since the request is sent in the initial TLS request, the server must buffer it, or create a response before it finishes the handshake. Admittedly it's not UDP, so you still need to successfully perform a TCP handshake (ie: verify the reverse path).

stingraycharles 11y ago
Wouldn't proper application design just wait to read the actual content / request from the socket? As in, this will most likely be buffered somewhere in the kernel TCP stack, and not in the application, making the situation comparable to 1rtt from a DoS perspective.
- keeperofdakeys 11y ago
  Where is "somewhere", the kernel only has a finite amount of memory. It's still a denial of service, whether it occurs in the kernel, or a user-space program. The point is that in order to service legitimate clients, the initial request must be buffered somewhere. For the 1rtt case, the request isn't sent till the TLS connection has been established. The attackers would have to keep track of these TLS connections, so this doesn't seem like a DoS vector. For 0rtt the attackers might not need to keep track of state, allowing them to simply send TLS 1.3 requests, and overload the server's memory. My question is whether this is a legitimate concern.