How will sslsplit handle quic?

[trifle]

This is not a bug report; I'm trying to learn how quic will affect MITM in general and sslsplit in particular.

In short, quic - wikipedia is an UDP-based protocol that is seeing increasing adoption in place of http/2.

It seems that MITM on quic is not entirely impossible - mitmproxy seems to be working on it (branch here, issue discussion).

Given that especially large sites are rapidly switching over to quic, it seems desirable to have an option of decrypting or at least downgrading it to http in sslsplit.

[trifle]

Just to add, downgrading should work if you just block 443/udp - clients will fail over to https/tcp

[daMatz]

@trifle could you please elaborate on this? If I reject incoming UDP connections on port 443 to the client (e.g. by setting iptables -I INPUT -p udp --dport 443 -j REJECT), the server should fallback to HTTP/1 or HTTP/2 over tcp instead of HTTP/3 over udp/quic?

[trifle]

@daMatz Disclaimer: I haven't investigated this extensively.

Handling connection failures is generally clients' responsibility (so has nothing to do with the server). This means that when you block UDP, browsers will need to figure out what to do next. There is a passage in the standard stating:

All applications running on top of QUIC must therefore either be prepared to accept connectivity failure on such networks or be engineered to fall back to some other transport protocol. In the case of HTTP, this fallback is TLS over TCP.

So yes, we can generally assume clients will fall back to TCP, but it is an open question whether they actually do. I can imagine some clients to just error out either due to laziness, ignorance or malice.

[daMatz]

@daMatz Disclaimer: I haven't investigated this extensively.

Handling connection failures is generally clients' responsibility (so has nothing to do with the server). This means that when you block UDP, browsers will need to figure out what to do next. There is a passage in the standard stating:

All applications running on top of QUIC must therefore either be prepared to accept connectivity failure on such networks or be engineered to fall back to some other transport protocol. In the case of HTTP, this fallback is TLS over TCP.

So yes, we can generally assume clients will fall back to TCP, but it is an open question whether they actually do. I can imagine some clients to just error out either due to laziness, ignorance or malice.

Alright thanks! I have to check how the behaviour is in my case, as I'm looking at mobile applications and different network libraries 👍

[trifle]

I'd be very interested in your results, so if you could drop a quick comment - even with a rough impression - that would be great!