6 ms·

HTTP/3 is written for the use case of large corporations and does not even allow for human persons to use it alone. It requires CA based TLS to set up a connect

HTTP/3 is written for the use case of large corporations and does not even allow for human persons to use it alone. It requires CA based TLS to set up a connection. So if you want to host a website visitable by a random person you've never communicated with before you have to get continued permission from an incorporated entity running a CA to do so. This is far more of a security problem than all of the bad HTTP 1.1 implementations put together. It is built in corporate control that cannot be bypassed except by not using HTTP/3. It is extremely important that we not let the mega-corp browsers drop HTTP 1.1 and continue to write our own projects for it.

tambre 4y ago
Is there anything the spec that actually requires that? AFAIK it's just that major implementators (browsers) have chosen to enforce TLS.
- superkuh 4y ago
  The language in the RFC that Google and Microsoft forced through the IETF to open-wash it uses "MUST" in capital letters when talking about setting up the HTTP3 endpoint and verifying the cert. https://datatracker.ietf.org/doc/rfc9114/ https://datatracker.ietf.org/doc/rfc9114/ I would be extremely relieved if I am wrong and someone could explain how I am wrong. Like... maybe there's some mechanism to self-sign without CA and use a null cypher? So even if most users would be scared away geeks could click through (like today's status quo with self-signed ssl certs).
  - jefftk 4y ago
    You can still use a self-signed cert with HTTP3 (including rightly scary warnings for visitors) or you can make your own CA and distribute the cert (no scary warnings when people visit your site).
    - mistrial9 4y ago
      I will believe this when I see it, thank you the zealous "you must obey the law" tone of SOME comments here reinforces the worst stereotypes of corporate apparats.. individuals doing the bidding of institutions based on the letter of their "laws" Human history has shown again and again that this ends badly .. HTTP is OK with ME
      - bombcar 4y ago
        That battle is mostly lost anyway - the web is what Google and Apple let you see for the most part for most users.
        mistrial9 4y ago
        I encourage you to take solace in stories of courage and invention at this challenging time in history.
      - jefftk 4y ago
        > I will believe this when I see it, thank you I'm on my phone so I can't confirm this is http3, but how about https://self-signed.badssl.com/ https://self-signed.badssl.com/
        mistrial9 4y ago
        ok $ curl -v https://self-signed.badssl.com/ * Trying 104.154.89.105:443... * Connected to self-signed.badssl.com (104.154.89.105) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Certificate Status (22): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS header, Certificate Status (22): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS header, Unknown (21): * TLSv1.2 (OUT), TLS alert, unknown CA (560): * SSL certificate problem: self-signed certificate * Closing connection 0 curl: (60) SSL certificate problem: self-signed certificate More details here: https://curl.se/docs/sslcerts.html "curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above." $ curl --version curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.13 Release-Date: 2022-01-05 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd
  - chrismorgan 4y ago
    > the RFC that Google and Microsoft forced through the IETF to open-wash it This is a gross misrepresentation of the situation. Yes, Google played a significant role in the development of HTTP/2, QUIC and HTTP/3, providing the starting point for the development work in each case, but there was no open-washing: there was a collaborative process with the involvement of many interested parties, and the end result was significantly different from what was first proposed, and significantly better. This is how IETF works. Google did not control matters in any way, nor Microsoft.
  - chrismorgan 4y ago
    The TLS verification requirements laid on HTTP/3 are described in RFC 9114 §3.1 ¶2, https://www.rfc-editor.org/rfc/rfc9114#section-3.1-2 https://www.rfc-editor.org/rfc/rfc9114#section-3.1-2: > The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority component of the URI. Upon receiving a server certificate in the TLS handshake, the client MUST verify that the certificate is an acceptable match for the URI's origin server using the process described in Section 4.3.4 of [HTTP]. If the certificate cannot be verified with respect to the URI's origin server, the client MUST NOT consider the server authoritative for that origin. This boils down to “this is HTTPS, so the same rules as ever apply for matching the certificate and origin”. I suspect you’ve misunderstood what authoritativity conveys. The last sentence is saying “… and if verification fails, don’t trust the connection”—and it’s up to each app to decide what to do about that; browsers put up a scary warning error page that you can normally click through (depending on server configuration). Note that it doesn’t even hardcode the CA model; I like the way RFC 9110 §4.3.3 ¶1 puts it: “The client usually relies upon a chain of trust, conveyed from some prearranged or configured trust anchor, to deem a certificate trustworthy.” You can read more about the rules of HTTPS in https://www.rfc-editor.org/rfc/rfc9110#section-4.3.3 https://www.rfc-editor.org/rfc/rfc9110#section-4.3.3 (sections 4.3.3 and 4.3.4). Certificate verification is the same as ever, and the only difference between HTTP/1 and HTTP/2 and HTTP/3 is that HTTP/1 has connection-per-origin, where 2 and 3 can use a connection for multiple origins (§4.3.3 ¶2–3 spells it out).
