3 ms·

Essentially. It's HTTP semantics on top of QUIC on top of UDP. Google and Microsoft open-washed their implementions designed for mega-corp use cases through the

Essentially. It's HTTP semantics on top of QUIC on top of UDP. Google and Microsoft open-washed their implementions designed for mega-corp use cases through the IETF and now it's called HTTP/3. One special feature of HTTP/3 as implemented that's really good for for-profit use cases but terrible for human person use cases is that it cannot establish a connection to a non-CA TLS endpoint. That is, you want a random internet visitor to be able to visit your HTTP/3 website, you have to get continued approval from a third party incorporated CA. This makes it pretty much useless for things like IoT and human uses at home. But it's great for things involving money.

still_grokking 3y ago
Could you please stop spreading uninformed FUD? > it cannot establish a connection to a non-CA TLS endpoint That's plain wrong. Self signed certificates and internal CAs work just fine. The whole point of HTTP/3 is: You can't establish an unencrypted connection. And that's a very good idea! I'm running at the very moment a HTTP/3 development server on this machine here. I did not have to ask anybody for allowance to do so. (Actually I'm right now building a WebTransport server. WebTransport has even more strict rules for certificates but even there it's still possible to connect to an endpoint that uses a self-signed cert that isn't signed by any CA cert.)
- superkuh 3y ago
  > Could you please stop spreading uninformed FUD? Inform me then. Did you compile boringssl or openssl+quic or whatever TLS lib yourself and enable the proper flags so you could do this? You and I both know that doesn't count. You certainly can't if you're using a binary distributed browser made by Microsoft, Google, Apple, or even Mozilla. If you look at the traffic you're sending it's probably hitting the HTTP/1.1 endpoint first then going to http/3 for further traffic. Internal CAs work but that's internal and irrelevant to being able to host a visitable website to a random persons. >You can't establish an unencrypted connection. And that's a very good idea! That's a very good idea for incorporated persons and their websites that involve transfers of money and other private details. The trade-off is that the entire system is more fragile and complex and needs continous constant updating and approval from a third party corporation. These are very bad traits for making a personal website that can last more than a few years. It's bad for the longevity of the web and so it's health.
  - still_grokking 3y ago
    > Did you compile boringssl or openssl+quic or whatever TLS lib yourself and enable the proper flags so you could do this? No, I did not. > You certainly can't if you're using a binary distributed browser made by Microsoft, Google, Apple, or even Mozilla. That's the part that simply isn't true. I'm using for testing a Chromium derivative with a stock Blink engine (Vivaldi). You can use self signed certs just fine. (But using a custom CA set up by `mkcert` is actually the simplest way for a dev setup). Chrome has a `--ignore-certificate-errors-spki-list=${CERT_HASH}` flag enabling the use of self signed certs for HTTP/3, given the right cert hash. I admit that this isn't something an average user could do. You need to invoke some `openssl` voodoo to generate the hash appropriate for usage with the mentioned browser flag from a given cert. But that's actually a feature, imho, as it makes talking someone into casually starting their browser with this flag for some arbitrary domain quite difficult, or in a lot of cases even impossible. (And the addition of CA certs by an unauthorized user can be prevented by other means). For WebTransport (where it's anticipated that the endpoints could be quite well some ephemeral machines, maybe even without DNS records) you can pass just a cert's sha1 fingerprint to the `WebTransport` constructor on the user agent. This will make the browser accept the designated (self signed) cert without any further checks. > If you look at the traffic you're sending it's probably hitting the HTTP/1.1 endpoint first then going to http/3 for further traffic. No, I don't even have a HTTP/1 (or /2) endpoint in this setup. I need to pass `--origin-to-force-quic-on=localhost` explicitly as Google's engine is otherwise too stupid to recognize the HTTP/3 server. (ALPN seems to have currently also issue besides this, judging from some comments online. But I'm not using this mechanism anyway currently, and have just a pure HTTP/3 endpoint.) > That's a very good idea for incorporated persons and their websites that involve transfers of money and other private details. It's a good idea in general. Have you ever considered that alone knowing who visits which website when is privacy related information? Meta-data is often even considered more interesting than the actual data. The USA stated boldly things like: "We kill people based on metadata"… Encrypting just everything is the only way forward! Otherwise sending or receiving encrypted traffic already would be a data point as such—a data point which could be used against some. > The trade-off is that the entire system is more fragile and complex […] Yes, it's a trade-off. Also, I think that the CA system is fundamentally broken. But this is nothing new coming with QUIC! > […] and needs continous constant updating and approval from a third party corporation. These are very bad traits for making a personal website that can last more than a few years. I'm not buying this argument any more. Before something like Let's Encrypt you've been right with that argument. But since then this point is moot. You don't need any "approval", you just need to prove that you own the domain for which you like to have a cert. This is a completely automatic and anonymous process. Set up once it will work as long as something like Let's Encrypt exists. (And Let's Encrypt very likely won't disappear anytime soon!) > It's bad for the longevity of the web and so it's health. No, it makes no difference. An unmaintained website will go away sooner or later anyway. You need at least to pay bills to keep it up. At least… But besides that this point is also moot. Nothing of this whole digital stuff will last very long. Ever tried to open an ancient file format? By ancient I don't mean 20 000 years old like some stone carvings, I don't mean 2 000 years like some papyrus role, not even 200 years like some a little bit older book, I mean a file as "ancient" as something made by some firm that went out of business 20 years ago… And talking about "health" in the context of the web given the current state of the internet is a joke in its own. I don't want to offend anybody but that's just the truth. The web is broken beyond repair. And that's mostly not even for technical reasons. (Even there would be also more than enough of those. But QUIC is actually one of the technologies that are more or less sane—even complex—and a step in the right direction. Every middle-box it kills on its way is a huge win for the net!)

