If you are a top-end router manufacturer, is there any useful and helpful status information you can show per-session or per-flow when you see a QUIC connection? I’m immediately assuming that you recognise QUIC as such rather than just thinking that it’s meaningless UDP. That at least would be a start, albeit a very small one. I do realise that what you can show is fairly limited because of the thorough encryption.
A wireshark-like breakdown into fields would perhaps be nice? Not exactly sure how much that’s possible. Handling the reconnection / network migration protocol would be nice. This is where QUIC intelligently copes with a change of network i/f and thus change of source IP address when say the local network interface in use changes from wifi->fibre to 4G/5G when a mobile machine leaves a building and switches to the cellular network instead of the local wifi. The L4 connection_id is maintained (or whatever it’s called) and the remote machine/server uses that to recognise that this is still the known L4 connection even though it’s now coming from an unknown L3 source address.
Again, not sure how much can be decoded and published, but since the whole thing is so utterly brain-melting that any well-documented help with wireshark-like analysis would be great, because maybe one could then apply filters based on certain fields (maybe with regex-type match expressions, or, errm, something.
) You may say, just use wireshark then, but the router is often in a much better place to get access and do analysis. AA, my ISP, can do a traffic capture and then apply TCPDUMP analysis on the results, but that doesn’t address the current case, and also I can’t do it live all the time, it’s just an n-secs capture. Nor can I then run filters based on what I find. Also there’s a problem of my own stupid making; I don’t have a suitable box on which to run Wireshark.
—
One more general, and probably stupid question, about encrypted protocols in general, including even TLS. If you have seen the connection establishment phase, then you know as much as one of the two boxes does, unless the protocol uses secrets pre-established, known in advance, or transmitted out-of-band, say using 4G instead of the main internet connection over say fibre. The whole point of many modern connections such as TLS, so I believe, is to allow unknown machines to communicate, without having earlier sent hard disks or dvds in the diplomatic pouch with a courier who vows to own up if she has been compromised en route. I’m a big fan of the likes of the Vernam cipher / one-time-pad, although I think it can be greatly enhanced. But of course as you know it’s not popular these days even though it’s the very best of the best, because the key distribution problem makes it a nightmare and it’s no use for web shopping seeing as the communicants have never met before to exchange secrets.
So with eg TLS, if you see the whole connection establishment phase and there are no Vernam-like pre-shared keys in storage, why can’t I just decode everything that is being said? Because the recipient knows no more than me, the eavesdropper, under the restriction previously mentioned about no PSKs (no Vernam/OTP-like private foreknowledge).
I must be completely stupid here; this is not my area, and I don’t pretend to understand the mathematics of the likes of TLS, and I’m not sure that I know anyone who does, although my friend Jane can work it out even if she doesn’t know. (Jane was the head operating systems’ kernel designer at one point before I left Psion/Symbian and later she was promoted to total and utter god of new RTOS development after I had moved to Skye. She has a maths degree from Oxford so is a bit of a brainbox in all things "git-hard" as another friend of mine is wont to say.) I need someone to explain it to me. I probably should have done a maths degree, although I’m not sure that I could have coped with it as I’m way too thick.
Is the average encrypted protocol only secure provided that eavesdroppers have missed overhearing the connection establishment phase? Which may or may not have been ages ago? Connection re-use and keepalive is a very good thing anyway as that way by reusing an already open L4 connection, there’s no slow-start phase in say TCP (don’t know about QUIC, but with early few-RTTs L7 data exchange, the slow start isn’t quite so deathful in some cases.) In QUIC and http/2 (?) (and SCTP maybe?) multiplexing of independent L5 data streams is promoted, no? So that means everything tends to use a single L4 connection, no? Provided that modules of code in a process do know about each other’s existence, that is, as if not then they can’t share a common, known, single L4 connection object or ‘handle’ given to the o/s or whatever it’s called.