4 ms·

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

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.
  - jefftk 4y ago
    The ways in which MITM attacks are dangerous are not limited to sites running JavaScript. The big one is that MITM can change what you see on sites. I should be able to trust that everything I read on superkuh.com is your writing, but today anyone operating a network node between my browser and your server can make arbitrary edits to your work.
    - superkuh 4y ago
      I agree. But this doesn't matter for the vast majority of websites (ie, non-commercial, non-institutional, personal websites). You can change it so it says or shows whatever and it's not going to hurt anyone. Just like requiring everyone to wear a level 3 bullet proof vest while making dinner will make the process safer, so will requiring CA based certs. And in this particular exact scenario, you can use my .onion site for superkuh.com to verify the end-point identity if you're really worried that someone might change the text. A system that works without CAs.
      - afiori 4y ago
        It matters if you have concerns about the experience users have on your site. Among other things a MitM can: - insert ads in your page - run miners on your user's browser - change links or redirect the page (likely to an CA-signed malware site) - insert malware in downloadable scripts on your site (http://superkuh.com/TkTTS.pl http://superkuh.com/TkTTS.pl)
  - nixgeek 4y ago
    On Windows and using Chrome as an example you’d set: Software\Policies\Google\Chrome,SSLErrorOverrideAllowed,REG_DWORD,1
- johannes1234321 4y ago
  For public facing things this is likely good. For my own home use it is quite an annoyance. The thing I wonder: will this prevent Internet of Sh*t devices to spread or will they become fully reliant on cloud, thus dependent on the vendor (as the customer's browser won't talk to it)
