7 ms·

It's sad to see these kinds of posts from universities who were connected to the internet early on. (the blog is hosted on AS239) This blog post itself served

by miyuru 4y ago

It's sad to see these kinds of posts from universities who were connected to the internet early on. (the blog is hosted on AS239) This blog post itself served from HTTP/1.1 and IPv4 for me. I guess the improving internet is handed over to the big companies who benefit them.

j16sdiz 4y ago
Benefit them, not us. They have no incentive to hold backward compatibility and putting smaller websites offline
superkuh 4y ago
I strongly disagree. HTTP/3 was a google's protocol and they and microsoft used their employees on the IETF to open-wash it. It is designed exclusively for the use cases of corporations and institutions to the detriment to the use cases of human persons. For example, you will not find any implementation of HTTP/3 that allows you to connect to another computer without that computer first getting continual approval from a third party corporation or institution. That is, you can't just connect to a friend's HTTP/3 web server, or your own HTTP/3 server on your LAN with any browser (or otherwise HTTP/3 client) out there. First you have to ask, say, LetsEncrypt for permission. HTTP/3 is not for human people. It's for corporate people and it will serve them well. But please don't mistake not using HTTP/2 or HTTP/3 with their corporate crap as being backwards. It's the the other way around. I'll be sad when the web dies and all we're left with is Google's centrally controlled QUIC.
- jeroenhd 4y ago
  Are you saying self signed certificates and custom certificate authorities are banned in HTTP/3? Because as far as I know, there's absolutely nothing stopping you from setting up your own crypto if you don't like certificate authorities.
  - superkuh 4y ago
    All current HTTP/3 implementations will not let you use a self-signed cert. Without the CA root it will not connect. The spec for HTTP/3 says this should be the default. There are compile-time flags you can use to enable it but with Google/Microsoft/Apple browsers all not, good luck being able to have people connect to your site. I'm saying that there is no way for me to distribute and install my custom CA into the browsers of every random person around the globe that will try to visit my website on software defined radio. I've self-signed my website(s) for 20 years now. In the past it did not matter. But over the last few years I've noticed that actual browser connections are disappearing and all that's left is http bots. They're the only HTTP clients not failing to load my page because of $browsers HTTPS only configuration causing them to see my self-signed cert and thus the browser scaremongering about it causing them to close the tab. HTTP/1.1 going away will be the death of the personal website.
    - nixgeek 4y ago
      No, most browsers do allow configuring this, but it’s no longer a simple “click through a warning”. Maybe that means the death of the personal website run by someone who refuses to get a certificate which chains to something publicly trusted and compliant with CA/B baselines, but I’d argue that’s actually a good thing — we would obviously disagree on this but I view this as removing easy ways for end users to do insecure things.
      - superkuh 4y ago
        >no, most browsers do allow configuring this, Really? Are you sure about that? I'd love to believe you as it'd mean there's been progress on this front but the last time I checked it required compile time flags in Chrome and Firefox. The problem is that this is a function of the libraries these browsers use, it's not an option that is within the browser itself. >removing easy ways for end users to do insecure things. That's a legit pov as long as you think about browsers as in the for-profit way: as insecure virtual machines for customers to run your untrusted third party code. And that's certainly the zeitgeist. But that's not what the web is to many human people. The web of documents still exists despite the last decade of the web just being a mechanism to distribute JS applications. I know that the for-profit point of view doesn't care about the web of documents (not profitable) but that doesn't make their use case the only use case. All you have to do to make accepting self-signed certs as secure (or more secure) than the "normal" web is to turn off automatic execution of untrusted code sent to you. I'd wager that a good fraction of the HN userbase already does this with their NoScript or uBlock or whatever anti-javascript protection extensions.
