More Privacy, Less Latency – Improved Handshakes in TLS v1.3
1–10 of 23 posts
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#2Regarding more privacy: have they found a way to keep the SNI information private?
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#3Regarding more privacy: have they found a way to keep the SNI information private?
[deleted]
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#40rtt 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.
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#5Regarding more privacy: have they found a way to keep the SNI information private?
[deleted]
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#6good 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)
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#70rtt 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.
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#8Regarding more privacy: have they found a way to keep the SNI information private?
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.
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#9Regarding more privacy: have they found a way to keep the SNI information private?
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 co…
Not to mention not compatible with TLS 1.2 and older.
Re: More Privacy, Less Latency – Improved Handshakes in TLS v1.3
#10I'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).