5 ms·

Users don’t need to care about the difference between HTTP, HTTP2, and HTTP3. It’s relevant only to browser engineers and server operators. There’s no reason t

Users don’t need to care about the difference between HTTP, HTTP2, and HTTP3. It’s relevant only to browser engineers and server operators. There’s no reason to ask everyone on the planet to change “https:” to “http3:” when we still can’t even reliably complete the “http:” to “https:” transition. We’ve learned that users simply do not care at all about “http:” or “https:”. We shouldn’t have to ask people to update their QR codes for HTTP3 just because we updated the protocol. Should we have introduced ftpp:// for passive FTP to distinguish it from classic FTP? No: it would only confuse users, cause frustration for pages linking to FTP urls, and both servers and clients are perfectly capable of negotiating this silently without surfacing it to the user. In general the pushback with HTTP3 is that site operators would rather not have to do the extra work to enable it. But from a user’s perspective, there is no work to enable it. It’s just https:// https:// like always and one day it gets faster. Sites that refuse to do the extra work to turn it on will be visibly slower than their peers once it’s widespread enough. If you believe that HTTP3 should have had its own URI spec, you would have needed to make that case a few years ago to the committee implementing it; it’s not going to change now. I assume their discussion about that is in the archives, and I expect it boils down to “this is not relevant to users, they should not be expected to care”.

jeffbee 6y ago
But users don't type or even see the URI scheme any more. It is also an implementation detail. I just think it's weird that we've left ourselves without any way to send a client directly to an HTTP/3 site. Instead they _must_ establish a TCP connection to the site and be redirected via Alt-Svc headers to HTTP/3.
- bastawhiz 6y ago
  What's the backwards compatibility story for that? Links just don't work for older browsers? Why spend all the time making H3 work seamlessly with H2 if we're only going to introduce a new scheme that only works in new HTTP clients?
- vitaliyf 6y ago
  I am not going to claim myself if this is "right" or "wrong" but there is some work on that being done via https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... - see https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...
  - floatingatoll 6y ago
    Previously, though only 2 comments across 4 posts: https://hn.algolia.com/?q=https%3A%2F%2Fblog.cloudflare.com%2Fspeeding-up-https-and-http-3-negotiation-with-dns%2F https://hn.algolia.com/?q=https%3A%2F%2Fblog.cloudflare.com%...
- ziml77 6y ago
  That's not true unless the server is set up to handle redirecting. Every time I go to unifi.home.arpa:8443 I get the message: Bad Request This combination of host and port requires TLS. I have to explicitly type the https:// https:// for it to work.
  - floatingatoll 6y ago
    To restate my comment in more precise terms, users do not care which protocol of { HTTP/0, HTTP/1, HTTP/2, HTTP/3 } their browser selects and uses when communicating with the remote server at whatever URL they entered. They expect the URL to work, and they don't care how. The Unifi issue you cite is due to a series of problems that are related to the http:// http:// to https:// https:// migration, most of which Unifi could have easily discovered and mitigated had they cared to. I'm really disappointed in Unifi here, but the browser is at fault, too. First: Your browser's fallback process for handling "the user entered an invalid URI" is attempting http:// http:// first, rather than https:// https:// first. Second: The Unifi is responding over http:// http:// with a completely useless error page, rather than a redirect to https:// https:// at the same port. Third: The Unifi probably isn't setting a Strict-Transport-Security header on responses to https://:8443 https://:8443, which means that your browser can't learn a better default. Fourth: If the Unifi's instructions tell you to enter "unifi.home.arpa:8443" rather than "https://unifi.home.arpa:8443 https://unifi.home.arpa:8443", their instructions are clearly wrong. (If you're not following their instructions precisely as written, that would explain your discover of the prior three; I can't say I blame you — I would have left it off too.)
