6 ms·

Under "QUIC Issues" it mentions "Private QUIC" and offhandedly remarks that there is no way to use QUIC without CA based TLS which is built in. This means that

Under "QUIC Issues" it mentions "Private QUIC" and offhandedly remarks that there is no way to use QUIC without CA based TLS which is built in. This means that QUIC cannot be used without the continuing approval of a third party incorporated entity. This is a very serious problem when QUIC takes over in user software (made by megacorps) and eventually drops HTTP/1.1 support. It will be the end of the open web and the beginning of a corporate controlled one. Ignoring this extremely dangerous outcome of a QUIC only world, this write-up is excellent and really clears things up.

jacob019 4y ago
Does QUIC not work with self-signed certificates?
- dinosaurdynasty 4y ago
  Browsers probably won't support it. I know quinn (a rust QUIC library) definitely does, though you have to enable custom verification as a compile option (which is reasonable).
- zekica 4y ago
  Browsers support QUIC with self signed certificates. It doesn't work with HSTS but that is by-design.
jmillikin 4y ago
Operating a private CA is trivial, there are packages to automate it at every level from simple manual scripting to fully-automated ACME servers such as Boulder[0]. For proprietary software it's idiomatic to use a private CA for securing connections to a central server, to avoid the risk of DNS hijacking or a malicious third-party CA. For open-source software it will, definitionally, allow substituting different server key validation options for users who prefer to run their own servers. The only real problem QUIC's mandatory TLS causes is that localhost development becomes marginally more difficult, but even as someone who loves running my in-development stuff on localhost it's clear that the security of the internet as a whole is of far greater value. [0] https://github.com/letsencrypt/boulder https://github.com/letsencrypt/boulder
- superkuh 4y ago
  Operating a private CA + QUIC does not allow me to host my own website that is visitable by a random person on the internet. HTTP/1.1 does. Private CAs solve other problems for internal uses but not this big important one for the public web.
  - jmillikin 4y ago
    HTTP over plaintext TCP is obsolete in a similar way to Telnet (vs SSH) or FTP (vs SFTP). It took something like 20 years for support for FTP to be dropped from major user agents[0]. By the time the major browsers drop support for plaintext HTTP, that protocol will be as quaint and archaic as Gopher is today. (and we'll all be better off for it -- good riddance to anything ASCII-based or unauthenticated) [0] https://blog.mozilla.org/security/2021/07/20/stopping-ftp-support-in-firefox-90/ https://blog.mozilla.org/security/2021/07/20/stopping-ftp-su...
    - superkuh 4y ago
      I think even you will be surprised how fast Google drops HTTP/1.1 support in Chrome. Humanity won't be better off for it but commerce certainly will. And I guess that's all that matters.
    - 0x000xca0xfe 4y ago
      HTTP/1.1 is not obsolete -- HTTP/2 and HTTP/3 preserve basically all semantics. HTTP/1 is better than 2 and 3 in many cases, e.g. when you cannot afford the complexity like in tiny embedded devices, or when you just need to bootstrap a WebSocket, or you don't need TLS. HTTP/1.1 will be obsolete when intranets and tiny devices are obsolete. Well, it looks like that could become true...
      - deleted 4y ago
        [deleted]
    - skissane 4y ago
      > HTTP over plaintext TCP is obsolete in a similar way to Telnet (vs SSH) or FTP (vs SFTP). That’s not comparing apples and oranges-HTTPS was originally just (and often still is just) plaintext HTTP/1.x wrapped in TLS. Whereas, SFTP and SSH are not FTP/TELNET over TLS, they are completely separate protocols. FTPS and TELNETS are the original protocols over TLS, but have seen only limited adoption (mostly in mainframe environments, in which SSH and SFTP perform poorly.) Even HTTP 2 and 3 are just a binary encoding of the HTTP/1.x protocol over an encrypted transport. By contrast, SSH and SFTP are essentially unrelated protocols to TELNET and FTP, as opposed to just binary encodings of them. (The TELNET protocol is already non-text-based anyway-the data may be mostly text but the control messages have never been.)
jacob019 4y ago
I think it will be a very long time before HTTP/1.1 is dropped entirely. It will get more warnings, and eventually get locked behind feature flags, but it's still quite useful on the LAN and will be required by legacy business software for decades. I do think it's appropriate to deprecate it's use on the public Internet. Let's Encrypt is operated by ISRG, a 501(c)(3) nonprofit. TLS certificate signing is an imperfect solution, but it is distributed enough that I wouldn't call it corporate controlled.
jakeogh 4y ago
Exactly. It's 3rd party permission to speak, among other deliberate problems: https://news.ycombinator.com/item?id=20992508 https://news.ycombinator.com/item?id=20992508

jacob019 4y ago

Does QUIC not work with self-signed certificates?

dinosaurdynasty 4y ago
Browsers probably won't support it. I know quinn (a rust QUIC library) definitely does, though you have to enable custom verification as a compile option (which is reasonable).
zekica 4y ago
Browsers support QUIC with self signed certificates. It doesn't work with HSTS but that is by-design.

jmillikin 4y ago

Operating a private CA is trivial, there are packages to automate it at every level from simple manual scripting to fully-automated ACME servers such as Boulder[0]. For proprietary software it's idiomatic to use a private CA for securing connections to a central server, to avoid the risk of DNS hijacking or a malicious third-party CA. For open-source software it will, definitionally, allow substituting different server key validation options for users who prefer to run their own servers. The only real problem QUIC's mandatory TLS causes is that localhost development becomes marginally more difficult, but even as someone who loves running my in-development stuff on localhost it's clear that the security of the internet as a whole is of far greater value. [0] https://github.com/letsencrypt/boulder https://github.com/letsencrypt/boulder

superkuh 4y ago
Operating a private CA + QUIC does not allow me to host my own website that is visitable by a random person on the internet. HTTP/1.1 does. Private CAs solve other problems for internal uses but not this big important one for the public web.
- jmillikin 4y ago
  HTTP over plaintext TCP is obsolete in a similar way to Telnet (vs SSH) or FTP (vs SFTP). It took something like 20 years for support for FTP to be dropped from major user agents[0]. By the time the major browsers drop support for plaintext HTTP, that protocol will be as quaint and archaic as Gopher is today. (and we'll all be better off for it -- good riddance to anything ASCII-based or unauthenticated) [0] https://blog.mozilla.org/security/2021/07/20/stopping-ftp-support-in-firefox-90/ https://blog.mozilla.org/security/2021/07/20/stopping-ftp-su...
  - superkuh 4y ago
    I think even you will be surprised how fast Google drops HTTP/1.1 support in Chrome. Humanity won't be better off for it but commerce certainly will. And I guess that's all that matters.
  - 0x000xca0xfe 4y ago
    HTTP/1.1 is not obsolete -- HTTP/2 and HTTP/3 preserve basically all semantics. HTTP/1 is better than 2 and 3 in many cases, e.g. when you cannot afford the complexity like in tiny embedded devices, or when you just need to bootstrap a WebSocket, or you don't need TLS. HTTP/1.1 will be obsolete when intranets and tiny devices are obsolete. Well, it looks like that could become true...
    - deleted 4y ago
      [deleted]
  - skissane 4y ago
    > HTTP over plaintext TCP is obsolete in a similar way to Telnet (vs SSH) or FTP (vs SFTP). That’s not comparing apples and oranges-HTTPS was originally just (and often still is just) plaintext HTTP/1.x wrapped in TLS. Whereas, SFTP and SSH are not FTP/TELNET over TLS, they are completely separate protocols. FTPS and TELNETS are the original protocols over TLS, but have seen only limited adoption (mostly in mainframe environments, in which SSH and SFTP perform poorly.) Even HTTP 2 and 3 are just a binary encoding of the HTTP/1.x protocol over an encrypted transport. By contrast, SSH and SFTP are essentially unrelated protocols to TELNET and FTP, as opposed to just binary encodings of them. (The TELNET protocol is already non-text-based anyway-the data may be mostly text but the control messages have never been.)

jacob019 4y ago

I think it will be a very long time before HTTP/1.1 is dropped entirely. It will get more warnings, and eventually get locked behind feature flags, but it's still quite useful on the LAN and will be required by legacy business software for decades. I do think it's appropriate to deprecate it's use on the public Internet. Let's Encrypt is operated by ISRG, a 501(c)(3) nonprofit. TLS certificate signing is an imperfect solution, but it is distributed enough that I wouldn't call it corporate controlled.

jakeogh 4y ago

Exactly. It's 3rd party permission to speak, among other deliberate problems: https://news.ycombinator.com/item?id=20992508 https://news.ycombinator.com/item?id=20992508