jefftk 4y ago
> HTTP/1.1 going away will be the death of the personal website. How does requiring HTTPS turn into no more personal websites? Let's Encrypt offers free certificates with automated renewal and minimal hassle, and if you don't like them there are several free alternatives.
- superkuh 4y ago
  First is the obvious increase in complexity and fragility of websites requiring re-approval every 90 (or whatever) days. A personal website made of .html and other files in the past would last, literally forever. Now require HTTPS and ACME(1/2/whatever) based re-approval and at some point that complex stack of software (who's complexity is hidden from the user) will break. The website will become inaccessible and die. And not only does it make them more fragile but it makes setting up a website for the first time much more complex. The second is more abstract but notice how literally everyone in this thread is recommending LetsEncrypt. That's great, and I love LE and I'm really glad they exist. But this is literally putting all our eggs in one basket. The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites. Like, say, a website for an abortion clinic that is now against the law in Texas. Switching to comodo when this happens won't fix it.
  - jefftk 4y ago
    > A personal website made of .html and other files in the past would last, literally forever. Web serving has always had moving parts, and there has always been some maintenance required to keep sites up. I agree that HTTPS increases the burden here, but not from zero. > at some point that complex stack of software (who's complexity is hidden from the user) will break Sort of? People definitely screw up their HTTPS configuration from time to time, or run into bugs. But the acme software is very reliable, so this is rare, and if it does happen blowing your existing configuration away and starting fresh will fix it. > And not only does it make them more fragile but it makes setting up a website for the first time much more complex. If you want to set up a website with minimal steps you generally get someone else to host, at which point they are dealing with HTTPS. If you want to do it all yourself HTTPS does add a step, but it is small compared to all of the other steps involved in setting up a server. > The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites. The US legal system cannot currently compel Let's Encrypt to refuse service to lawbreaking sites, and even if the law changed here you could get a certificate from a CA in another country.
wbl 4y ago
The solution is a few minutes of setting up ACME away
- dpkirchner 4y ago
  And in fact you can do this almost automatically the next time you upgrade your webserver to resolve security issues. It's about as easy as it can get, easier than a lot of things people do every week (shopping, etc).
  - superkuh 4y ago
    If you think an acme using website is going to remain accessible when left unattended for a decade I have a bridge to sell you. acme 1 didn't even last a handful of years. And that's ignoring the dozens of ways every individual acme package can and do fail even before the protocol becomes obsoleted. Moving parts break. Even if the complexity is hidden from you it is still there. And lets not even get into root cert churn. Remember when LE's original root cert stopped working a couple years ago? HTTPS only, CA TLS only, leads to websites with lifetimes that max out around several years. This is fine for corporate/institutions as nothing of theirs lasts this long anyway. But it's a huge problem with personal sites which remain useful and valuable for longer time periods.
    - dpkirchner 4y ago
      It doesn't need to last a decade no more than does a web server. We have to upgrade software, it's just a fact of life. I don't really understand the objection on those grounds. It sounds like you just don't want to do it for other reasons.
jeroenhd 4y ago
I can't find much about this in the HTTP/3 spec. Validation of certificates must be done according to section 4.3.4 of RFC9110 which explicitly spells out that browsers must either get permission to continue or abort, but that's up to the browser to decide. I can find some references to Chrome's QUIC not supporting self signed certificates, but I can't find any source that says that WebKit and Firefox made the same decision. Do you happen to know a self signed HTTP/3 URL that I can test this with? Browsers choosing to break self signed certificates can happen even with HTTP 0.9. All they need to do is require the user to type the bypass phrase ("thisisunsafe" in the Chrome error screen) on any certificate validation error and enable HTTPS only mode. This has nothing to do with spec. Browsers have even removed spec implementations for HTTP/2 spec (HTTP push) after a few years.

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.
- jefftk 4y ago
  The ways in which MITM attacks are dangerous are not limited to sites running JavaScript. The big one is that MITM can change what you see on sites. I should be able to trust that everything I read on superkuh.com is your writing, but today anyone operating a network node between my browser and your server can make arbitrary edits to your work.
  - superkuh 4y ago
    I agree. But this doesn't matter for the vast majority of websites (ie, non-commercial, non-institutional, personal websites). You can change it so it says or shows whatever and it's not going to hurt anyone. Just like requiring everyone to wear a level 3 bullet proof vest while making dinner will make the process safer, so will requiring CA based certs. And in this particular exact scenario, you can use my .onion site for superkuh.com to verify the end-point identity if you're really worried that someone might change the text. A system that works without CAs.
    - afiori 4y ago
      It matters if you have concerns about the experience users have on your site. Among other things a MitM can: - insert ads in your page - run miners on your user's browser - change links or redirect the page (likely to an CA-signed malware site) - insert malware in downloadable scripts on your site (http://superkuh.com/TkTTS.pl http://superkuh.com/TkTTS.pl)
- nixgeek 4y ago
  On Windows and using Chrome as an example you’d set: Software\Policies\Google\Chrome,SSLErrorOverrideAllowed,REG_DWORD,1
johannes1234321 4y ago
For public facing things this is likely good. For my own home use it is quite an annoyance. The thing I wonder: will this prevent Internet of Sh*t devices to spread or will they become fully reliant on cloud, thus dependent on the vendor (as the customer's browser won't talk to it)

jefftk 4y ago

> HTTP/1.1 going away will be the death of the personal website. How does requiring HTTPS turn into no more personal websites? Let's Encrypt offers free certificates with automated renewal and minimal hassle, and if you don't like them there are several free alternatives.

superkuh 4y ago
First is the obvious increase in complexity and fragility of websites requiring re-approval every 90 (or whatever) days. A personal website made of .html and other files in the past would last, literally forever. Now require HTTPS and ACME(1/2/whatever) based re-approval and at some point that complex stack of software (who's complexity is hidden from the user) will break. The website will become inaccessible and die. And not only does it make them more fragile but it makes setting up a website for the first time much more complex. The second is more abstract but notice how literally everyone in this thread is recommending LetsEncrypt. That's great, and I love LE and I'm really glad they exist. But this is literally putting all our eggs in one basket. The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites. Like, say, a website for an abortion clinic that is now against the law in Texas. Switching to comodo when this happens won't fix it.
- jefftk 4y ago
  > A personal website made of .html and other files in the past would last, literally forever. Web serving has always had moving parts, and there has always been some maintenance required to keep sites up. I agree that HTTPS increases the burden here, but not from zero. > at some point that complex stack of software (who's complexity is hidden from the user) will break Sort of? People definitely screw up their HTTPS configuration from time to time, or run into bugs. But the acme software is very reliable, so this is rare, and if it does happen blowing your existing configuration away and starting fresh will fix it. > And not only does it make them more fragile but it makes setting up a website for the first time much more complex. If you want to set up a website with minimal steps you generally get someone else to host, at which point they are dealing with HTTPS. If you want to do it all yourself HTTPS does add a step, but it is small compared to all of the other steps involved in setting up a server. > The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites. The US legal system cannot currently compel Let's Encrypt to refuse service to lawbreaking sites, and even if the law changed here you could get a certificate from a CA in another country.

wbl 4y ago

The solution is a few minutes of setting up ACME away

dpkirchner 4y ago
And in fact you can do this almost automatically the next time you upgrade your webserver to resolve security issues. It's about as easy as it can get, easier than a lot of things people do every week (shopping, etc).
- superkuh 4y ago
  If you think an acme using website is going to remain accessible when left unattended for a decade I have a bridge to sell you. acme 1 didn't even last a handful of years. And that's ignoring the dozens of ways every individual acme package can and do fail even before the protocol becomes obsoleted. Moving parts break. Even if the complexity is hidden from you it is still there. And lets not even get into root cert churn. Remember when LE's original root cert stopped working a couple years ago? HTTPS only, CA TLS only, leads to websites with lifetimes that max out around several years. This is fine for corporate/institutions as nothing of theirs lasts this long anyway. But it's a huge problem with personal sites which remain useful and valuable for longer time periods.
  - dpkirchner 4y ago
    It doesn't need to last a decade no more than does a web server. We have to upgrade software, it's just a fact of life. I don't really understand the objection on those grounds. It sounds like you just don't want to do it for other reasons.

jeroenhd 4y ago

I can't find much about this in the HTTP/3 spec. Validation of certificates must be done according to section 4.3.4 of RFC9110 which explicitly spells out that browsers must either get permission to continue or abort, but that's up to the browser to decide. I can find some references to Chrome's QUIC not supporting self signed certificates, but I can't find any source that says that WebKit and Firefox made the same decision. Do you happen to know a self signed HTTP/3 URL that I can test this with? Browsers choosing to break self signed certificates can happen even with HTTP 0.9. All they need to do is require the user to type the bypass phrase ("thisisunsafe" in the Chrome error screen) on any certificate validation error and enable HTTPS only mode. This has nothing to do with spec. Browsers have even removed spec implementations for HTTP/2 spec (HTTP push) after a few years.