Anyone know why there's no new URL scheme for HTTP/3? We didn't rely on Alt-Svc headers for switching to HTTPS. We gave it its own scheme. Why aren't we doing that for HTTP/3?
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:// 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”.
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.
https://hn.algolia.com/?q=https%3A%2F%2Fblog.cloudflare.com%...
Bad Request
This combination of host and port requires TLS.
The Unifi issue you cite is due to a series of problems that are related to the http:// to 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:// first, rather than https:// first.
Second: The Unifi is responding over http:// with a completely useless error page, rather than a redirect to https:// at the same port.
Third: The Unifi probably isn't setting a Strict-Transport-Security header on responses to 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", 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.)
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.
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 has more details near the end.
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?
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.
You are entitled to revocation of any unexpired certificates for names over which you can demonstrate control. For Let's Encrypt for example you can automate this, simply make the API calls to demonstrate control (as you would for issuance) and then present the certificate that is to be revoked (it's in the logs) and ask their API to revoke it.
Maybe DNSSEC could be used here to help if ACME added a way to force DNSSEC-only domain validation.
For example: No one is stopping someone from intercepting your request to your clinic and add a form asking for personal details - and then using those details to "restore password" - or simply ask for your CC number. You might not fall for it but are you as confident in all other patients?
Grandma might be able to edit HTML, but "what's sudo? What's ssh? This one website says I need to pay for certs?"
My biggest concern as http becomes less and less acceptable is that practically the entire internet relies on lets encrypt to run.
Sym crypto is the only answer (Schneier,DJB) people have been trumpeting this for years.
To validate the person holding that certificate is who they claim to be, how can I do that? By either getting their certificate out of band (impractical), or trusting an intermediate.
Lets encrypt doesn't make it any easier or harder to get an invalid certificate.
Now if the server wants me to authenticate, https has that built in. I can present my own client certificate, and if it's signed by somewhere the server trusts, it knows who I am. But how would a random server authenticate who I am? I'd personally rather use certificates or ssh keys or similar than usernames and passwords, but that's too complex for the average person.
Clearly I could have lost control over the key to my certificate, or the server could have lost theirs, there's not much you can do about that, no matter what type of authentication system you use.
First, getting authentic data from the provider so that you know what they published is what you're reading.
But also links and embedded links/scripts. Since HTTP can be (relatively) trivially MITMd, it not only exposes end users to getting manipulated info, but also, having them running Javascript that's not what the site owner intended.
In fact that's exactly how China attacked GitHub recently: https://threatpost.com/github-attack-perpetrated-by-chinas-g...
Your browser might flag a http server as dangerous (mine doesn't - it just has a padlock with a line through), but you're leaking information to your ISP that you are reading about a Physical Therapist.
If your site tries to do https and fails (self signed or invalid certificate) it will rightly flag up that it's a problem.
My grandma would not be able to manage a server on the internet, let alone responsibly manage it. If you can't set up a modern server with https then you shouldn't be running a server on the internet at all.
Thank god we moved on from that.
I can't find the example (it was linked on HN a few years back), but a clear demonstration of this is a case where the MITM can serve a phishing page that initially appears to be the original site you've hijacked (so the user trusts it, and leaves it alone); but later, while the page is not visible (for example, when the user switches away from that tab), the page will switch over to showing a Facebook login screen or something.
Since the website isn't a known "malicious site" (so no alert from the browser), the user probably won't bother to look at the URL bar. They'll just think they left Facebook open in a tab, and it logged them out for inactivity. So they'll "log back in."
[1] https://news.ycombinator.com/item?id=24711111
EDIT: what are the downvotes for? If for disagreement, this only shows how poorly people misunderstand security of https.
> What danger could possibly happen if I'm reading about a Physical Therapy clinic?
Depends what is a "danger" to you. Your insurance learning you're having issues and deciding to increase the amounts you owe them, because they saw that your back is aching, is definitely a problem.
> But unless the Physical Therapist knows how to manage the server, they get this scary warning.
Wrong. In 2020, if the Physical Therapist can have an http website, they can have an https website with a valid certificate.
It's the same for your grandma store. Going from no website to http is a much much bigger step than going from http to https.
The real danger I see is the disappearance of lots of quality, not-for-profit content that reminds me of the good old Internet, swapping it with new shiny https publishers, of which 90% belong to the same owners. That's the real danger to the society. The long tail is disappearing, while commercial interests, and the manipulation that comes with that sneaks in everywhere.
This ship has sailed, though: “plaintext HTTP” is available only with HTTP/0 and HTTP/1. This article is discussing HTTP/3, which carries forward the requirement of wire encryption that HTTP/2 argued over for a long time and then incorporated into the standard.
(Incidentally, my grandmother was a Smalltalk and 6502 assembly programmer of educational software in the 80s. She let me read her technical books at age 5. Probably best to find another example, such as “non-technical site owners”.)
Also note that because http:// and https:// are different schemes, there is no requirement that they serve the same website. http://example.com/foo and https://example.com/foo could be completely different resources, or completely different websites. An opportunistically encrypted load of an http:// URL still needs to load the http:// website, not the https:// one. Though opting in to HSTS eliminates this distinction.
For that matter, HTTP/1.1 allows full URLs to be specified in the request line, as an alternative to the traditional "Host" header. This is usually only used when using HTTP proxies:
GET https://example.com/foo HTTP/1.1
...
In short: scheme and protocol are different things, and for good reason.
URIs are resource identifiers. They exist to identify a resource, not how to access it. Tying those resource identifiers to a means of resolution would unnecessarily couple it to a resolution mechanism and thereby reduce the universality and permanence of URIs. URIs which are URLs are closer to describing a means of access but fundamentally there's still an interest in providing enough degrees of indirection that the longevity and permanence of an URL is maximised.