5 ms·

If HTTP/1.1 is deprecated from all browsers, and HTTP/3 eventually becomes the only way to view a web page, then it will be impossible to host a localnet web pa

If HTTP/1.1 is deprecated from all browsers, and HTTP/3 eventually becomes the only way to view a web page, then it will be impossible to host a localnet web page (ex. a wifi router). The people pushing this standard through don't make routers, so they don't give a shit, and everyone on the planet will just be screwed. This is what happens when we let 1 or 2 companies run the internet for us

paradite 3y ago
Pardon my knowledge. If we are to get very technical instead of for average people, surely you can self-sign a cert and setup your CA chain on the computers in your local network? Or is there something else that prevents you from hosting HTTP/3 locally?
- jrmg 3y ago
  Knowing how to do that is quite a high barrier to entry.
  - utybo 3y ago
    Couldn't mkcert handle most of that process?
  - throwjdn 3y ago
    [dead]
- taway1237 3y ago
  As far as I know, browsers don't allow self-signed certificates on HTTP/3. This was mentioned by people in comments here, and quick google seems to confirm.
  - Majestic121 3y ago
    You cannot use a certificate that was not signed by a trusted CA, but nothing keeps you from creating your own CA, making it trusted locally, and using it to sign your cert
    - mgaunard 3y ago
      Nothing except convenience and compatibility with dozens of operating systems that might operate on the network. Can you even easily do it on Android? Without an Internet connection?
    - koito17 3y ago
      > making it trusted locally That is precisely the problem. Most proprietary systems don't let you touch the trust store at all. Even "open" platforms like Android have been locking down the ability to do anything to the trust store.[1] With that said, if we assume the user is only using Google Chrome and not an alternative browser, then typing "thisisunsafe" on the TLS error page should let one elide trust store modifications entirely. I cannot guarantee this is the case for HTTP/3 since the reverse proxies I deal with still use HTTP/2. [1] https://httptoolkit.com/blog/android-14-breaks-system-certificate-installation/ https://httptoolkit.com/blog/android-14-breaks-system-certif...
    - throwaway892238 3y ago
      One might then ask: why not just let the user click a button in the browser to see the page, without jumping through all those hoops? How does increased human toil make it better? (Spoiler: it doesn't)
  - throwjdn 3y ago
    [dead]
SoftTalker 3y ago
Look for routers that run an ssh server or have a serial console I guess.
- dybber 3y ago
  Just use a proper browser
cryptonector 3y ago
Impossible because you'd need a server certificate? But you can issue it yourself and add a trust anchor to your browsers.
paulddraper 3y ago
> If HTTP/1.1 is deprecated from all browsers If HTTP/1.1, HTTP/2, and HTTP/3 is deprecated from all browsers the World Wide Web would shut down. WWW is in danger! /s
WorldMaker 3y ago
Routers today are already dealing with this problem because Chrome throws major security warnings for any unencrypted HTTP traffic. The current solutions I've seen are to use things like Let's Encrypt/ACME certificates for wildcard sub-domains *.routercompanylocal.tld and a bit of secure handshake magic to register temporary A/AAAA records for link-local IP addresses (DNS has no problem advertising link-local addresses) and pass the private parts of the certificate down to the local hardware. Several major consumer routers I've seen will auto-route users to something like https://some-guid.theircompanyrouterlocal.tld https://some-guid.theircompanyrouterlocal.tld and everything just works including a CA chain usually up to Let's Encrypt. Doing Let's Encrypt/ACME for random localnet web pages is getting easier all the time and anyone can use that wildcard domain loophole if they want to build their own secure bootstrap protocols for localnet. It would be great if the ACME protocol more directly supported it than through the wildcard domain name loopholes currently in use, and that may come with time/demand. I imagine there are a lot of hard security questions that would need to be answered before a generally available "localnet ACME" could be devised (obviously every router manufacturer is currently keeping their secure handshakes proprietary because they can't afford to leak those certificates to would be MITM attacks), but I'm sure a lot of smart minds exist to build it given enough time and priority.
- dark-star 3y ago
  for routers there's a simple and easy workaround. Let's say your router answers on "router.lan". All they would have to do is redirect this name via the router's DNS resolver to, say, 192-168-0-1.company.com, which would be an officially-registered domain that resolves back to ... wait for it... 192.168.0.1! If you control company.com you can run wildcard DNS for any amount of "private" IP addresses, complete with an official and valid trusted certificate. For an internal IP address. Problem solved. (and no, this is not theoretical, there were appliances some 10+ years ago that did exactly that...)
  - WorldMaker 3y ago
    Yeah, that is mostly what I was describing. There's some rough security benefit to using more transient A/AAAA records under a GUID or other pseudo-random DNS name than a DNS zone that just encodes common link local addresses. There are definite security benefits to a company using mycompanyrouters.com instead of their home company.com (XSS scripting attacks and the like). So some things have changed over 10+ years, but yes the basic principles at this point are pretty old and certainly working in practice.
