3 ms·

QUIC is TCP+TLS. HTTP is done as a separate layer on top. The benefits are: future protocol evolution (TCP is extremely difficult to change because of middlebo

by uluyol 6y ago

QUIC is TCP+TLS. HTTP is done as a separate layer on top. The benefits are: future protocol evolution (TCP is extremely difficult to change because of middleboxes, QUIC encrypts almost all of the header to stop middleboxes from messing things up) faster connection establishment (fewer RTTs thanks to bundling TCP+TLS handshakes), no head-of-line blocking when sending multiply streams over a single connection.

paulryanrogers 6y ago
Is this sustainable though? Won't the middle boxes adapt?
- judge2020 6y ago
  Almost nothing is plaintext so iterations can be done within the encrypted layer. Iterations could start being done at the same speed that http is done today.
  - oarsinsync 6y ago
    Middleboxes by design MITM connections. They'll terminate the connection from the client and the server, unencrypt and reencrypt as necessary. That's the whole point of the troublesome middleboxes. They're not passive listeners. They're active participants, with fragile implementations.
    - cmckn 6y ago
      One does not simply “unencrypt” traffic, though. That’s the whole point of TLS.
      - oarsinsync 6y ago
        Indeed, one intercepts and terminates the TCP (or now UDP) session. No version of TLS is immune to these middleboxes. I suspect I'm being misunderstood. I don't intend to suggest these pasky middleboxes spring up randomly on the Internet and anyone is at risk. These are deliberately installed on the edge of corporate networks, and their sole purpose is to intercept, unencrypt and filter traffic. There's no technological solution for a middleware box that emulates a client to servers, and emulates a server to clients, and is operating exactly as designed. This shouldn't be new or surprising or groundbreaking to anyone. It's just a fancy name for a poorly implemented proxy.
        floatboth 6y ago
        Default configurations – without tampering by corporate admins – are of course immune. Application layer developers are fighting corporate TLS interception with things like certificate pinning, not using the OS certificate store, making it harder to modify the app's certificate store. The goal is to heavily discourage corporations from breaking end-to-end security to spy on their employees.
        jlokier 6y ago
        It is relatively easy to override certificate pins by modifying the browser that's installed on the corporate network. In those places where they are adding a "trusted" local middlebox CA to the client for interception, modifying the browser's pin store (or its logic) is not such a big stretch on top of that. At least other devices, such as users own devices on the corporate network, are immune to this.
    - detaro 6y ago
      No, "middleboxes" does not just refer to MITM proxies, but a whole slew of things (many of which are broken in various different ways).
    - tialaramex 6y ago
      > Middleboxes by design MITM connections. If only this was true. Almost all of TLS 1.3 would be more straight forward if you were right. As a trivial example, clients could begin by saying they want to speak TLS 1.3 rather than pretending they want TLS 1.2 even though they actually don't. Implementing a security device as back-to-back proxy in which there are two connections, one from a client to the device, then another from the device to the server, would be entirely compliant with the standard, it would trivially enable forward compatibility, and it would make it easier to reason about the provided security features (if any). But it would make them (much) more expensive. The true purpose of such middleboxes is not security, it is to transfer money from gullible customers to the vendor. "Security" is just an excuse, if they thought you'd buy it to prevent COVID-19 that's what they would claim it does. So, a common trick went like this: When a client makes an HTTPS connection, you let it ride, but you passively watch the first few packets they receive. You're looking for the X.509 certificate from the server, which you will then inspect to figure out if it's somebody you trust. If not, you reset the connection and next time they try you intercept, perhaps to display a "Warning: Unauthorized Terror Porn Gay Propaganda Web Site. Your Boss Has Been Notified" message. Notice this doesn't actually provide any security at all, X.509 certificates are public documents, my servers can give you the certificate for Google, or a local hospital, or PornHub, even though I am not in fact Google, a local hospital or PornHub. The middlebox won't know this was bogus because the protocol only proves the server knows the keys for this certificate to the client not a third party eavesdropping. But this "trick" does break TLS 1.3 as originally designed because since a plaintext X.509 certificate is only useful for snooping and provides no security benefit it is now encrypted, and these middleboxes would freak out. So what was done about that? Well they don't actually provide any security so we just sidestepped it. TLS 1.3 claims to be a TLS 1.2 resumption. "Oh you were already talking to this server about something else. I'm sure I must have checked that time and it was fine. On you go" says the middlebox. This worked very well for their actual purpose, as you can see from the revenues of middlebox suppliers.
  - ocdtrekkie 6y ago
    Expect middleboxes to aggressively block QUIC and similar harmful adtech products designed to circumvent inspection and security.
- jlokier 6y ago
  It's designed with almost everything encrypted so that middleboxes can't inspect the contents of packets and filter or change them. This is essential, as it's been found that middleboxes now break almost every kind of experimental protocol that's not shielded in this way. So it's designed very much to resist ossification and allow protocol evolution. Still, some vendors are adapting to QUIC by blocking QUIC: https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/ https://www.fastvue.co/fastvue/blog/googles-quic-protocols-s... Resolving the QUIC issue The good news is that if QUIC communication does not work between a client and a server, the traffic will fall back to traditional HTTP/HTTPS over TCP, where it can be inspected, controlled, logged and reported on as usual. At the time of writing, the advice from most firewall vendors is to block QUIC until support is officially added to their products. This recommended method will vary from firewall to firewall. Some firewalls allow QUIC by default while others block it by default, but all firewalls are able to allow or block it. It's not really true that everything QUIC falls back to HTTP/HTTPS, as there are non-HTTP applications running over QUIC too. That kind of blocking is going to cause pain to the people I know who are implementing QUIC-only products. But it's not a new problem. WebSockets doesn't work everywhere either, even UDP does not work everywhere. HTTP is also a problem because some middleboxes modify responses (even if you don't care about privacy that breaks applications). The strongest fallback I know of in practice is HTTPS, but some places block HTTPS or modify the certificates, and some filter on the HTTPS domain which is visible in the TLS negotiation.
anticensor 6y ago
QUIC is more similar to UDP+SCTP+TLS. Or, if you skip UDP and directly layer it over IP, to SCTP+TLS.

by uluyol 6y ago

paulryanrogers 6y ago

Is this sustainable though? Won't the middle boxes adapt?

judge2020 6y ago
Almost nothing is plaintext so iterations can be done within the encrypted layer. Iterations could start being done at the same speed that http is done today.
- oarsinsync 6y ago
  Middleboxes by design MITM connections. They'll terminate the connection from the client and the server, unencrypt and reencrypt as necessary. That's the whole point of the troublesome middleboxes. They're not passive listeners. They're active participants, with fragile implementations.
  - cmckn 6y ago
    One does not simply “unencrypt” traffic, though. That’s the whole point of TLS.
    - oarsinsync 6y ago
      Indeed, one intercepts and terminates the TCP (or now UDP) session. No version of TLS is immune to these middleboxes. I suspect I'm being misunderstood. I don't intend to suggest these pasky middleboxes spring up randomly on the Internet and anyone is at risk. These are deliberately installed on the edge of corporate networks, and their sole purpose is to intercept, unencrypt and filter traffic. There's no technological solution for a middleware box that emulates a client to servers, and emulates a server to clients, and is operating exactly as designed. This shouldn't be new or surprising or groundbreaking to anyone. It's just a fancy name for a poorly implemented proxy.
      - floatboth 6y ago
        Default configurations – without tampering by corporate admins – are of course immune. Application layer developers are fighting corporate TLS interception with things like certificate pinning, not using the OS certificate store, making it harder to modify the app's certificate store. The goal is to heavily discourage corporations from breaking end-to-end security to spy on their employees.
        jlokier 6y ago
        It is relatively easy to override certificate pins by modifying the browser that's installed on the corporate network. In those places where they are adding a "trusted" local middlebox CA to the client for interception, modifying the browser's pin store (or its logic) is not such a big stretch on top of that. At least other devices, such as users own devices on the corporate network, are immune to this.
  - detaro 6y ago
    No, "middleboxes" does not just refer to MITM proxies, but a whole slew of things (many of which are broken in various different ways).
  - tialaramex 6y ago
    > Middleboxes by design MITM connections. If only this was true. Almost all of TLS 1.3 would be more straight forward if you were right. As a trivial example, clients could begin by saying they want to speak TLS 1.3 rather than pretending they want TLS 1.2 even though they actually don't. Implementing a security device as back-to-back proxy in which there are two connections, one from a client to the device, then another from the device to the server, would be entirely compliant with the standard, it would trivially enable forward compatibility, and it would make it easier to reason about the provided security features (if any). But it would make them (much) more expensive. The true purpose of such middleboxes is not security, it is to transfer money from gullible customers to the vendor. "Security" is just an excuse, if they thought you'd buy it to prevent COVID-19 that's what they would claim it does. So, a common trick went like this: When a client makes an HTTPS connection, you let it ride, but you passively watch the first few packets they receive. You're looking for the X.509 certificate from the server, which you will then inspect to figure out if it's somebody you trust. If not, you reset the connection and next time they try you intercept, perhaps to display a "Warning: Unauthorized Terror Porn Gay Propaganda Web Site. Your Boss Has Been Notified" message. Notice this doesn't actually provide any security at all, X.509 certificates are public documents, my servers can give you the certificate for Google, or a local hospital, or PornHub, even though I am not in fact Google, a local hospital or PornHub. The middlebox won't know this was bogus because the protocol only proves the server knows the keys for this certificate to the client not a third party eavesdropping. But this "trick" does break TLS 1.3 as originally designed because since a plaintext X.509 certificate is only useful for snooping and provides no security benefit it is now encrypted, and these middleboxes would freak out. So what was done about that? Well they don't actually provide any security so we just sidestepped it. TLS 1.3 claims to be a TLS 1.2 resumption. "Oh you were already talking to this server about something else. I'm sure I must have checked that time and it was fine. On you go" says the middlebox. This worked very well for their actual purpose, as you can see from the revenues of middlebox suppliers.
- ocdtrekkie 6y ago
  Expect middleboxes to aggressively block QUIC and similar harmful adtech products designed to circumvent inspection and security.
jlokier 6y ago
It's designed with almost everything encrypted so that middleboxes can't inspect the contents of packets and filter or change them. This is essential, as it's been found that middleboxes now break almost every kind of experimental protocol that's not shielded in this way. So it's designed very much to resist ossification and allow protocol evolution. Still, some vendors are adapting to QUIC by blocking QUIC: https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/ https://www.fastvue.co/fastvue/blog/googles-quic-protocols-s... Resolving the QUIC issue The good news is that if QUIC communication does not work between a client and a server, the traffic will fall back to traditional HTTP/HTTPS over TCP, where it can be inspected, controlled, logged and reported on as usual. At the time of writing, the advice from most firewall vendors is to block QUIC until support is officially added to their products. This recommended method will vary from firewall to firewall. Some firewalls allow QUIC by default while others block it by default, but all firewalls are able to allow or block it. It's not really true that everything QUIC falls back to HTTP/HTTPS, as there are non-HTTP applications running over QUIC too. That kind of blocking is going to cause pain to the people I know who are implementing QUIC-only products. But it's not a new problem. WebSockets doesn't work everywhere either, even UDP does not work everywhere. HTTP is also a problem because some middleboxes modify responses (even if you don't care about privacy that breaks applications). The strongest fallback I know of in practice is HTTPS, but some places block HTTPS or modify the certificates, and some filter on the HTTPS domain which is visible in the TLS negotiation.

anticensor 6y ago

QUIC is more similar to UDP+SCTP+TLS. Or, if you skip UDP and directly layer it over IP, to SCTP+TLS.