I think it’s fundamentally unavoidable. At the point that a browser initiates a connection to a server, the server doesn’t yet know which certificate to present. DH alone doesn’t authenticate that you haven’t been MITM’d.
It’s not unavoidable if both parties can agree on a PSK (pre-shared key) out-of-band, or from a previous session - and IIRC, the TLS 1.3 0-RTT handshake which is now used by QUIC can negotiate PSKs or tickets for use in future sessions once key exchange is done. But for the first time connection between two unknown parties, it is certainly unavoidable when SNI is required, due to the aforementioned inability to present appropriate certificates.
On the other hand, if you have been MitM’d you’ll notice it instantly (and know that the server certificate has been leaked to Mallory in the Middle). And now every connection you make is broken, including the ones they did not want to block. I see to ways of avoiding that:
Don’t actually MitM.
Be a certificate authority your users “trust” (install your public key in everyone’s computers, mostly).
No, but DH prevents sending a key across the wire, making them known and prevents passive observers from reading ciphertext. Wouldn’t it make sense to talk to the server first?
Without some form of authentication (provided by TLS certificates in this case), you have no way to know whether you’re doing key exchange with the desired endpoint or some middlebox, so you don’t really gain anything there.
You gain protection against passive observers, thereby increasing costs of attackers trying to snoop on what services people connect to. Also when you then anyways end up receiving the certificate you at worst retro-actively could verify you weren’t snooped at, which is more than you have when it’s actually that you send a key that allows you to decrypt, which still sounds odd to me.
I don’t know how much sense it makes? Doing a DH first adds more round trips to connection start, which is the specific thing QUIC is trying to avoid, and changes the way TLS integrates with the protocol, which affects implementability, the main hurdle QUIC has had to overcome.
I get that, but how does it make sense to send something encrypted when you send the key to decrypt it with it? You might as well save that step, after all the main reason to encrypt something is to prevent it from being read.
EDIT: How that initial key is sent isn’t part of TLS, is it? It’s part of QUIC-TLS (RFC9001). Not completely sure, but doesn’t regular 0-RTT in TLSv1.3 work differently?
The next version of QUIC has a different salt which prevents ossification. To achieve encryption without authentication, the server and the client can agree on a different salt. There’s a draft describing this approach, I think.
It’s only the public keys that are known, and if they did their job well, they only need to expose ephemeral keys (which are basically random, and thus don’t reveal anything). In the end, the only thing an eavesdropper can know is the fact you’re initiating a QUIC connection.
If you want to hide that, you’d have to go full steganography. One step that can help you there is making sure ephemeral keys are indistinguishable from random numbers (With Curve25519, you can use Elligator). Then you embed your abnormally high-entropy traffic in cute pictures of cats, or whatever will not raise suspicion.
This is incorrect, see RFC9001. As a passive observer you have all the information you need to decrypt the rest of the handshake. This is by design and is also mentioned again in the draft that rpaulo mentioned.
The problems with this are mentioned in 9001, the mentioned draft and the article.
Goodness, I’m reading section 7 of the RFC right now, it sounds pretty bad. The thing was devised in 2012, we knew how to make nice handshakes that leak little information and for heaven’s sake authenticate everything.
As a passive observer you have all the information you need to decrypt the rest of the handshake.
Now I’m sure it’s not that bad. I said “It’s only the public keys that are known”. You can’t be implying we can decrypt or guess the private keys as well? And as a passive observer at that? That would effectively void encryption entirely.
I imagine the approach in a lot of places will just be to block HTTP3 outright. It makes their lives easier, and most people won’t even notice, since there’s always an HTTP 1 or 2 fallback. Kind of a consequence of the browser manufacturers deciding that there is one and only one scheme for things users can actually navigate to and that’s https.
The article says that Russia is blocking QUIC on all international sites, but I do see that visitors from Russia are accessing some of my QUIC-enabled sites over HTTP3. The site in question (https://spotifytrack.net) is using QUIC version 1 as well.[1]
I checked three different visits from three different IPs that all geo-locate to Russia, and all of them do indeed make successful HTTP3 requests. Maybe that situation has changed since that testing was done or this article was published.
I haven’t looked at the specs yet. Is that true? Isn’t that horrible?
I think it’s fundamentally unavoidable. At the point that a browser initiates a connection to a server, the server doesn’t yet know which certificate to present. DH alone doesn’t authenticate that you haven’t been MITM’d.
It’s not unavoidable if both parties can agree on a PSK (pre-shared key) out-of-band, or from a previous session - and IIRC, the TLS 1.3 0-RTT handshake which is now used by QUIC can negotiate PSKs or tickets for use in future sessions once key exchange is done. But for the first time connection between two unknown parties, it is certainly unavoidable when SNI is required, due to the aforementioned inability to present appropriate certificates.
On the other hand, if you have been MitM’d you’ll notice it instantly (and know that the server certificate has been leaked to Mallory in the Middle). And now every connection you make is broken, including the ones they did not want to block. I see to ways of avoiding that:
No, but DH prevents sending a key across the wire, making them known and prevents passive observers from reading ciphertext. Wouldn’t it make sense to talk to the server first?
Without some form of authentication (provided by TLS certificates in this case), you have no way to know whether you’re doing key exchange with the desired endpoint or some middlebox, so you don’t really gain anything there.
You gain protection against passive observers, thereby increasing costs of attackers trying to snoop on what services people connect to. Also when you then anyways end up receiving the certificate you at worst retro-actively could verify you weren’t snooped at, which is more than you have when it’s actually that you send a key that allows you to decrypt, which still sounds odd to me.
What you’re suggesting is described on https://www.ietf.org/id/draft-duke-quic-protected-initial-04.html This leverages TLS’s encrypted client hello to generate QUIC’s INITIAL keys.
I don’t know how much sense it makes? Doing a DH first adds more round trips to connection start, which is the specific thing QUIC is trying to avoid, and changes the way TLS integrates with the protocol, which affects implementability, the main hurdle QUIC has had to overcome.
I get that, but how does it make sense to send something encrypted when you send the key to decrypt it with it? You might as well save that step, after all the main reason to encrypt something is to prevent it from being read.
EDIT: How that initial key is sent isn’t part of TLS, is it? It’s part of QUIC-TLS (RFC9001). Not completely sure, but doesn’t regular 0-RTT in TLSv1.3 work differently?
The purpose of encrypting initial packets is to prevent ossification.
Okay, but to be fair that kind of still makes it seem like the better choice would be unauthenticated encryption that is not easily decryptable.
I know 0RTT is a goal but at least to me it seems like the tradeoff isn’t really worth it.
Anyways thanks for your explanations. It was pretty insightful.
I guess I’ll read through more quic and TLS on the weekend if I have time.
The next version of QUIC has a different salt which prevents ossification. To achieve encryption without authentication, the server and the client can agree on a different salt. There’s a draft describing this approach, I think.
According to https://quic.ulfheim.net/ :
It’s not more horrible than the existing TLS 1.3 :-) I sent out a link to something that may be of interest to you.
It’s only the public keys that are known, and if they did their job well, they only need to expose ephemeral keys (which are basically random, and thus don’t reveal anything). In the end, the only thing an eavesdropper can know is the fact you’re initiating a QUIC connection.
If you want to hide that, you’d have to go full steganography. One step that can help you there is making sure ephemeral keys are indistinguishable from random numbers (With Curve25519, you can use Elligator). Then you embed your abnormally high-entropy traffic in cute pictures of cats, or whatever will not raise suspicion.
This is incorrect, see RFC9001. As a passive observer you have all the information you need to decrypt the rest of the handshake. This is by design and is also mentioned again in the draft that rpaulo mentioned.
The problems with this are mentioned in 9001, the mentioned draft and the article.
Goodness, I’m reading section 7 of the RFC right now, it sounds pretty bad. The thing was devised in 2012, we knew how to make nice handshakes that leak little information and for heaven’s sake authenticate everything.
Now I’m sure it’s not that bad. I said “It’s only the public keys that are known”. You can’t be implying we can decrypt or guess the private keys as well? And as a passive observer at that? That would effectively void encryption entirely.
I imagine the approach in a lot of places will just be to block HTTP3 outright. It makes their lives easier, and most people won’t even notice, since there’s always an HTTP 1 or 2 fallback. Kind of a consequence of the browser manufacturers deciding that there is one and only one scheme for things users can actually navigate to and that’s
https.The article says that Russia is blocking QUIC on all international sites, but I do see that visitors from Russia are accessing some of my QUIC-enabled sites over HTTP3. The site in question (https://spotifytrack.net) is using QUIC version 1 as well.[1]
I checked three different visits from three different IPs that all geo-locate to Russia, and all of them do indeed make successful HTTP3 requests. Maybe that situation has changed since that testing was done or this article was published.
[1] https://http3check.net/?host=spotifytrack.net