- toast0 6y ago
  Elsewhere in the thread, it sounds like there's a DNS way to suggest http/3. If adoption is high, clients might end up doing something like happy eyeballs; send tcp syns as well as the udp equivalents, and use whichever comes back first or use them all but prefer the fastest one, etc.
  - tialaramex 6y ago
    According to Apple (I don't own an iPhone) if you have iOS 14 and go into the Experimental Features settings and turn on support for draft HTTP/3 then it will try to do SVCB (that's the "DNS way to suggest http/3") and if it concludes that HTTP/3 is possible and there's no contraindication it will race an HTTP/3 connection vs HTTP/2 If it notices that HTTP/3 always loses or fails, it will gradually stop trying on the rationale that your network is broken so it's a waste of time. If your site uses Cloudflare, this Just Works™ since Cloudflare will answer HTTP/3 and emit DNS records saying it speaks HTTP/3 so there's no new work for you. Otherwise, to enable it you'd need to either create SVCB records in your DNS (your DNS server may need to be updated) or use the Alt-Svc: feature and give up on the performance improvement for first visits.
    - floatingatoll 6y ago
      Home > Settings > Safari > Experimental Features, for Safari on iOS 14. Home > Settings > Developer, for anywhere in iOS 14 that uses the system HTTP library. Note that you'll need a device with development mode enabled for the latter. https://developer.apple.com/wwdc20/10111 https://developer.apple.com/wwdc20/10111 has more details near the end.
logicOnly 6y ago
One of my biggest complaints is how https flags text based websites for being dangerous. What danger could possibly happen if I'm reading about a Physical Therapy clinic? They don't take credit cards, there's no information for me to enter on the website. But unless the Physical Therapist knows how to manage the server, they get this scary warning. Maybe it isn't a big deal to US healthcare because they make lots of money. But I imagine there are others that don't have the technical abilities to upgrade to https. Could your grandma do it for her sewing store?
- xahrepap 6y ago
  The problem is you can't trust what you're reading to be from the source. Maybe the site doesn't take credit cards. But after a MITM it might suddenly start taking credit cards. And other things. Whatever the attacker wants! All in the seeming name of the origin.
  - jk700 6y ago
    MITM like that still works for most https websites because of the automatic domain validation by ACME-based certificate authorities. The only caveat is that now an attacker has to get a valid certificate, so first he has to do MITM on the route from the datacenters where CAs run validators to the datacenter where the website is hosted, which for most websites today is likely a long route crossing many countries, after that an attacker gets the exact capabilities as with MITMing http.
    - suprfsat 6y ago
      Feb 19, 2020: Multi-Perspective Validation Improves Domain Validation Security (https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat...)
      - jk700 6y ago
        That's the thing, they don't seem to bother actually addressing the problem and assume no other interception capability than hacking BGP. But we are talking here about exactly that, i.e. if you can intercept traffic in any other way somewhere close to a website or its nameservers - you can get a valid certificate and use it to MITM its visitors anywhere in the world where you can intercept traffic too. And in case of using big cloud providers for validation to "improve" security, this still likely pushes traffic from all of them through some big IX before reaching a datacenter with a website and at worst only adds a couple more points an attacker has to intercept traffic at to get the certificate. This is where all that centralization is really bad for security. It basically makes https a protection only against low effort MITM of last mile ISPs.

jeffbee 6y ago

But users don't type or even see the URI scheme any more. It is also an implementation detail. I just think it's weird that we've left ourselves without any way to send a client directly to an HTTP/3 site. Instead they _must_ establish a TCP connection to the site and be redirected via Alt-Svc headers to HTTP/3.

bastawhiz 6y ago
What's the backwards compatibility story for that? Links just don't work for older browsers? Why spend all the time making H3 work seamlessly with H2 if we're only going to introduce a new scheme that only works in new HTTP clients?
vitaliyf 6y ago
I am not going to claim myself if this is "right" or "wrong" but there is some work on that being done via https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... - see https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...
- floatingatoll 6y ago
  Previously, though only 2 comments across 4 posts: https://hn.algolia.com/?q=https%3A%2F%2Fblog.cloudflare.com%2Fspeeding-up-https-and-http-3-negotiation-with-dns%2F https://hn.algolia.com/?q=https%3A%2F%2Fblog.cloudflare.com%...
