> What I suspect in fact is that in the datacentre what most admins would > be interested in would just be to disable header protection to make it > easier to follow the protocol itself (e.g. observe retransmits etc) > without risking to expose the payload, that absolutely nobody wants to > see the vast majority of the time during debugging.
That's an interesting idea. In principle it should be possible to only export the header protection keys without exporting any other TLS keys. I don't believe the SSLKEYLOGFILE has an option for that though, and I'm not sure if there's a way to load header protection keys into Wireshark. On Wed, 24 Jan 2024 at 10:39, Willy Tarreau <[email protected]> wrote: > On Tue, Jan 23, 2024 at 08:17:07AM +0000, Hugo Landau wrote: > > > > Plain-text communication was an explicit anti-goal in the design of > > > > QUIC. > > > > > > This is absolutely right, but I'm a little disappointed that no one > has really said *why* yet. > > > > I support everything Martin has said here. IMO the only circumstance in > > which 'unencrypted (integrity-only) QUIC' could make sense is for > > internal use in datacentres. It is certainly true that the protocol as > > designed is (rightly) designed for the public internet and certainly > > reflective of the hostility of the public internet as a network > > environment today. At the same time it makes it feel a bit overkill for > > a backend protocol between servers in a trusted environment. > > But maybe the burden of that is a non-issue in practice. > > For having been involved in analysing a lot of network traces in order > to troubleshoot compatibility issues between TCP components, I'd say > that in practice most of the traces inside the datacenter only require > access to the protocol parts and not the payload. Even worse, sometimes > you can discover by accident that you're having a trace caught in emergency > while trying to spot a big prod problem and that was stored on your USB > thumb drive, and when you (re)discover this, you're very happy to see > that the data were encrypted. > > What I suspect in fact is that in the datacentre what most admins would > be interested in would just be to disable header protection to make it > easier to follow the protocol itself (e.g. observe retransmits etc) > without risking to expose the payload, that absolutely nobody wants to > see the vast majority of the time during debugging. > > Willy > >
