9 ms·

There's also the fact that TCP has an unfixable security flaw - any random middleware can inject data (without needing to block packets) and break the connectio

by o11c 2y ago

There's also the fact that TCP has an unfixable security flaw - any random middleware can inject data (without needing to block packets) and break the connection. TLS only can add Confidentiality and Integrity, it can do nothing about the missing Availability.

suprjami 2y ago
What does that have to do with anything here? This post is about QUIC performance, not TCP packet injection.
- o11c 2y ago
  "Accept worse performance in order to fix security problems" is a standard tradeoff.
  - suprjami 2y ago
    QUIC was invented to provide better performance for multiplexed HTTP/3 streams and the bufferbloat people love that it avoids middlebox protocol interference. QUIC has never been about "worse performance" to avoid TCP packet injection. Anybody who cares about TCP packet injection is using crypto (IPSec/Wireguard). If performant crypto is needed there are appliances which do it at wirespeed.
ChocolateGod 2y ago
> There's also the fact that TCP has an unfixable security flaw - any random middleware can inject data (without needing to block packets) and break the connection I am unsure how this is a security flaw of TCP? Any middleman could block UDP packets too and get the same effect, or modify UDP packets in an attempt to cause the receiving application to crash.
- o11c 2y ago
  In order to attack UDP, you have to block all routes through which traffic might flow. This is hard; remember, the internet tries to be resilient. In order to attack TCP, all you have to do is spy on a single packet (very easy) to learn the sequence number, then you can inject a wrench into the cogs and the endpoints will reject all legitimate traffic from each other.
  - jeroenhd 2y ago
    That's only true if you use the kernel TCP stack. You can replicate the slow QUIC stack and do everything in user mode to get control back over what packets you accept (i.e. reject any that don't fit your TLS stream).

by o11c 2y ago

suprjami 2y ago

What does that have to do with anything here? This post is about QUIC performance, not TCP packet injection.

o11c 2y ago
"Accept worse performance in order to fix security problems" is a standard tradeoff.
- suprjami 2y ago
  QUIC was invented to provide better performance for multiplexed HTTP/3 streams and the bufferbloat people love that it avoids middlebox protocol interference. QUIC has never been about "worse performance" to avoid TCP packet injection. Anybody who cares about TCP packet injection is using crypto (IPSec/Wireguard). If performant crypto is needed there are appliances which do it at wirespeed.

ChocolateGod 2y ago

> There's also the fact that TCP has an unfixable security flaw - any random middleware can inject data (without needing to block packets) and break the connection I am unsure how this is a security flaw of TCP? Any middleman could block UDP packets too and get the same effect, or modify UDP packets in an attempt to cause the receiving application to crash.

o11c 2y ago
In order to attack UDP, you have to block all routes through which traffic might flow. This is hard; remember, the internet tries to be resilient. In order to attack TCP, all you have to do is spy on a single packet (very easy) to learn the sequence number, then you can inject a wrench into the cogs and the endpoints will reject all legitimate traffic from each other.
- jeroenhd 2y ago
  That's only true if you use the kernel TCP stack. You can replicate the slow QUIC stack and do everything in user mode to get control back over what packets you accept (i.e. reject any that don't fit your TLS stream).