ziml77 6y ago
That's not true unless the server is set up to handle redirecting. Every time I go to unifi.home.arpa:8443 I get the message: Bad Request This combination of host and port requires TLS. I have to explicitly type the https:// https:// for it to work.
- floatingatoll 6y ago
  To restate my comment in more precise terms, users do not care which protocol of { HTTP/0, HTTP/1, HTTP/2, HTTP/3 } their browser selects and uses when communicating with the remote server at whatever URL they entered. They expect the URL to work, and they don't care how. The Unifi issue you cite is due to a series of problems that are related to the http:// http:// to https:// https:// migration, most of which Unifi could have easily discovered and mitigated had they cared to. I'm really disappointed in Unifi here, but the browser is at fault, too. First: Your browser's fallback process for handling "the user entered an invalid URI" is attempting http:// http:// first, rather than https:// https:// first. Second: The Unifi is responding over http:// http:// with a completely useless error page, rather than a redirect to https:// https:// at the same port. Third: The Unifi probably isn't setting a Strict-Transport-Security header on responses to https://:8443 https://:8443, which means that your browser can't learn a better default. Fourth: If the Unifi's instructions tell you to enter "unifi.home.arpa:8443" rather than "https://unifi.home.arpa:8443 https://unifi.home.arpa:8443", their instructions are clearly wrong. (If you're not following their instructions precisely as written, that would explain your discover of the prior three; I can't say I blame you — I would have left it off too.)
toast0 6y ago
Elsewhere in the thread, it sounds like there's a DNS way to suggest http/3. If adoption is high, clients might end up doing something like happy eyeballs; send tcp syns as well as the udp equivalents, and use whichever comes back first or use them all but prefer the fastest one, etc.
- tialaramex 6y ago
  According to Apple (I don't own an iPhone) if you have iOS 14 and go into the Experimental Features settings and turn on support for draft HTTP/3 then it will try to do SVCB (that's the "DNS way to suggest http/3") and if it concludes that HTTP/3 is possible and there's no contraindication it will race an HTTP/3 connection vs HTTP/2 If it notices that HTTP/3 always loses or fails, it will gradually stop trying on the rationale that your network is broken so it's a waste of time. If your site uses Cloudflare, this Just Works™ since Cloudflare will answer HTTP/3 and emit DNS records saying it speaks HTTP/3 so there's no new work for you. Otherwise, to enable it you'd need to either create SVCB records in your DNS (your DNS server may need to be updated) or use the Alt-Svc: feature and give up on the performance improvement for first visits.
  - floatingatoll 6y ago
    Home > Settings > Safari > Experimental Features, for Safari on iOS 14. Home > Settings > Developer, for anywhere in iOS 14 that uses the system HTTP library. Note that you'll need a device with development mode enabled for the latter. https://developer.apple.com/wwdc20/10111 https://developer.apple.com/wwdc20/10111 has more details near the end.

logicOnly 6y ago

One of my biggest complaints is how https flags text based websites for being dangerous. What danger could possibly happen if I'm reading about a Physical Therapy clinic? They don't take credit cards, there's no information for me to enter on the website. But unless the Physical Therapist knows how to manage the server, they get this scary warning. Maybe it isn't a big deal to US healthcare because they make lots of money. But I imagine there are others that don't have the technical abilities to upgrade to https. Could your grandma do it for her sewing store?

xahrepap 6y ago
The problem is you can't trust what you're reading to be from the source. Maybe the site doesn't take credit cards. But after a MITM it might suddenly start taking credit cards. And other things. Whatever the attacker wants! All in the seeming name of the origin.
- jk700 6y ago
  MITM like that still works for most https websites because of the automatic domain validation by ACME-based certificate authorities. The only caveat is that now an attacker has to get a valid certificate, so first he has to do MITM on the route from the datacenters where CAs run validators to the datacenter where the website is hosted, which for most websites today is likely a long route crossing many countries, after that an attacker gets the exact capabilities as with MITMing http.
  - suprfsat 6y ago
    Feb 19, 2020: Multi-Perspective Validation Improves Domain Validation Security (https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat...)
    - jk700 6y ago
      That's the thing, they don't seem to bother actually addressing the problem and assume no other interception capability than hacking BGP. But we are talking here about exactly that, i.e. if you can intercept traffic in any other way somewhere close to a website or its nameservers - you can get a valid certificate and use it to MITM its visitors anywhere in the world where you can intercept traffic too. And in case of using big cloud providers for validation to "improve" security, this still likely pushes traffic from all of them through some big IX before reaching a datacenter with a website and at worst only adds a couple more points an attacker has to intercept traffic at to get the certificate. This is where all that centralization is really bad for security. It basically makes https a protection only against low effort MITM of last mile ISPs.