- jshier 4y ago
  You're thinking of HTTP/2. The QUIC protocol that underlies HTTP/3 requires SSL all the time.
chrismorgan 4y ago
Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out sooner or later, first with the likes of scary address bar “insecure” badges, and probably within a decade by disabling http: by default in a way similar to Firefox’s HTTPS-Only Mode (puts up a network error page with the ability to temporarily enable HTTP for the site), though I doubt it’ll be removed for decades. And HTTP/1 at least over TLS will remain the baseline for decades to come—HTTP/2 could conceivably be dropped at some point, but HTTP/3 is very unlikely to ever become the baseline because it requires more setup effort. You can still use cleartext HTTP/1 at least for now if you want, but this functionality was rightly more or less removed in HTTP/2, and fully removed in HTTP/3. Pervasive monitoring is an attack (https://www.rfc-editor.org/rfc/rfc7258.html https://www.rfc-editor.org/rfc/rfc7258.html), and HTTP/2 and HTTP/3 are appropriately designed to mitigate it. Look, be real: the entire web is now built heavily on the CA model. If free issuance of certificates falters, the internet as we know it is in serious trouble. Deal with it. Social factors. This might conceivably happen, and if it does, HTTP/1 will not save you. In fact, cleartext HTTP/1 will be just about the first thing to die (be blocked) in the most likely relevant sequence of events.
- TheFlyingFish 4y ago
  I agree that sending cleartext over the internet in this day and age is a bad idea. But "encrypt all communication at the application layer" doesn't have to be the only solution. There's also "encrypt communication at the <i>network</i> layer," as discussed here for example: https://tailscale.com/blog/remembering-the-lan/ https://tailscale.com/blog/remembering-the-lan/ I have a suspicion that this will prove to be a better abstraction than application-level encryption for everything. If I'm right, I would expect things to naturally start migrating in that direction over time. We'll see!
- jallmann 4y ago
  It is a layering violation though. Not all HTTP usage is through a browser, and not all routes go over the plaintext Internet. Browsers or clients can still require HTTPS at the application layer, but it shouldn't be part of the protocol spec. Suppose I have an app within an intranet that's secured with, say, Wireguard or an application-layer tunnel (eg, SSH or Openziti). Bringing HTTP/3 into the picture means dealing with CAs and certs on top of the provisioning I've already done for my lower layers, possibly leaking information via Certificate Transparency logs. Then the cost of double-encryption, etc.
insanitybit 4y ago
Can you not just have it use a self signed certificate? I don't see why a CA would need to be involved at all, nor can I even imagine how that could be enforced at the protocol level. This sounds like a red herring to me. edit: Yeah I've more or less confirmed that self signed certs are perfectly fine in HTTP3. This is a big ball of nothing.
- rootusrootus 4y ago
  About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.
  - bornfreddy 4y ago
    > I have to type the magic key sequence to bypass the error. 8 keys? f + i + r + e + f + o + x + Enter?
    - count 4y ago
      'thisisunsafe' to answer the actual question
  - snowwrestler 4y ago
    If you control both the server and the client, you can make yourself your own private CA, issue all the certs you need, and have no browser errors anywhere.
  - insanitybit 4y ago
    Add the certificate to your trusted store? HTTP3 will change nothing about this.
    - skrtskrt 4y ago
Natsu 4y ago
I mean, if it's on the open web you can use Let's Encrypt. If it's on your private network, you can make whatever keys you want with XCA and trust your self-made CA in browsers.

tambre 4y ago

Is there anything the spec that actually requires that? AFAIK it's just that major implementators (browsers) have chosen to enforce TLS.

superkuh 4y ago
The language in the RFC that Google and Microsoft forced through the IETF to open-wash it uses "MUST" in capital letters when talking about setting up the HTTP3 endpoint and verifying the cert. https://datatracker.ietf.org/doc/rfc9114/ https://datatracker.ietf.org/doc/rfc9114/ I would be extremely relieved if I am wrong and someone could explain how I am wrong. Like... maybe there's some mechanism to self-sign without CA and use a null cypher? So even if most users would be scared away geeks could click through (like today's status quo with self-signed ssl certs).
- jefftk 4y ago
  You can still use a self-signed cert with HTTP3 (including rightly scary warnings for visitors) or you can make your own CA and distribute the cert (no scary warnings when people visit your site).
  - mistrial9 4y ago
    I will believe this when I see it, thank you the zealous "you must obey the law" tone of SOME comments here reinforces the worst stereotypes of corporate apparats.. individuals doing the bidding of institutions based on the letter of their "laws" Human history has shown again and again that this ends badly .. HTTP is OK with ME
    - bombcar 4y ago
      That battle is mostly lost anyway - the web is what Google and Apple let you see for the most part for most users.
      - mistrial9 4y ago
        I encourage you to take solace in stories of courage and invention at this challenging time in history.
    - jefftk 4y ago
      > I will believe this when I see it, thank you I'm on my phone so I can't confirm this is http3, but how about https://self-signed.badssl.com/ https://self-signed.badssl.com/
      - mistrial9 4y ago
        ok $ curl -v https://self-signed.badssl.com/ * Trying 104.154.89.105:443... * Connected to self-signed.badssl.com (104.154.89.105) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Certificate Status (22): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS header, Certificate Status (22): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS header, Unknown (21): * TLSv1.2 (OUT), TLS alert, unknown CA (560): * SSL certificate problem: self-signed certificate * Closing connection 0 curl: (60) SSL certificate problem: self-signed certificate More details here: https://curl.se/docs/sslcerts.html "curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above." $ curl --version curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.13 Release-Date: 2022-01-05 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd
- chrismorgan 4y ago
  > the RFC that Google and Microsoft forced through the IETF to open-wash it This is a gross misrepresentation of the situation. Yes, Google played a significant role in the development of HTTP/2, QUIC and HTTP/3, providing the starting point for the development work in each case, but there was no open-washing: there was a collaborative process with the involvement of many interested parties, and the end result was significantly different from what was first proposed, and significantly better. This is how IETF works. Google did not control matters in any way, nor Microsoft.
- chrismorgan 4y ago
  The TLS verification requirements laid on HTTP/3 are described in RFC 9114 §3.1 ¶2, https://www.rfc-editor.org/rfc/rfc9114#section-3.1-2 https://www.rfc-editor.org/rfc/rfc9114#section-3.1-2: > The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority component of the URI. Upon receiving a server certificate in the TLS handshake, the client MUST verify that the certificate is an acceptable match for the URI's origin server using the process described in Section 4.3.4 of [HTTP]. If the certificate cannot be verified with respect to the URI's origin server, the client MUST NOT consider the server authoritative for that origin. This boils down to “this is HTTPS, so the same rules as ever apply for matching the certificate and origin”. I suspect you’ve misunderstood what authoritativity conveys. The last sentence is saying “… and if verification fails, don’t trust the connection”—and it’s up to each app to decide what to do about that; browsers put up a scary warning error page that you can normally click through (depending on server configuration). Note that it doesn’t even hardcode the CA model; I like the way RFC 9110 §4.3.3 ¶1 puts it: “The client usually relies upon a chain of trust, conveyed from some prearranged or configured trust anchor, to deem a certificate trustworthy.” You can read more about the rules of HTTPS in https://www.rfc-editor.org/rfc/rfc9110#section-4.3.3 https://www.rfc-editor.org/rfc/rfc9110#section-4.3.3 (sections 4.3.3 and 4.3.4). Certificate verification is the same as ever, and the only difference between HTTP/1 and HTTP/2 and HTTP/3 is that HTTP/1 has connection-per-origin, where 2 and 3 can use a connection for multiple origins (§4.3.3 ¶2–3 spells it out).
jshier 4y ago
You're thinking of HTTP/2. The QUIC protocol that underlies HTTP/3 requires SSL all the time.

chrismorgan 4y ago

Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out sooner or later, first with the likes of scary address bar “insecure” badges, and probably within a decade by disabling http: by default in a way similar to Firefox’s HTTPS-Only Mode (puts up a network error page with the ability to temporarily enable HTTP for the site), though I doubt it’ll be removed for decades. And HTTP/1 at least over TLS will remain the baseline for decades to come—HTTP/2 could conceivably be dropped at some point, but HTTP/3 is very unlikely to ever become the baseline because it requires more setup effort. You can still use cleartext HTTP/1 at least for now if you want, but this functionality was rightly more or less removed in HTTP/2, and fully removed in HTTP/3. Pervasive monitoring is an attack (https://www.rfc-editor.org/rfc/rfc7258.html https://www.rfc-editor.org/rfc/rfc7258.html), and HTTP/2 and HTTP/3 are appropriately designed to mitigate it. Look, be real: the entire web is now built heavily on the CA model. If free issuance of certificates falters, the internet as we know it is in serious trouble. Deal with it. Social factors. This might conceivably happen, and if it does, HTTP/1 will not save you. In fact, cleartext HTTP/1 will be just about the first thing to die (be blocked) in the most likely relevant sequence of events.

TheFlyingFish 4y ago
I agree that sending cleartext over the internet in this day and age is a bad idea. But "encrypt all communication at the application layer" doesn't have to be the only solution. There's also "encrypt communication at the <i>network</i> layer," as discussed here for example: https://tailscale.com/blog/remembering-the-lan/ https://tailscale.com/blog/remembering-the-lan/ I have a suspicion that this will prove to be a better abstraction than application-level encryption for everything. If I'm right, I would expect things to naturally start migrating in that direction over time. We'll see!
jallmann 4y ago
It is a layering violation though. Not all HTTP usage is through a browser, and not all routes go over the plaintext Internet. Browsers or clients can still require HTTPS at the application layer, but it shouldn't be part of the protocol spec. Suppose I have an app within an intranet that's secured with, say, Wireguard or an application-layer tunnel (eg, SSH or Openziti). Bringing HTTP/3 into the picture means dealing with CAs and certs on top of the provisioning I've already done for my lower layers, possibly leaking information via Certificate Transparency logs. Then the cost of double-encryption, etc.

insanitybit 4y ago

Can you not just have it use a self signed certificate? I don't see why a CA would need to be involved at all, nor can I even imagine how that could be enforced at the protocol level. This sounds like a red herring to me. edit: Yeah I've more or less confirmed that self signed certs are perfectly fine in HTTP3. This is a big ball of nothing.

rootusrootus 4y ago
About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.
- bornfreddy 4y ago
  > I have to type the magic key sequence to bypass the error. 8 keys? f + i + r + e + f + o + x + Enter?
  - count 4y ago
    'thisisunsafe' to answer the actual question
- snowwrestler 4y ago
  If you control both the server and the client, you can make yourself your own private CA, issue all the certs you need, and have no browser errors anywhere.
- insanitybit 4y ago
  Add the certificate to your trusted store? HTTP3 will change nothing about this.
  - skrtskrt 4y ago

Natsu 4y ago

I mean, if it's on the open web you can use Let's Encrypt. If it's on your private network, you can make whatever keys you want with XCA and trust your self-made CA in browsers.