still_grokking 3y ago

Could you please stop spreading uninformed FUD? > it cannot establish a connection to a non-CA TLS endpoint That's plain wrong. Self signed certificates and internal CAs work just fine. The whole point of HTTP/3 is: You can't establish an unencrypted connection. And that's a very good idea! I'm running at the very moment a HTTP/3 development server on this machine here. I did not have to ask anybody for allowance to do so. (Actually I'm right now building a WebTransport server. WebTransport has even more strict rules for certificates but even there it's still possible to connect to an endpoint that uses a self-signed cert that isn't signed by any CA cert.)

superkuh 3y ago
> Could you please stop spreading uninformed FUD? Inform me then. Did you compile boringssl or openssl+quic or whatever TLS lib yourself and enable the proper flags so you could do this? You and I both know that doesn't count. You certainly can't if you're using a binary distributed browser made by Microsoft, Google, Apple, or even Mozilla. If you look at the traffic you're sending it's probably hitting the HTTP/1.1 endpoint first then going to http/3 for further traffic. Internal CAs work but that's internal and irrelevant to being able to host a visitable website to a random persons. >You can't establish an unencrypted connection. And that's a very good idea! That's a very good idea for incorporated persons and their websites that involve transfers of money and other private details. The trade-off is that the entire system is more fragile and complex and needs continous constant updating and approval from a third party corporation. These are very bad traits for making a personal website that can last more than a few years. It's bad for the longevity of the web and so it's health.
- still_grokking 3y ago
  > Did you compile boringssl or openssl+quic or whatever TLS lib yourself and enable the proper flags so you could do this? No, I did not. > You certainly can't if you're using a binary distributed browser made by Microsoft, Google, Apple, or even Mozilla. That's the part that simply isn't true. I'm using for testing a Chromium derivative with a stock Blink engine (Vivaldi). You can use self signed certs just fine. (But using a custom CA set up by `mkcert` is actually the simplest way for a dev setup). Chrome has a `--ignore-certificate-errors-spki-list=${CERT_HASH}` flag enabling the use of self signed certs for HTTP/3, given the right cert hash. I admit that this isn't something an average user could do. You need to invoke some `openssl` voodoo to generate the hash appropriate for usage with the mentioned browser flag from a given cert. But that's actually a feature, imho, as it makes talking someone into casually starting their browser with this flag for some arbitrary domain quite difficult, or in a lot of cases even impossible. (And the addition of CA certs by an unauthorized user can be prevented by other means). For WebTransport (where it's anticipated that the endpoints could be quite well some ephemeral machines, maybe even without DNS records) you can pass just a cert's sha1 fingerprint to the `WebTransport` constructor on the user agent. This will make the browser accept the designated (self signed) cert without any further checks. > If you look at the traffic you're sending it's probably hitting the HTTP/1.1 endpoint first then going to http/3 for further traffic. No, I don't even have a HTTP/1 (or /2) endpoint in this setup. I need to pass `--origin-to-force-quic-on=localhost` explicitly as Google's engine is otherwise too stupid to recognize the HTTP/3 server. (ALPN seems to have currently also issue besides this, judging from some comments online. But I'm not using this mechanism anyway currently, and have just a pure HTTP/3 endpoint.) > That's a very good idea for incorporated persons and their websites that involve transfers of money and other private details. It's a good idea in general. Have you ever considered that alone knowing who visits which website when is privacy related information? Meta-data is often even considered more interesting than the actual data. The USA stated boldly things like: "We kill people based on metadata"… Encrypting just everything is the only way forward! Otherwise sending or receiving encrypted traffic already would be a data point as such—a data point which could be used against some. > The trade-off is that the entire system is more fragile and complex […] Yes, it's a trade-off. Also, I think that the CA system is fundamentally broken. But this is nothing new coming with QUIC! > […] and needs continous constant updating and approval from a third party corporation. These are very bad traits for making a personal website that can last more than a few years. I'm not buying this argument any more. Before something like Let's Encrypt you've been right with that argument. But since then this point is moot. You don't need any "approval", you just need to prove that you own the domain for which you like to have a cert. This is a completely automatic and anonymous process. Set up once it will work as long as something like Let's Encrypt exists. (And Let's Encrypt very likely won't disappear anytime soon!) > It's bad for the longevity of the web and so it's health. No, it makes no difference. An unmaintained website will go away sooner or later anyway. You need at least to pay bills to keep it up. At least… But besides that this point is also moot. Nothing of this whole digital stuff will last very long. Ever tried to open an ancient file format? By ancient I don't mean 20 000 years old like some stone carvings, I don't mean 2 000 years like some papyrus role, not even 200 years like some a little bit older book, I mean a file as "ancient" as something made by some firm that went out of business 20 years ago… And talking about "health" in the context of the web given the current state of the internet is a joke in its own. I don't want to offend anybody but that's just the truth. The web is broken beyond repair. And that's mostly not even for technical reasons. (Even there would be also more than enough of those. But QUIC is actually one of the technologies that are more or less sane—even complex—and a step in the right direction. Every middle-box it kills on its way is a huge win for the net!)