cjblomqvist 3y ago
Google actually makes a router?

paradite 3y ago

Pardon my knowledge. If we are to get very technical instead of for average people, surely you can self-sign a cert and setup your CA chain on the computers in your local network? Or is there something else that prevents you from hosting HTTP/3 locally?

jrmg 3y ago
Knowing how to do that is quite a high barrier to entry.
- utybo 3y ago
  Couldn't mkcert handle most of that process?
- throwjdn 3y ago
  [dead]
taway1237 3y ago
As far as I know, browsers don't allow self-signed certificates on HTTP/3. This was mentioned by people in comments here, and quick google seems to confirm.
- Majestic121 3y ago
  You cannot use a certificate that was not signed by a trusted CA, but nothing keeps you from creating your own CA, making it trusted locally, and using it to sign your cert
  - mgaunard 3y ago
    Nothing except convenience and compatibility with dozens of operating systems that might operate on the network. Can you even easily do it on Android? Without an Internet connection?
  - koito17 3y ago
    > making it trusted locally That is precisely the problem. Most proprietary systems don't let you touch the trust store at all. Even "open" platforms like Android have been locking down the ability to do anything to the trust store.[1] With that said, if we assume the user is only using Google Chrome and not an alternative browser, then typing "thisisunsafe" on the TLS error page should let one elide trust store modifications entirely. I cannot guarantee this is the case for HTTP/3 since the reverse proxies I deal with still use HTTP/2. [1] https://httptoolkit.com/blog/android-14-breaks-system-certificate-installation/ https://httptoolkit.com/blog/android-14-breaks-system-certif...
  - throwaway892238 3y ago
    One might then ask: why not just let the user click a button in the browser to see the page, without jumping through all those hoops? How does increased human toil make it better? (Spoiler: it doesn't)
- throwjdn 3y ago
  [dead]

SoftTalker 3y ago

Look for routers that run an ssh server or have a serial console I guess.

dybber 3y ago
Just use a proper browser

cryptonector 3y ago

Impossible because you'd need a server certificate? But you can issue it yourself and add a trust anchor to your browsers.

paulddraper 3y ago

> If HTTP/1.1 is deprecated from all browsers If HTTP/1.1, HTTP/2, and HTTP/3 is deprecated from all browsers the World Wide Web would shut down. WWW is in danger! /s

WorldMaker 3y ago

Routers today are already dealing with this problem because Chrome throws major security warnings for any unencrypted HTTP traffic. The current solutions I've seen are to use things like Let's Encrypt/ACME certificates for wildcard sub-domains *.routercompanylocal.tld and a bit of secure handshake magic to register temporary A/AAAA records for link-local IP addresses (DNS has no problem advertising link-local addresses) and pass the private parts of the certificate down to the local hardware. Several major consumer routers I've seen will auto-route users to something like https://some-guid.theircompanyrouterlocal.tld https://some-guid.theircompanyrouterlocal.tld and everything just works including a CA chain usually up to Let's Encrypt. Doing Let's Encrypt/ACME for random localnet web pages is getting easier all the time and anyone can use that wildcard domain loophole if they want to build their own secure bootstrap protocols for localnet. It would be great if the ACME protocol more directly supported it than through the wildcard domain name loopholes currently in use, and that may come with time/demand. I imagine there are a lot of hard security questions that would need to be answered before a generally available "localnet ACME" could be devised (obviously every router manufacturer is currently keeping their secure handshakes proprietary because they can't afford to leak those certificates to would be MITM attacks), but I'm sure a lot of smart minds exist to build it given enough time and priority.

dark-star 3y ago
for routers there's a simple and easy workaround. Let's say your router answers on "router.lan". All they would have to do is redirect this name via the router's DNS resolver to, say, 192-168-0-1.company.com, which would be an officially-registered domain that resolves back to ... wait for it... 192.168.0.1! If you control company.com you can run wildcard DNS for any amount of "private" IP addresses, complete with an official and valid trusted certificate. For an internal IP address. Problem solved. (and no, this is not theoretical, there were appliances some 10+ years ago that did exactly that...)
- WorldMaker 3y ago
  Yeah, that is mostly what I was describing. There's some rough security benefit to using more transient A/AAAA records under a GUID or other pseudo-random DNS name than a DNS zone that just encodes common link local addresses. There are definite security benefits to a company using mycompanyrouters.com instead of their home company.com (XSS scripting attacks and the like). So some things have changed over 10+ years, but yes the basic principles at this point are pretty old and certainly working in practice.

cjblomqvist 3y ago

Google actually makes a router?