Conversation

GnuTLS was using an all-zero key for encrypting TLS session tickets. Whoops.

CVE-2020-13777: TLS 1.3 session resumption works without master key, allowing MITM (#1011) · Issues...

GnuTLS servers are able to use tickets issued by each other without access to the secret key as generated by gnutls_session_ticket_key_generate(). This allows a MITM server without valid...

622

789

Replying to

FFS can we just deprecate session resumption already? It's not worth the risks.

Replying to

and

Thankfully either side (client or server) can unilaterally refuse to use it, so there are lots of paths to push for deprecation.

Replying to

and

TLS 1.3 already goes a long way towards that and most people aren't trying to use 0-RTT. There will be even less reason to care about it with QUIC since it puts the TLS handshake into the equivalent of the TCP handshake as long as the certificates aren't too bloated.

Replying to

and

With QUIC, if you don't use bloated certificates, you don't need any extra round trip for TLS anyway without needing the scary 0-RTT feature. 0-RTT is pretty fucking sketchy by the way. It would be safe to use with HTTP GET with how I implement services but not the way most do...

Replying to

and

I'm really not interested in hearing about Google's goofy attempt to replace standard protocols for the sake of making hideously bloated websites less disincentivized by bad ux.

Replying to

and

QUIC refers to the IETF protocol. Google's proof of concept protocol is referred to as gQUIC now. HTTP/3 is essentially HTTP/2 over QUIC with minor changes to deal with running on top of a multiplexed protocol. It won't be any less standard than other protocols.

Replying to

and

Real-time applications like voice / video calls, gaming, etc. use custom protocols implemented on top of UDP. WebRTC uses SCTP-over-DTLS-over-UDP. QUIC is similar concept. WebRTC will move to using QUIC and most custom protocols implemented via UDP will be able to move to it.

Replying to

and

IETF wanted QUIC to be separate from HTTP/3 because it's useful for other things. That's why they're standardizing it separately. It's not Google's protocol anymore. It has been heavily changed including dropping their much more minimal replacement for TLS and just using TLS 1.3.

3:31 PM · Jun 9, 2020Twitter Web App

Replying to

and

I'm happy with HTTP/1.1 forever.

Replying to

and

What about uses other than web servers? Voice / video calls, etc. There's a reason that Zoom and nearly everyone else doing real-time stuff has terrible homegrown protocols. TCP doesn't work well for real-time applications and doesn't handle lossy networks or transitions well.

Show replies