[superkuh]

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/

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).

[chrismorgan]

> 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]

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:

> 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 (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).

[jefftk]

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]

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

[jefftk]

> 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/

[mistrial9]

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

[benmmurphy]

        curl -kv https://self-signed.badssl.com/
        *   Trying 104.154.89.105:443...
        * TCP_NODELAY set
        * Connected to self-signed.badssl.com (104.154.89.105) port 443 (#0)
        * ALPN, offering http/1.1
        * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
        * successfully set certificate verify locations:
        *   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
        CApath: none
        * TLSv1.2 (OUT), TLS header, Certificate Status (22):
        * TLSv1.2 (OUT), TLS handshake, Client hello (1):
        * TLSv1.2 (IN), TLS handshake, Server hello (2):
        * TLSv1.2 (IN), TLS handshake, Certificate (11):
        * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
        * TLSv1.2 (IN), TLS handshake, Server finished (14):
        * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
        * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
        * TLSv1.2 (OUT), TLS handshake, Finished (20):
        * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
        * TLSv1.2 (IN), TLS handshake, Finished (20):
        * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
        * ALPN, server accepted to use http/1.1
        * Server certificate:
        *  subject: C=US; ST=California; L=San Francisco; O=BadSSL; CN=*.badssl.com
        *  start date: Aug 12 15:59:10 2022 GMT
        *  expire date: Aug 11 15:59:10 2024 GMT
        *  issuer: C=US; ST=California; L=San Francisco; O=BadSSL; CN=*.badssl.com
        *  SSL certificate verify result: self signed certificate (18), continuing anyway.
        > GET / HTTP/1.1
        > Host: self-signed.badssl.com
        > User-Agent: curl/7.65.1
        > Accept: */*
        > 
        * Mark bundle as not supporting multiuse
        < HTTP/1.1 200 OK
        < Server: nginx/1.10.3 (Ubuntu)
        < Date: Fri, 21 Oct 2022 18:41:58 GMT
        < Content-Type: text/html
        < Content-Length: 502
        < Last-Modified: Fri, 12 Aug 2022 15:59:21 GMT
        < Connection: keep-alive
        < ETag: "62f678d9-1f6"
        < Cache-Control: no-store
        < Accept-Ranges: bytes
        <

[mistrial9]

yes minus-k says "less checking, generally proceed" but does it remember that certificate? maybe not

[nl]

This seems like it... works exactly as intended?

If you decide you trust that certificate (which can be a legitimate thing to do - the cert signature could be communicated to you via out-of-band trusted mechanisms) then https://curl.se/docs/sslcerts.html explains how to trust it.

[jefftk]

Among other things that's saying it's a self-signed cert and can do HTTP2. So that Chrome on my phone will connect to it does confirm that you can do self-signed certs with HTTP2 at least.

[nrb]

> HTTP is OK with ME

How do you propose to secure user sessions and prevent MITM or tracking otherwise?

[bombcar]

That battle is mostly lost anyway - the web is what Google and Apple let you see for the most part for most users.

[mistrial9]

I encourage you to take solace in stories of courage and invention at this challenging time in history.