3 ms·

> soon most web applications will switch to using HTTP/3 implemented on QUIC so they won't even be using HTTP. HTTP/3 is definitely still HTTP. QUIC is replaci

by cmckn 4y ago

> soon most web applications will switch to using HTTP/3 implemented on QUIC so they won't even be using HTTP. HTTP/3 is definitely still HTTP. QUIC is replacing TCP.

superkuh 4y ago
HTTP/3 is HTTP because Google and Microsoft said so and had the people in place to push it through the IETF. It's not really HTTP like HTTP/1.1 was and is; designed for human people to interact with for web sites made out of pages. It's a protocol designed for web applications. This is so deep in it's core it won't even allow you to connect to another IP unless you get continuing approval from an incorporated entity running a CA to lease a TLS cert.
- Seirdy 4y ago
  QUIC does not require a CA. Self-signed or DANE-backed TLS certificates work fine. Try using cURL built with HTTP/3 support to see for yourself. Requiring CAs and not implementing support for other anchors of trust is an implementation decision, and is not mandated by the spec. The spec mandates TLS 1.3, not "the version of TLS 1.3 used by these three web browsers". QUIC was designed with non-browser use in mind too; it's for any situation where you want to maintain connection integrity in an unreliable network.
  - superkuh 4y ago
    True in theory, not true in practice. It might work if all the random people on the internet used cURL to visit my websites but they tend to use browsers that are Chrome based. And Chrome's QUIC (or the underlying quiche library) differs how Chrome's H1 and H2 implement TLS. It will not accept a self-signed cert during a HTTP3 QUIC connection. Even going localhost (defeats the point, but to check) and trying --disable_certificate_verification --allow-insecure-localhost will not work. Like I said, the megacorps that designed QUIC designed it for their use cases and that does not include allowing human people to host websites by themselves. Not if it potentially impacts e-commerce security. Their implementations reflect this.

by cmckn 4y ago

> soon most web applications will switch to using HTTP/3 implemented on QUIC so they won't even be using HTTP. HTTP/3 is definitely still HTTP. QUIC is replacing TCP.

superkuh 4y ago

HTTP/3 is HTTP because Google and Microsoft said so and had the people in place to push it through the IETF. It's not really HTTP like HTTP/1.1 was and is; designed for human people to interact with for web sites made out of pages. It's a protocol designed for web applications. This is so deep in it's core it won't even allow you to connect to another IP unless you get continuing approval from an incorporated entity running a CA to lease a TLS cert.

Seirdy 4y ago
QUIC does not require a CA. Self-signed or DANE-backed TLS certificates work fine. Try using cURL built with HTTP/3 support to see for yourself. Requiring CAs and not implementing support for other anchors of trust is an implementation decision, and is not mandated by the spec. The spec mandates TLS 1.3, not "the version of TLS 1.3 used by these three web browsers". QUIC was designed with non-browser use in mind too; it's for any situation where you want to maintain connection integrity in an unreliable network.
- superkuh 4y ago
  True in theory, not true in practice. It might work if all the random people on the internet used cURL to visit my websites but they tend to use browsers that are Chrome based. And Chrome's QUIC (or the underlying quiche library) differs how Chrome's H1 and H2 implement TLS. It will not accept a self-signed cert during a HTTP3 QUIC connection. Even going localhost (defeats the point, but to check) and trying --disable_certificate_verification --allow-insecure-localhost will not work. Like I said, the megacorps that designed QUIC designed it for their use cases and that does not include allowing human people to host websites by themselves. Not if it potentially impacts e-commerce security. Their implementations reflect this.