- peterkelly 4y ago
  The problems you described are specific to implementations, not the protocol itself. I have read all of the QUIC specs in full (since I'm working on an implementation) and have seen nothing in any of them that mandates a centralised certificate infrastructure (caveat: I have not read the HTTP/3 spec, perhaps you could point out the relevant section if its in there). Of course, the most common use case requires this, but in that respect it's no different to HTTPS. IPFS uses QUIC as one of its supported transport protocols, and this works in the most common implementation, Kubo [1]. The spec for the QUIC transport used in IPFS [2] indicates the same certificate trust policy as for the TLS protocol [3]. The latter, in turn, relies on peer-to-peer authentication with automatically-generated self-signed certificates containing a libp2p-specific additional extension. IPFS is particularly well suited to the use case of personal websites you've mentioned, as it's specifically designed to operate without any form of centralisation. [1] https://github.com/ipfs/kubo https://github.com/ipfs/kubo. [2] https://github.com/libp2p/specs/tree/master/quic https://github.com/libp2p/specs/tree/master/quic [3] https://github.com/libp2p/specs/blob/master/tls/tls.md https://github.com/libp2p/specs/blob/master/tls/tls.md
- tiberious726 4y ago
  If you care about this kind of stuff just run your own CA. X.509 sucks, but it's orthogonal to http3

by miyuru 4y ago

j16sdiz 4y ago

Benefit them, not us. They have no incentive to hold backward compatibility and putting smaller websites offline

superkuh 4y ago

I strongly disagree. HTTP/3 was a google's protocol and they and microsoft used their employees on the IETF to open-wash it. It is designed exclusively for the use cases of corporations and institutions to the detriment to the use cases of human persons. For example, you will not find any implementation of HTTP/3 that allows you to connect to another computer without that computer first getting continual approval from a third party corporation or institution. That is, you can't just connect to a friend's HTTP/3 web server, or your own HTTP/3 server on your LAN with any browser (or otherwise HTTP/3 client) out there. First you have to ask, say, LetsEncrypt for permission. HTTP/3 is not for human people. It's for corporate people and it will serve them well. But please don't mistake not using HTTP/2 or HTTP/3 with their corporate crap as being backwards. It's the the other way around. I'll be sad when the web dies and all we're left with is Google's centrally controlled QUIC.

jeroenhd 4y ago
Are you saying self signed certificates and custom certificate authorities are banned in HTTP/3? Because as far as I know, there's absolutely nothing stopping you from setting up your own crypto if you don't like certificate authorities.
- superkuh 4y ago
  All current HTTP/3 implementations will not let you use a self-signed cert. Without the CA root it will not connect. The spec for HTTP/3 says this should be the default. There are compile-time flags you can use to enable it but with Google/Microsoft/Apple browsers all not, good luck being able to have people connect to your site. I'm saying that there is no way for me to distribute and install my custom CA into the browsers of every random person around the globe that will try to visit my website on software defined radio. I've self-signed my website(s) for 20 years now. In the past it did not matter. But over the last few years I've noticed that actual browser connections are disappearing and all that's left is http bots. They're the only HTTP clients not failing to load my page because of $browsers HTTPS only configuration causing them to see my self-signed cert and thus the browser scaremongering about it causing them to close the tab. HTTP/1.1 going away will be the death of the personal website.
  - nixgeek 4y ago
    No, most browsers do allow configuring this, but it’s no longer a simple “click through a warning”. Maybe that means the death of the personal website run by someone who refuses to get a certificate which chains to something publicly trusted and compliant with CA/B baselines, but I’d argue that’s actually a good thing — we would obviously disagree on this but I view this as removing easy ways for end users to do insecure things.
    - superkuh 4y ago
      >no, most browsers do allow configuring this, Really? Are you sure about that? I'd love to believe you as it'd mean there's been progress on this front but the last time I checked it required compile time flags in Chrome and Firefox. The problem is that this is a function of the libraries these browsers use, it's not an option that is within the browser itself. >removing easy ways for end users to do insecure things. That's a legit pov as long as you think about browsers as in the for-profit way: as insecure virtual machines for customers to run your untrusted third party code. And that's certainly the zeitgeist. But that's not what the web is to many human people. The web of documents still exists despite the last decade of the web just being a mechanism to distribute JS applications. I know that the for-profit point of view doesn't care about the web of documents (not profitable) but that doesn't make their use case the only use case. All you have to do to make accepting self-signed certs as secure (or more secure) than the "normal" web is to turn off automatic execution of untrusted code sent to you. I'd wager that a good fraction of the HN userbase already does this with their NoScript or uBlock or whatever anti-javascript protection extensions.
peterkelly 4y ago
The problems you described are specific to implementations, not the protocol itself. I have read all of the QUIC specs in full (since I'm working on an implementation) and have seen nothing in any of them that mandates a centralised certificate infrastructure (caveat: I have not read the HTTP/3 spec, perhaps you could point out the relevant section if its in there). Of course, the most common use case requires this, but in that respect it's no different to HTTPS. IPFS uses QUIC as one of its supported transport protocols, and this works in the most common implementation, Kubo [1]. The spec for the QUIC transport used in IPFS [2] indicates the same certificate trust policy as for the TLS protocol [3]. The latter, in turn, relies on peer-to-peer authentication with automatically-generated self-signed certificates containing a libp2p-specific additional extension. IPFS is particularly well suited to the use case of personal websites you've mentioned, as it's specifically designed to operate without any form of centralisation. [1] https://github.com/ipfs/kubo https://github.com/ipfs/kubo. [2] https://github.com/libp2p/specs/tree/master/quic https://github.com/libp2p/specs/tree/master/quic [3] https://github.com/libp2p/specs/blob/master/tls/tls.md https://github.com/libp2p/specs/blob/master/tls/tls.md
tiberious726 4y ago
If you care about this kind of stuff just run your own CA. X.509 sucks, but it's orthogonal to http3