Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

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.

[XGS_Is_On]

Oki doki. *Knuckle crack* - I love when Weaver posts threads I can answer some of.

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.

No. Not without inspecting beyond superficially layer 4 which makes your router no longer a router but a layer-7 aware DPI device. You'd recognise that it's QUIC by the port number but wouldn't be dissecting the protocol itself anymore than right now your top-end router dissects TCP headers and provides details on window sizes, congestion avoidance, SACKs sent, etc. Those are the purview of specialised devices that are not routers. Firewalls will certainly be doing DPI on QUIC, but firewalls that can handle the several terabits per second a single router chassis can aren't a thing.

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

If this forum counts yeah you do, a bit, though definitely not an expert.

Asymmetric ciphers are used, these have a public and a private component. The public one anyone can know, the private one is, well private.

In the case of RSA generate two large prime numbers, p and q and multiple them to produce n, the modulus: n = p * q.
Next, calculate the lowest common multiple of (p-1,q-1) and you've Carmichael's totient for n.
Pick a prime number, e, between 1 and Carmichael's totient for n, 65537 is often chosen, doesn't have to be random.
Your public key consists of e and n.

To encrypt your ciphertext c = your message, m, ^e mod n. c = m^e mod n.

Now decryption.

The private key consists of d and n. d is 1/e mod Carmichael's n. This means calculate the modular inverse of e, not do the 1/e mod Carmichael's n.

To decrypt:

m =  c^d mod n.

In summary, RSA relies on the difficulty of factoring large numbers without any clues - to decrypt you need d which is never sent on the wire. To work d out you need to know Charmichael's totient of n which in turn requires p and q which are never sent on the wire.

I give you 1,766,514,921,648,574 and ask you to work out which 2 prime numbers it's been made with: challenging. I ask you to multiply 57885161 and 305175781 not so challenging. Now imagine doing this with a pair of 2048 binary digit primes and you get the idea. If you know one of the two primes used in the calculation that's a private key and you can trivially solve the problem. Everyone knows n, e and d are mathematically related such that encryption with e can be decrypted wtih d.

RSA is computationally expensive so it and eliptic curve will be used for key exchange with something like AES for the actual data - you'll see cipher suites mentioning RSA4096/AES256/SHA512 for example: this means 4096 bit key RSA to exchange a 256 bit AES key with 512 bit SHA being used as the hashing function to provide message integrity.

As far as the more modern eliptic curves go - https://en.wikipedia.org/wiki/Elliptic-curve_cryptography is superior to me.

[petef]

I'll add a small bit to that answer. The bulk of the conversation is encrypted with a symmetric key, i.e. the same at both ends. It is not however pre-shared, rather it is generated when the two ends establish communication with both contributing. That early conversation is encrypted using asymmetric keys. https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange

[Weaver]

Thanks XGS. for the first time, I get it. So the answer to my other question is "no"; we are ok even if the eavesdropper hears the initial part of the conversation.

At least I know I’m completely stupid. The drugs do not help at all with this.

Coming back to the router QUIC analysis thing. I do understand that parsing QUIC fields live would crucify routing performance. I didn’t explain the situation I was thinking of. One could ask the router to capture traffic and then parse it from the buffer and that would be a very nice feature indeed. This would be just like AA’s post-traffic-capture analysis tool. So a misunderstanding caused by my lack of explanation.

[XGS_Is_On]

Got it.

That's easy, it just kills throughput on big routers. Won't have the same impact on a Firebrick because they aren't using big routing ASICs. In fact given the performance they have they could easily be appliances doing everything in software, no hardware support at all.

You set up an access list to capture traffic then mirror that traffic to an internal virtual interface and write the entire flow to storage.

Very resource intensive. Should only be done for debug purposes outside of standard operating hours.

[Weaver]

I left the option open as to how much if any pre-filtering might be done before stuff is written to the capture buffer. The one extreme is to (1) capture all traffic for a short time period. Another is to (2) write only UDP, or (3) only QUIC. It depends on our how capabilities for filtering as to which options are open to us if the traffic is very high rate. We just either waste more RAM if we have it, or we fill the buffer too soon.