HTTP isn't supposed to rely on external services that can die, cut you off, block you, etc.
This is not a matter of how easy it is to align with the current browser dictated situation.
EDIT: LoTR typo (elf vs self) fixed.
HTTP alone doesn't serve its initial purpose at the large scale. That's like having a process for building homes out of dirt and hay, a totally viable way of doing your own house today, but it definitely won't be enough to house the 10 billion people of tomorrow.
The real alternative to provide what HTTP once wanted to provide, if not HTTPS (because of its reliance on points of contention), is in the decentralized web: dat, zeronet, ipfs ?
mkdir ~/public_html/
echo 'My Samoyed is <b>really</b> hairy.' > ~/public_html/index.html
If the people steering the dominant browser projects think that allowing everyone to author and distribute creative work is important, they'll keep supporting HTTP, and they might also direct effort to supporting dat, zeronet, ipfs, onion sites, and so on. If they don't think that's important, they probably won't do any of those things, even though, yes, the tradeoffs are a little different.
Since most of them are at Apple and Google, I think the iOS App Store and the Google Play Store probably represent the future of the web. I think that sucks but I don't know how to stop it.
As for adobe, it's pretty labor-intensive and slow as a way of doing your own house, and it doesn't work that well in very damp climates like Seattle. But there's no difficulty at all in scaling it up to 10 billion people, and indeed with compressed-earth brick presses, it might work better with modern industrial machinery than with the traditional North African craft processes that we now use all over the New World. There's plenty of suitable dirt and hay out there.
The answer is in the question: they're building _browsers_, to consume content but certainly not to create it or spread it. The last mainstream browser that did that (Opera) vanished a few years ago.
In fact, thinking about the problem a little bit more I realized that the heart of the article is kind of true but isn't articulated to show it clearly: Internet, while it was still young, was pretty symmetric because every node could be a producer and/or a consumer, and it seems everyone was. Today things are really different, because while there still are producers, the important gap is that they're not distributors anymore, and they're far fewer than consumers anyway.
The article states that the switch to HTTPS has somehow "changed" things, because you can't start a super basic HTTP process and expect it to run for a long time. This conversation has shown that while it's technically true it's very easy today to run an HTTPS reverse proxy to mitigate the situation, so from the point of view of TLS the point is mostly theoretical. However there's something that is very important today, it's that people who want to produce mostly can't also be distributors: NATs and firewalls and the complexity of configuration has in practice prevented everyone but the most tech-savvy of us from self-hosting. I think this point is more detrimental to the initial promise of the WWW than the technicalities of the encryption that has allowed us to make this protocol more viable at the scale we're at right now.
The answer is, as I've said before, the decentralized web: I personally believe that dat is the right model, but I might be wrong and the details don't matter that much because the important point is that they all allow us to get past connectivity issues and be both a producer _and_ a distributor. Hopefully that's where we're going to be headed in the coming years.
Regarding adobe, there's no question it _can_ be used if we just want to; what I had in mind (and I did not express it, my bad) is that this kind of material usually comes with the associated manual process that's so prevalent in the communities working with it. Scaling it to 10 billion people, all using this method, will definitely change the way our societies are built: tall buildings aren't possible anymore, at least not the way we're used to. Structures take decades, not years or months to be built. I doubt this can scale to 10 billion people.
I didn't have root then, I didn't have root a couple of years later when I was doing sysadmin intern tasks on the math department's machines, and I didn't even have root on my desktop SPARC 5 in 1996 when I was working at a company, although I did on my roommate's Linux box at home and, later that year, my own. But IIRC our internet access was through Slirp on a shell account: we didn't have our own public IP address. (My workplace SPARC did.)
That was about the time the unwashed AOL colonist hordes started thinking they owned the internet and remaking it in the image of the world they knew, giving primacy to commerce rather than knowledge and sharing; but, of course, they didn't have public IP addresses either, or I think even private ones.
I'd say that the internet was still young then because it was only 23 in 1992 and only 25 in 1996, and now it's 51. But I think it's actually easier for people to put things online now, despite the NAT growth and HTTPS churn and whatnot, because an awful lot of people at the time had some kind of internet access but no distribution capabilities and no usable software. I don't know how long it would take an average internet user to learn to spin up a DigitalOcean droplet and start running nginx on it with LetsEncrypt, but I imagine it's on the order of a day or two, and the startup cost is like US$5 or something.
But however much easier it may be to initially put something online today, it's enormously harder to keep it online, and I think that's a terrible price to pay. And we're increasingly vulnerable to arbitrary censorship decisions made by Google, Apple, etc., even if currently that is more a potential risk than an active catastrophe — much like the next pandemic was a year go.
Today the menace is not so much commerce — though it continues to be a pervasive corrupting influence on our discourse and a frequent excuse for political censorship, it is also the underpinning of the internet since the beginning — as it is partisanship. Want to distribute health "misinformation", such as advocacy of wearing face masks (a month and a half ago, anyway, when this contradicted official guidance from the CDC)? Better hope Google and Fecebutt don't find out.
The whole problem of a self-signed cert is unless you have a priori knowledge of the cert somehow, it then is trivial to MITM a self-signed cert. That is why it was never trusted. That is the point of a signed cert, you are inherently trusting a third party to tell you the cert a website is giving you is good.
It does bring up an idea of making an individual a CA (i.e. you know someone's PGP key and that PGP key signs a cert, and that is a way to trust it). But you still fallback on the same issues with PGP email, you ultimately need someway of trusting it in the first place.
LE and other certificate authorities* at least prove that your data wasn't tampered with in transit, or wasn't decrypted, read and reencrypted without any way for you to find out.
* as long as you trust those authorities
I do not enough to solve that problem really.
So I'm going to disagree. No, there is no security benefit to encryption without authentication.
There certainly are real world situations where the chance of active eavesdropping (which requires a targeted attack, and is risky because it can be detected) is low, so you accept that level of risk, but the ability for someone to just grab all the traffic of a large group (that just happens to include you) for a prolonged period of time undetected is much higher.
Encryption prevents sniffing, Encryption + trust prevents sniffing and MITM. Providing sniffing protection is an upgrade.
As an example, say HTTP would always upgrade to HTTPS with a server provided public key. That would be more secure than the HTTP we have today, even though it wouldn't prevent MITM.
Of course it's worse when the user thinks the connection is encrypted when he actually has no idea who he's talking to.
What kind of attack do you have in mind where someone can sniff on the data but not tamper with it?
And how should a browser explain this situation to the user? No, the mindset that an unverified certificate is better than no encryption is very dangerous.
If a website previously using a self-signed certificate switches to plain HTTP - how will that help me verify the identity of the server the next time I visit?
By removing the self-signed certificate, not only am I still unable to verify the identity of the server, but now my traffic is in plaintext for anyone on the local network to trivially intercept (in addition to whatever stranger I'm sending it to on the other end).
I understand your sentiment, and I know the slippery slope that you are referring to when you say that it's a dangerous mindset to be okay with unverified certificates. Unencrypted communication however, is not a solution to that problem.
Could you point out who you are responding to who said that unencrypted communication is a solution to the problem? This strikes me as a straw man argument.
If they are able to trivially intercept your network traffic they are probably also able to modify it (=> hijack untrusted HTTPS) or what scenario am I missing here?
Of course unencrypted communication isn't a solution if your goal is to have secure communication. But so isn't untrusted communication.
Either it's secure or not. You can't have something in-between. The browser would have to display an icon that says "This connection is secure but actually we don't really know so maybe it isn't". What are you supposed to make of such information?
The NSA for example is known to just suck up all the traffic it can get and put it in a pile for later analysis.
Maybe your mention of "Make a bomb in chem class tomorrow" was just a joke to a close friend about how much you hate school, and maybe an analyst will realise that and move on when they see it, but civil liberties advocates think it'd be better if that analyst couldn't type "bomb" into an NSA search engine and see every mention of the word by anybody in your city in the last six weeks. I agree.
Americans tried just telling the NSA not to collect this data, but the whole point of spooks is to do this stuff, short of terminating the agency they were always going to collect this data, it's in their nature. So the practical way forward is to encrypt everything.
Any TLS connection can't be snooped. Only the participants get to see the data. The NSA isn't going to live MITM every single TLS connection so even with self-signed certificates the effect is you prevent mass surveillance.
A targeted attack will MITM you, no doubt, and so that is the reason to insist on certificates, but it's wrong to insist as you do that there's no benefit without them.
Ok, that wasn't really my intention. I was stating that a false sense of security is worse than having (knowingly!) no security at all.
So yes I agree, you're generally better off even with untrusted encryption but that doesn't help in practical terms with our current situation of HTTPS in web-browsers. Maybe it would have been better if web-browsers would have just silently accepted self-signed certificates while still showing the big red warning about an insecure connection. I guess that will be solved with QUIC/HTTP3.
Agreed. If you know that you are insecure you're less likely to pass sensitive information over the connection.
IMO the culprit is browser behavior. For instance, when visiting unencrypted HTTP sites in Chrome you may or may not notice an unobtrusive, greyed out "Not Secure" label in the URL bar. Visit your own self-signed certificate dev site though, and Chrome will give you an error wall with nothing to click, and you have to type "thisisunsafe" to pass (the page does not tell you that typing "thisisunsafe" will get you through).
Perhaps the reasoning is that if a site is served unencrypted it shouldn't be serving sensitive information, whereas an invalid certificate is an easy indicator of something amiss... but wow, talk about obtuse.
Your concern is definitely valid though, and I'm concerned about it too.
If the site doesn't seem to require HTTPS but you've gone there with HTTPS and there's no trustworthy certificate then the browser gives you a different interstitial which has a button labelled Advanced which reveals a link "Proceed to ... (unsafe)" that will switch off further interstitials for this site but retain the "Not Secure" labelling.
The HTTPS site (once you reach it) gets access to all modern features, an HTTP site, even if you ignore all the warnings, does not. As an example that's particularly unsubtle, calls to all the WebAuthn APIs just give back an error as if the user has thumped "Cancel".
Edited to add: Also the grey "Not secure" is changed to red if you seem to interact with a form, because that's probably a terrible idea on an HTTP site. Eventually I expect it will just always be red (the change to notice form interactions was in 2018 and this is part of a planned gradual shift by Chrome and other browser vendors).
It took Letsencrypt to make HTTPS accessible to the majority of the web because there was no cheap way before, because self-signed certs were punished by browsers while unencrypted connections were fine. We could have been full on moving from an encrypted (self-signed) web to a trusted (CA) web by now instead of moving from a plain-text to a trusted web.
Also, self-signed certs still prevent a MITM if you ever connected to the site before, similar to the trust-on-first-connection behavior of SSH. Given the widespread deployment and trust of SSH I'm suprised this people act so different with HTTPS.
Passive collection, where you search through the accumulated data after the fact.
In what real-world situation is that an upgrade?
The browsers agree with you. Blame Netscape (a corporation which no longer exists) in the mid-1990s (when people still thought Bill Clinton was cool and that the Web might be a fad) for this UI design mistake. Or maybe even Sir Tim himself since his "Web" has no security whatsoever.
But, merely acknowledging that the present design is wrong doesn't fix it, and we can't rewrite history. So the shift has been gradual, but it's real.
In this current Firefox for example an HTTPS site which presents a self-signed cert gets a warning interstitial, and then a cautionary UI marker but once I tell Firefox I trust this certificate it functions normally.
On the other hand an HTTP site gets a red warning UI and some feature just don't work, and there is no way for the site to add those things, they're just outright prohibited with HTTP. If I try to fill out a form the browser reminds me it's insecure, and again there's no way to switch that off because it's true.
Long term the goal is to deprecate HTTP entirely. You will have to use any remaining HTTP sites through a reverse proxy (or an old browser), perhaps somebody benevolent will operate a public proxy for those rare public sites that refused or are unable to upgrade to HTTPS. I'd guess we're maybe 5-10 years from that.
This is a very recent development. Until last year HTTP had no special behavior while self-signed HTTPS had a big "You WILL get hacked and all your creditcards stolen if you continue, do not continue unless you have a PhD in Computer Security" warning. Still has.
Chrome shows a grey "not secure" on HTTP and a similar warning on self-signed.
In terms of how secure HTTP vs self-signed is, the behavior should be reversed.
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
I've been shilling for this project enough, and feel it's a little offtopic here, but if you're really interested you can find it in my recent post history :)
I don't think DANE is going to make any progress, but opposing it because it gives TLDs more power is kind of bunk -- the TLDs already have that much power, DANE just makes it more explicit.
You generate a CA cert using a utility like xca and then create client certs signed by it. You can use signing requests if you don't want to know the password that protects the certs (in my scenario, I was fine with that).
You then export your client certs, with your CA cert included, and coordinate with people who need access to install the cert on their browser or OS.
Your users will get prompted to trust a new CA (as they should).
Combine with a webserver that supports routing requests based on certificate status, like nginx, and it's pretty neat. You can allow access to only those who have a cert signed by your CA.
I did this for the longest time before letsencrypt was a thing, and if letsencrypt goes away, I'll go back to it.
What I don't get, with DNSSEC getting rolled out more and more, why can't every site operator simply stick the fingerprint of their HTTPS cert in DNS and have DNSSEC take care of the trust chain?
EDIT: why on earth was this question downvoted? It was genuine, I honestly don't know how to do it.
This question is extremely relevant given how DNS-based authentication is the preferred way to authenticate with letsencrypt.
If DNS is good enough for letsencrypt to validate you and give you a cert, why can't DNS be good enough for the browser alone, without needing to rely on some third party service?
Letsencrypt has certainly made HTTPS easier in practice, but we really need to get rid of the whole CA-model entirely.
That's well and good, but who are those Letsencrypt guys, anyway? That's why there is a chain of trust and Certificate Authorities.
You, and your browser, cannot know everyone out there so you pick a few 'authorities' that are well-known and deemed serious enough to be trusted and go from there.
DNSSEC operates on the same principle of a chain of trust from root.
Letsencrypt is run by Mozilla. So lets instead make that:
> What Mozilla does ... is that you control the domain you are requesting a certificate for.
So Mozilla trusts me based on me controlling the DNS of my domain, and can issue me a security-token which Mozilla's browser (and other browsers) then can trust.
Note: It does not trust me or verify me to be non-malicious, honest or have good intentions of any kind. It merely verifies that I control the DNS of the domain I request a certificate for. That's it. That is all.
So why can't Mozilla's browser simply instead of trusting these magic tokens, instead just verify that the cert for the site matches the cert pinned in DNS, thus validating that the site-operator is indeed in control of the DNS of his domain?
It will be exactly the same validation, except now we don't have to rely on a third-party service to do that for us. And then the web can finally be autonomous and decentralized again.
Let's Encrypt is a service of ISRG, a public benefit corporation https://www.abetterinternet.org/about/
Some key ISRG people were from Mozilla, but so what?
> So why can't Mozilla's browser simply instead of trusting these magic tokens, instead just verify that the cert for the site matches the cert pinned in DNS
Poor deployability and interoperability. Now your browser mysteriously doesn't work on a lot of the world's networks and the site doesn't work with other browsers.
>that you control the domain you are requesting a certificate for
but it mostly seems to do it the exact same way any random person browsing to an HTTP site would: it checks the DNS records. It's not like there's an out of band channel here where they actually verify business records separately or something. So what exactly is the value of the middle man in this? Why not just have public sigs in the DNS records too? When DNS is the root of trust anyway and "Certificate Authorities" are reduced to fully automated systems, what value to "Certificate Authorities" even bring anymore in this context? It seems like a hack from a time when CAs were expected to provide some out of band verification that would actually be useful. But on the web that mostly hasn't happened or has been rendered moot (witness the death of EV).
I can see how central CAs could still be useful in many other circumstances. But for anything where control of DNS directly correlates with control of the entire chain, it seems like it'd be a lot better to just decentralize into DNS.
The exact same applies to using DNS as chain of trust. You have to start with a well-known root of trust because it's impossible to know all the DNS servers or registrars out there. In fact that's exactly how DNSSEC works.
It seems that the question is whether DNS and HTTPS certificates are converging to provide the same service. Perhaps, though I'm not sure, but that wouldn't change the system fundamentally.
But they aren't, DNS is. That's my question. If someone controls my domain, they can point it wherever and get all the Let's Encrypt CA signed certs they want. So how exactly is the CA being a root of trust there if the CA itself is basing trust off of domain control? In neighbor comment it seems that maybe the CA is basically acting as a hack to bypass an inability by clients to check DNS? I can see why that would have some practical value in the near term but it'd be good to do away with it as soon as possible. Apple/Google/Microsoft (and maybe Mozilla) may be in a position to do so if no one else.
You're discussing how to prove to Let's Encrypt, or anyone else, that you are the legitimate owner of a domain.
That does not mean that I know or trust Let's Encrypt. The root of trust is an entity I know and trust and which can vouch for Let's Encrypt, which can in turn (or not) vouch that you are the legitimate owner of a domain.
The same applies to DNSSEC. The root of trust being the root servers.
Hasn't really gone anywhere of importance.
I personally think there's been a few factors as to why:
* Distrust of DNSSEC and centralized authority.
* Lagging DNSSEC deployment, not just in DNS but also in clients and applications.
* Needs another DNS lookup on connection to validate certs, adding lag. I think it probably needs stapling support in some form just like cert validity checking.
There's also been follow up RFC detailing it's use for SMTP, SRV records and PGP.
There are also a lot of other objections to it, including that it's too centralized (see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...), but that's the basic reason why it can't be deployed.
Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure), despite almost the exact same reasons holding up with middle-boxes, proxies and the like.
Now that there is an alternate, much simpler HTTPS-solution everyone is "oh noes that would break corporate environments". What's different this time around? Why is breaking things bad this time?
If we could just sit down, and all agree that the only reason we "need" HTTPS everywhere is because running JavaScript in a browser represents a security-issue, the quicker we can start solving the real problem: JavaScript as a default-permission.
The quicker we can phase that out from web-pages (which honestly more often than not, simply represents documents), the better.
This misunderstanding is where your argument went off the rails: people wanted HTTPS because they are sending data over networks which aren’t perfectly trustworthy. Starting in the late 1990s there was string consumer demand to feel safe entering credit cards and other personal information even if the site used no JavaScript - our household-name clients expected it even if they only used JS for mouseover effects. That was before WiFi became common, too, and people realized the risks of letting everyone at Starbucks see their information.
DNSSEC has no equivalent because it took so long to be adopted that it offers no meaningful user benefit over HTTPS, and it’d need to be a substantial win to balance out the poor user experience and implementation challenges.
And here the HTTPS crowd‘S argument is that an evil attacker can inject malicious JS if MITMed, and this according to them is why everyone must have HTTPS for everything. No middle ground.
But if JS was not a default permission, that wouldn’t be a problem and plain HTTP would go a long way for most people, without risking stuff like heart bleed and insecure servers, due to an overly complicated and often vulnerable crypto stack.
Edit: I don’t see why people think this is a crazy suggestion. We used to treat MSWord-documents the same way we treat web-documents now. That is, once op deed, the document had the permission and capability to run any embedded script it wanted.
In the end everyone realized this was a bad idea, and now Word-documents have to request the script-permission from the user before scripts are allowed to run.
The result? MSWord-based worms and malware almost eliminated over night.
And I’d like to see anyone argue that we should give HTML-email script-permissions by default. You know why that is a bad idea.
So why wouldn’t want the same for the web? Why should not the web be safe by default? Why should we have to accept scripts we haven’t authorised?
The HN community loves static sites and the old web. But this is a tiny tiny tiny minority.
That problem is solved by making sites avoid needless JS.
Today I can browse almost every major news-site without JS and they won’t visually break. Same for documentation. It’s all documents after all.
If I enable JS they load megabytes of scripts and still act just the same. What did those scripts bring me? Increased CPU load and lowered battery life.
What is it wrong with not wanting that as default?
"I wish things were like the 90s, but with broadband" is a constant refrain among techies but go talk to the rest of the world and it is absolutely not what people want.
Really? Most websites don't have login systems? Don't ever have content you might not want everyone to know you're reading? Don't allow you to post messages you might want to keep separate? Don't allow you to search for things you want to keep private?
I disagree. Most websites include some sort of login system, at least for the editors to use (e.g. Wordpress). And the few that don't, often include data that doesn't need to be private, but should be signed (e.g. GPG key fingerprints).
So I guess I'm confused how
DNS records hold a public key rather than _acme-challenge
If someone gets control of your domain, then yes, there really isn't much difference between a system where a public key in your domain's DNS records is used by clients to tell they are talking to your sites and a system where a certificate issued by LE is used for that.
As you note, once they have control of your domain they can get new certificates from LE for it.
But attacks against the domain owner aren't the only kind of attacks. There are also attacks against the domain's visitors.
Suppose Bob has an old router at home with out of date, buggy firmware that I know a remote exploit for that allows me to change his DNS settings. I change it so that instead of using the DNS servers it get from Bob's ISP via DHCP to resolve DNS requests from the LAN, it uses my DNS server.
My DNS server points your domain to one of my sites instead of yours, where I run my nefarious fake version of your site.
Under the public key on DNS server approach, it's my DNS server, so I can put a public key on it that corresponds to my keys on my fake version of your site, and everything will check out from Bob's point of view.
Under the LE approach, this does not work. To get LE to issue to me a certificate for your site, I have to get LE to use a DNS server I control to resolve your domain.
That's the difference. Under the current system to securely hijack your site I need to compromise your system, your DNS provider, your domain registrar, your ISP, or your hosting provider. Under the keys in DNS approach, I just need to compromise end users.
It definitely makes sense, and I completely understand how this sort of workaround can be necessary to get stuff done. But it's also too bad and I hope there can be a push towards securing DNS sooner rather then later, as it really should be the minimal source of trust in most cases. Having DNS be reliable for that with widespread support would open up a ton of additional new possibilities too, and not just for public websites.
RFC 6698
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
I wrote a short explanation of how it works a while back.
https://www.metafarce.com/adventures-in-dane.html
The short answer is that DANE has been seeing deployment success for SMTP, but has yet to see much deployment success for HTTPS.
Once in Python
https://github.com/smutt/danish
And again in Rust.
https://github.com/smutt/danish-rust
An old explanation can be found here.
https://www.middlebox-dane.org/
Both middlebox-dane.org and metafarce.com have DNS TLSA records that match their certificate from Let's Encrypt. You can do this, but almost no one is.
There is some pickup in The Netherlands where I live. For example, www.digid.nl has delpoyed DANE for HTTPS.
Since "DANE for e-mail" is still relatively new / obscure, for the uninitiated, RFC7672 [0] describes "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", which requires DNSSEC -- and, as a result, comes with all of its associated disadvantages / trade-offs.
An alternative, more recent method of providing authenticated and encrypted delivery of e-mail is described in RFC8461 [1], "SMTP MTA Strict Transport Security (MTA-STS)", which uses DNS and HTTPS -- and, thus, relies on CAs / PKIX. MTA-STS doesn't require DNSSEC but it is then susceptible to "malicious downgrades".
Although we're not going to see all e-mail being encrypted in transit anytime soon (if we ever do), it's good to know that there are folks working on solutions, including at some of the largest e-mail providers.
---
Let's also not forget that having a HTTP website relies on other services that are maintained by others as well; this isn't going from "full independence" to dependence, it's going from N dependencies to N+1.
Certbot is not a silver bullet and is easy until it's not.
There are a lot of websites out there that just want to serve some static data or host a blog, and https IMHO adds nothing but a layer of complexity for no benefit.
Until someone who is trusted, technically capable, and has a better and sustainable solution that optimises collective good, I'm not sure that the current situation we are in is really that bad.
The DID and VC standards have an interesting approach. Use self-signed public keys, and third-party-signed credentials. To prevent MITM use credentials, to encrypt channel use the keys.
The agreement part, however, remains difficult because the protocols are always evolving.
Maybe in a few years we'll get it solved, just like Bitcoin solved double-spending without centralization?
I think the main reason is that they're on the whole pretty racist towards dwarves.
And there are always T&Cs. AKA we didn't like that article on your account, we kill all your services and deactivate your account.
When I think about my old grandma or my oblivious inlaws downloading "free games" and constantly getting scammed or infected with viruses, this whole HTTPS thing seems awfully ridiculous. The internet is full of websites that will grift you if you aren't careful.
I think the other part of it is also that FF is trying to position itself as the browser for security-conscious users. Hence the aggressive blocking... whether it works or not is another question.