Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

timtaubert.de

Post reply on HN
Print view View original

11–20 of 23 posts

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

#11

Post by dgoldstein0 »

mc_hammer wrote: post #6

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

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.

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

#12

Post by r1ch »

netheril96 wrote: post #7
emielm wrote: post #4

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.

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.

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.

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

#13

Post by viraptor »

mc_hammer wrote: post #6

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

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.

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

#14

Post by stingraycharles »

keeperofdakeys wrote: post #10

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

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.

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

#15

Post by AndyMcConachie »

kardos wrote: post #2

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

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.

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

#16

Post by darkr »

viraptor wrote: post #13
mc_hammer wrote: post #6

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

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.

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.

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

#17

Post by quesera »

AndyMcConachie wrote: post #15
kardos wrote: post #2

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

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

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

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

#18

Post by mook »

AndyMcConachie wrote: post #15
kardos wrote: post #2

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

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

> You could always just look at the destination IP address of the packet.

For CDN services like cloudflare I'd imagine that it would make more of an impact, since in that case an IP address could potentially match many host names. Of course that has its own downsides - most notably the fact that you'd need to trust them with the server's private key.

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

#19

Post by [deleted] »

quesera wrote: post #17
AndyMcConachie wrote: post #15

Earlier quoted context omitted.

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

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

[deleted]

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

#20

Post by jimktrains2 »

quesera wrote: post #17
AndyMcConachie wrote: post #15

Earlier quoted context omitted.

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

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

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

Post reply on HN