Shouldn’t the server’s DH key be pretty much opaque to a client?
-
-
If we wanted to prevent this kind of thing, then we would have tried to find a way to make the protocol secure by making Server.Random deterministic, and get people to insist on that variant of TLS. (Even now, given the use of ephemeral DH, does Server.Random need to be random?)
-
This is an impossible problem. You’d have to lock down every potentially random byte of the protocol to make this work, and even then you could always use a timestamp or an out-of-band channel.
-
It would be difficult. I think it helps that there are few unencrypted extensions in TLS 1.3 and almost all data is encrypted/authenticated. On the other hand, the record header is authenticated but not (required to be) verified to be in range so it allows a covert channel.
-
(FWIW I argued against the record header covert channel on the TLS WG mailing list but people disagreed.) I agree that such a design would be tricky and would require a lot of effort (not just a couple of tweets) and kind of too late since TLS 1.3 shipped. Not sure *impossible*.
-
Oh, maybe it can be done for QUIC.
-
Quic packets are the record layer for quic, so quic only forwards tls messages not records
-
Yeah, I mean, more generally, one could/should analyze QUIC more generally to see if there are unnecessary covert channels. I assume that since it uses TLS 1.3 then Server.Random is still one, for example.
-
The harder problem with QUIC is that the server could just send out a junk QUIC record that the client throws away, which contains the)(encrypted) information for the MitM to process. So, probably there's not much one could do.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.