It takes 10 minutes to put an old HTTP server behind a reverse proxied nginx instance with auto-renewing letsencrypt certs (you can even reverse proxy old HTTPS-supporting servers that have outdated TLS versions).
I also disagree with the idea that HTTPS introduced the problem of requiring maintenance; anything you expose to the public internet needs maintenance and security upgrades.
Yeah, HTTPS is the response to the problem. The problem is that the internet is nowhere near as "safe" as it was a few decades ago. (Or at least, the unsafe-ness is now better known.)
It's a bit like complaining that you can no longer take your origami collection outside without an umbrella. Well, the umbrella isn't the problem, the rain is. The umbrella is a solution. But of course being under an umbrella isn't the same as being outside on a sunny day. So sure, lament the change in the weather; lament the inconvenience of carrying an umbrella around all the time; but don't blame the umbrella for the rain.
> The problem is that the internet is nowhere near as "safe" as it was a few decades ago.
It wasn't very safe a few decades ago either.
In 2000, I had naively set up a Linux box under my desk with a public IP, thinking maybe I could host a blog on it. It got a number of portscans within minutes of being set up, and subsequent monitoring showed lots of intrusion attempts. Luckily the box was patched, but I was essentially one zero-day away from being 0wn3d. But I did learn a lot before moving the box behind a firewall.
I guess that back in the day, some people could wish these away as unproven threats well into the early 2000s until malware like Nimda / Code Red well and truly destroyed that illusion.
If your two servers communicate over the public internet rather than a private network, all you've done is made your users believe they are behind a secure connection when they really aren't.
For example, if your "old" server is a colocated physical server and your proxy server is a fancy cloud VM.
Or the hosting provider could offer a turnkey solution.
They could use something like VLAN to isolate that physical server on its own network, put the VLAN behind a firewall, and have an HTTPS reverse proxy that goes through that firewall.
Depending on how their network is built, it might even be possible to make this self-service where you enable a setting in your account and your physical server gets wrapped in this additional layer.
Eh. I sort of disagree with this specific phrasing.
People shouldn't focus only on targeted attacks on the server. Of course if you have an HTTPS proxy in front of an HTTP server, you can be MITMed between those two servers, and that's very bad.
But even with that flaw you're getting benefits. Public networks can't inject malware/ads into that webpage, a MITM attacker between your proxy and the main server will have a harder time correlating a request with a specific person, ISPs will have a harder time scanning the traffic for use with ads/metadata.
This is a similar argument that comes up sometimes about VPNs. I know people who argue that a VPN does nothing because it just moves trust from one party to another. But the reality is that if you search my public IP address, you will get a pretty decent approximation of where I live. In a world without a VPN, I'm not just choosing whether or not I trust my ISP, I'm choosing whether I'm comfortable giving a decent marker of my physical location to literally every single website that I visit.
That doesn't mean the "moving trust" concern isn't valid, it just means it's not the full picture of what a VPN (either privately hosted or through a 3rd-party) protects you from.
In the same way, it is a valid concern that behind the scenes data might not be encrypted between a proxy and a server. But that's not the full picture of what HTTPS protects you from. HTTPS also protects you at the router/network level.
I also disagree with the idea that HTTPS introduced the problem of requiring maintenance; anything you expose to the public internet needs maintenance and security upgrades.
Although this argument doesn't allow for the huge number of websites that are not on the public Internet, but instead running on someone's internal network or embedded in some device.
It is a dangerous trend for us to rely on browsers made mostly or entirely by businesses who care little for those environments because they make no money from them. There are good reasons that long-lived standards and forward compatibility are important, not least that whoever first developed some useful in-house service with a web front-end or manufactured some long-lived, high-value device may no longer be around to update things routinely according to the whims of Google or whoever.
The issue isn't that Google doesn't make money on intranets.
The issue is that the security landscape has gotten so much worse and continues to become more hostile, and private IP address space and a packet filter don't provide nearly as much protection as a lot of people want to think, and attacking internal applications from "outside" is commonplace. The trend towards zero-trust and such is driven more by the fact that there's no such thing has home anymore, at least as far as networks are concerned - there's no realistic way to keep the internet out.
And those IoT devices with long-lived security holes are landmines, not assets. I'm much less worried about "long-lived, high value" ones, because those are far more likely to get updates than cheap, fire-and-forget webcams and such.
I agree entirely that forward-compatibility is an extremely important consideration. Security, however, frequently pulls in the opposite direction, leaving an unpleasant tradeoff.
The trend will not reverse - I don't see how it realistically could. We live in the Red Queen's world.
You're arguing that there are no environments now where bad people can't penetrate and roam freely inside the local network? If so, I'm afraid I don't accept that premise at all. Even a basic firewall that accepts no unsolicited incoming traffic is highly effective in environments where you don't need to serve anything to the public Internet from inside your LAN. Between that and keeping software like web browsers and email systems that actively fetch data from outside updated, an average household or small business will be protected reasonably well against most routine threats.
The world is far bigger than cloud computing and IoT devices. There must be millions of little in-house web applications someone wrote long ago that are still useful, probably running on some 10-year-old PC in the corner, with some sort of scheduled back-ups if you're lucky. There is also no guarantee that even a high-value, long-lived engineering device manufactured a decade or more ago and still in perfect working order also still has ongoing software support. There is a huge amount of value locked into these old systems, and arbitrarily dismissing their relevance if they don't meet modern security standards that may or may not even be relevant in all the circumstances is like designing a building with such robust security that no-one can get inside, even the owners.
It takes 10 minutes to put an old HTTP server behind a reverse proxied nginx instance with auto-renewing letsencrypt certs
Hi. I've been online since 1982, when I built my own modem from parts sold out of the back of a magazine. What you just wrote might as well have been instructions for assembling a DIY fusion reactor, for all I know.
That's what the author means when he suggests that something is being lost. I now have no realistic choice but to go through a centralized gatekeeper to post content on the Web. That sucks. It wasn't supposed to be that way.
After 15 minutes of googling, I believe you'll have a good grasp on that stuff. I've been there.
So there is new stuff you need to know. On the other hand, these days you'll find that blog post that walks you through installing nginx and certbot on your $5/month VPS, prepackaged with dependencies, just works out of the box, in a very short order. From what I recall from the late 90s, setting up a plain old fashioned HTTP server felt a lot more difficult then.
In the late 90s you mentioned above, ISPs routinely provided some web space as part of the package, at least in my country. You just FTPed your files up to them, and they ran all the necessary software for you.
> no realistic choice but to go through a centralized gatekeeper
This is the critical part. Even though Let's Encrypt is not-for-profit, etc. It is still a single entity. Until someone can go and start their own CA in that 10 minutes that works across the world, we're moving away from and not towards what HTTP was.
The A in CA is always going to stand for authority. The basis of the CA system is that CAs (supposedly) can be trusted. If you remove the hard parts of being a CA, then you remove the basis for that trust (however questionable it was to begin with). You don’t have an authority any more, you just have an ephemeral group of self-attesting certificate issuers, and why would you even need the issuers in that case?
These are just the general (and unsolved, or perhaps even unsolvable) problems associated with PKI. I think there’s a solid argument to be made about separating the encryption of communication from the authentication of server identity. That would solve one problem, but it would also just take an existing bad problem and (arguably) make it a lot worse. Given all of its horrendous shortcomings, the CA system is still the most successful PKI ever created, by quite a large margin.
The usual alternative proposal is some form of decentralised web of trust. This has the significant advantage that it includes neither the letters CA nor SPOF. But of course it has difficulties of its own, and unfortunately it's hard to see how we could move safely and reasonably quickly in that direction given the entrenched powers that now dominate the CA and browser markets.
It is worrying that Let's Encrypt is currently the only major provider of free, relatively easily arranged certs, though. Its success has been impressive, but it's probably also one of the biggest single points of failure in modern Web infrastructure now.
The problem with a decentralized web of trust isn’t that CAs are too entrenched to be replaced. It’s that there’s no such thing as an alternative decentralized web of trust solution, and no reasonable idea about how one could be created. Amazon reviews work on a decentralized web of trust model, and any PKI attempting to implement one is going to run into exactly the same issues that those have. The trust has to be put somewhere. It’s not realistic to expect the users to validate trust themselves, if you establish an authority to trust, then it can abuse its power, and if anonymous participants can abuse your model, then anonymous participants will abuse your model.
All decentralized web of trust models lean towards one of those problem categories. They can be too onerous to be usable (like the original PGP proposal), easily abused, or simply create even more dubious shadow authorities. There is no known PKI model that solves all of those problems at once, and not really any basis for even presuming it’s possible.
Just to be clear, the problem I think we're trying to solve with a web of trust is the authentication one, not the encryption one. Several existing systems such as GPG demonstrate the viability of a web of trust solution in principle. What is currently missing is a practical method of scaling up.
Yes, any such method would inevitably require a different process to how things work today, most likely including some sort of administrative action to get a new domain recognised when setting up a new site. Still, if you'd suggested seven or even six years ago that anyone would be able to set up effective HTTPS hosting with relatively little effort and without paying for an expensive certificate from some big name CA, you'd probably have been laughed out of the building. Five years ago, Let's Encrypt was starting its rapid rise to dominance, and as the various limitations in the original scheme have been removed, that rise has shown no sign of slowing down.
Encryption without authentication is meaningless, and it's no accident that https has them so tightly linked. If you can't tell that you are securely communicating with mitm, what's the point?
Sorry, I'm not sure what point you're trying to make here. Authentication without encryption is not meaningless, and if you can authenticate then there are multiple possibilities for setting up encryption for the subsequent communication. Tightly linking the two is not necessary, and not necessarily desirable.
The basis of the PGP/GPG approach is in-person key signing. It can only work if you're willing to authenticate somebody's identity with them face-to-face (keep in mind that publishing your public key online is currently only possible because of CAs). The web of trust model is an improvement to this, because it allows you to choose people that you trust to also perform this ritual properly. But to say all you need to do it figure out how to scale this up is a flawed premise.
The PKI you choose for the internet needs to work for all internet users. The web of trust model only works for highly motivated and technically competent users, and even then, such a user cannot possibly authenticate all of the identities they need to for typical internet use. They end up with a small group of people they can communicate with more securely. They aren't heading off the google HQ to sign their TLS keys, and if they discover a new web service they want to use, they're not going to hold off on using it until a proper key signing ceremony can take place.
Such a system is not fit for the purpose of securing internet communication, and it's not fit for use amongst the majority of web users. Your options for improving those shortcomings is to either create a system that can easily be gamed, by requiring users to trust some sort of community consensus, or to establish trusted authorities (which is just reinventing CAs, and probably in a way that's worse than the current CA system).
The web of trust model simply cannot work for this purpose, there's currently no plausible approach for improving it, and it's not obvious that such an approach is even possible.
The basis of the PGP/GPG approach is in-person key signing. It can only work if you're willing to authenticate somebody's identity with them face-to-face (keep in mind that publishing your public key online is currently only possible because of CAs).
That depends on what you're trying to prove. At the moment, CAs typically accept that someone attempting to create a certificate for a certain domain is the legitimate owner if that person can demonstrate immediate control over something like the content of the website or the DNS. Attempts to enforce stronger verification, such as EV certificates, have largely fallen flat. An equivalent standard would be no worse as the basis for a web of trust system than it is as a basis for major CAs issuing certificates today.
The biggest problem with today's CA system isn't that there are trusted authorities, it's that for any given cert there is one and only one ultimate trusted authority and if there are further certs involved then the dependency chain is strictly linear. This creates both gatekeepers and single points of failure. A system where multiple reputable sources could indicate their trust in a certain identity and where authentication was based on looking for multiple trusted paths to verify a claimed identity would address several of the practical weaknesses of our current CA-based infrastructure.
Having your certificate signed one time or three times or a hundred times doesn’t really change the dynamics of the problem at all. Without an authority you put the burden of authentication on the user (no matter what ceremony they use). This fact alone makes it a generally useless approach to PKI. The only thing the web of trust does is allow you to share that burden with a select number of people that you actually know and trust. If you try to extend the perimeter of the web beyond that, it just becomes a web of horribly misplaced trust. Reframing it as a web of reputation doesn’t change anything either.
Having your certificate signed one time or three times or a hundred times doesn’t really change the dynamics of the problem at all.
Just to clarify, I'm not necessarily talking anything as specific as signing a certificate. I'm talking about the problem of authentication in general, whatever mechanism it might use.
Maybe we're talking at cross-purposes as I'm not sure exactly what problem you're trying to solve here, but my argument is that the main problem with existing CAs is that they represent single points of failure in several respects.
Authenticating against multiple sources from a potentially larger pool does then change the dynamics in exactly two very important ways: it means neither the site host nor the site visitor is reliant on a single CA and thus a single potential point of failure any longer. This isn't a complete solution to all possible problems with the existing CA system, but it does offer a conceivable way to mitigate some known weaknesses in that system.
Getting that far doesn't really even need a full web of trust system, just a mechanism for seeking confirmation from N of M ultimate authorities where N is chosen such that 1 < N < M with whatever safety margin on either end you deem appropriate. But a more comprehensive web of trust would potentially allow for a fully decentralised system in the sense that anyone could operate their own final authority but how much it was trusted would depend on the properties of the web (as would how much any default authorities included with browsers as standard were or potentially were not to be trusted).
What you’re describing is not a known weakness in the CA system, and doesn’t even really touch on the actual known issues with implementing PKI. The CA is not a point of failure. If one CA fails to sign your certificate, you just get one from a different CA. If a CA that had already signed your certificate vanishes, nothing fails because your existing certificates do not suddenly become unsigned.
The core issues with PKI are establishing trust. The only way to do that for most applications requires an authority. You’re not improving the system by requiring multiple authorities to sign every certificate. You’re not making things less authority-reliant or more resilient. You’re just making it more complicated, and leaving the real underlying issues around authentication unchanged.
> Until someone can go and start their own CA in that 10 minutes that works across the world, we're moving away from and not towards what HTTP was.
Would you trust the authenticity of content that originated from a site signed with such a CA? If so, why?
PKI is just a technology for verifying trust over untrusted channels. But that trust is created in and remains rooted in the real world, and is itself built on societal chains of trust.
No technology, centralized or decentralized, will replace real world trust in human societies any time soon. Trustless tech only works if it's based on a society with trust. Otherwise the tech is meaningless.
> I now have no realistic choice but to go through a centralized gatekeeper to post content on the Web.
I don't know where you got that. You'd install an nginx (or caddy, my preference) reverse proxy on exactly the same hardware you were running your HTTP site, or if that machine is too foreign you can buy an old laptop, put the reverse proxy on it and forward to your site. There is nothing centralized with that.
I'm a modern web developer who's fairly up to date on those things. I've set up what he described just last week. I definitely couldn't do it in 10 minutes. An hour maybe.
The person above forgot that those things require a lot of skill and experience just to understand what you're told to do. We're a long way from building websites with FrontPage and uploading them over FTP.
It is also possible to use stunnel to do this, and the configuration to do so is really quite simple. It can be run both as a standing daemon or launched on-demand as an inetd service.
The thttpd web server can run modern TLS with this approach, and the footprint is much lighter than with Apache.
> anything you expose to the public internet needs maintenance and security upgrades.
Uh, no — in the past you could have purchased a hosting solution, that does it's own TCP termination (such as shared hosting) to completely forget about your site. Many static websites still exist solely because of that.
Now you can accomplish the same thing by paying Cloudflare (or some other party) to terminate your TLS connection. One more kind of parasites has been enshrined in technological stack.
You can also pay Hetzner, Wordpress, 1&1, AWS or any other hosting provider, most of which also offer automatic certificate renewal by now. I don't see how there is any change, especially since hosting has gotten a lot cheaper.
Well, you surely could do this via some proxy setup. But in that case you could also simply rely on LetsEncrypt directly; them going away is as likely as your average hosting provider.
Now, of course that's an item on the maintenance list if you're hosting the web page yourself, but as mentioned above: You still need regular updates, having certificate renewal on that list doesn't make any noticeable difference.
> It takes 10 minutes to put an old HTTP server behind a reverse proxied nginx instance with auto-renewing letsencrypt certs
The point of the article is that not even this is enough, because letsencrypt will change protocols, TLS versions and ciphers will be obsoleted, etc etc.
Basically your entire stack will need to be kept continuously up to date.
Just setting up Nginx in a Ubuntu LTS release won’t be enough, because you always will need to have everything up to latest always. And obviously you need to automate that self-update process too.
So because the browser is insecure and allows JavaScript, everyone else who wants to serve a simple index.html will now need to be a full-on DevOps-expert.
To me that sounds pretty backwards. How about we just fix the JavaScript-security issue in the browser instead? Or would that be just too simple???
This is breaking the web in the sense that everything which is old will perish instead of being preserved.
Maybe I’ll go back to making my sites HTTP only. It certainly sounds simpler and more reliable than this...
I can update and maintain nginx and certbot(honestly I use lego) but I won't say I'm a DevOps expert.
And you can deploy your static site on Netlify, S3 etc.
Ask your mom to "put an old HTTP server behind a reverse proxied nginx instance with auto-renewing letsencrypt certs" and time her. See if it takes 10 minutes.
Then ask someone to foot the server bill. See how many takers you get.
This is fine for corporations with IT departments, but when I was a high school student, I had a web page, and my web server was sitting under a desk in a random office. When I was in college, professors ran their own web servers.
A lot of innovation bubbled up, bottom-up.
Big tech stuck that with a fork. That's not a good thing.
A high school student/college professor is clever enough to write web pages and setup web servers, but not clever enough to install encryption keys and certificates? Not buying it.
There is a difference between being able to do something once and being willing to take on some ongoing and occasionally time-consuming responsibility to maintain it.
Look at how many useful but Java-based demonstrations on academics' websites became inaccessible when the browsers decided Java plug-ins were evil and should be removed. What happened was not that people who had voluntarily spent considerable time over the course of possibly several years developing useful little bits of software suddenly dropped everything to redo all of that work again in a different language just because the browser developers had decided that other language was now flavour of the month. Instead, lots of valuable work was effectively lost.
Java changed its security model at the same time, and applets needed to run inside a web browser. (You could fix this by modifying the source, but why bother, since no one would use the result in practice?)
That seems like an issue with Java/Oracle then, not browser manufacturers.
This has also come up with Flash, where Adobe still hasn't opened up the technology to the point where people can effectively emulate it.
If a technology is insecure, and it gets removed from a specific environment for security reasons, and simultaneously a company makes it so that it's impossible to run outside of that environment -- the deprecation wasn't really the problem then.
The reason we've lost massive numbers of Java applets and Flash apps isn't because they got deprecated from web browsers, it's because alternative environments and emulators were never built or given the support they needed. Mozilla/Google can't just decide to change the Java security model for native applets.
Applets weren't necessarily standalone software, though. I built several professionally, and they were all integrated into a wider web page, not just a self-contained program.
The changes by the plug-in developers were often unhelpful in the final days before we gave up on those technologies entirely, but let's not pretend they were the root cause of the plug-ins' demise.
I don't think they were the root cause, but even though there are scenarios like you're talking about, I still think we'd be in a different world today if different companies were handling those plugins.
It's worth noting that from a preservation perspective, today we're at the point where people are pretty realistically looking into emulating SWF runtimes in Javascript inside web browsers. If that happened, you wouldn't even need click-to-play. SWFs would just work with the same sandboxing guarantees as the browser.
The biggest reason that hasn't really taken off is because the SWF format still hasn't been opened up. The reason why there isn't just a drop-in WASM library that lets you run Flash code on the web is because of Adobe, not Mozilla or Google.
Of course, especially in the case of Java we could only ever emulate features that browsers support. But that's why the plugins were deprecated in the first place; because they supported inherently insecure features that we either don't want in the browser, or don't want to support in the same way.
But that's true for lots of platforms, and yet I can already run C/Rust/Lua code in a web browser. The Lua runtime had been cross-compiled to ASM.js before Flash was dead (although today we have a lot better speed). But the difference between Lua/C and Java was that the most common Java runtime was proprietary. OpenJDK browser plugins would break most sites that I was using. So there wasn't anybody who was sitting down to say, "excluding the features that browsers don't support, is there any of this code that's salvageable?" They weren't really allowed to do that.
Even assuming that were technically possible, why should we assume that anyone who visited those pages and found them useful would know what a JAR or JVM is?
They decided to drop java as a plugin because people would browse to a random webpage, and malware would automatically be downloaded to their machines.
Java plug-ins died off for a reason, but that doesn’t change the fact that deprecating http is effectively deleting decades worth of the internet for no good reason.
If someone can own my browser by mitm’ing a static html page, then they can do it more easily by serving malicious ads, or using seo / social engineering to steer me to a web server they control. I don’t buy that argument.
Also, browsers could run in a simple and secure legacy mode when they connect via http.
Even if there are good reasons, it;'s still effectively deleting decades worth of the internet.
To blithely say that it's trivial to slap together a reverse proxy and keep it updated is both factually wrong and missing the point: something has been lost, and it's sad.
> Also, browsers could run in a simple and secure legacy mode when they connect via http.
:) What if, purely as a theoretical proposal, they display the webpage as normal, but just show a little icon in the address bar that marks the website as insecure?
Have I missed something? Is anybody actually talking about removing HTTP support from browsers? I don't think that this is the same scenario as Java or Flash at all, HTTP still works fine. All of the static websites that people are complaining about losing still load without any problems.
And even if it was the same scenario, Java is not a great example to use here, because the deprecation of Java and Flash, as painful as it was to many people, was also very clearly, almost universally recognized as necessary for security.
Java and Flash are probably the two best examples you could come up with if you wanted to argue, "sometimes it's necessary to take painful steps that break things to make a secure system. Sometimes you can't trust developers to do the right things until you force them."
Am I sad about Flash and Java? Of course, I have a fair amount of personal background in that area. We lost precious things. But should we have kept Java? No, of course not. Obviously not, that would have been such a terrible idea for both security and the Open web. I remember the pain of trying to get decent Flash support on Linux. It was a fantastic, open system for some people. But it was also proprietary, and filled with security holes, and being used in ridiculous ways for DRM and circumvention of Open browser standards, and frankly, the slow deprecation path just wasn't working.
I wish Flash had been handled better, but... I mean, we did have to get rid of it. I don't believe anyone could seriously argue to me that the web would be better if we were still using Java and Flash today.
So even in a theoretical world where we're actually talking about deprecating unencrypted HTTP support, we should still only be talking about preserving or emulating sites that will be lost. We shouldn't be talking about continuing to do something that's insecure.
The usual security arguments for dropping those plug-ins have always been a bit dubious. There is no doubt that the old plug-ins were bug-ridden security nightmares. However, click-to-play had mitigated the drive-by download problem. Perhaps more importantly, would an objective assessment of today's browsers really find that they are significantly more secure than the plug-ins were, where they have taken over providing similar functionality? Much the same attack surface is still there, it's just that the browsers are behind all of it now. The evergreen browsers tend to deploy updates more quietly, but if you check the changelogs, they still push out fixes for many significant security flaws in those updates.
I'm not sure arguments about the proprietary nature of the old plug-ins are very strong either. After all, the main cheerleader for dumping them initially was Apple, but to this day Apple relies on proprietary and patent-encumbered technologies for playing multimedia content on iOS where just about everyone else in the world is using technically superior formats with open standards by now.
I don't know if I would claim that the web would be better if we still had Java and Flash today. I think there are too many different dimensions to consider to make such a blanket statement. But I do think a lot of value was lost by turning them off, and I do think the security and openness benefits have been overstated, not because the plug-ins weren't deeply flawed in those respects but because people seem to overlook the all too similar failings in the replacements.
> However, click-to-play had mitigated the drive-by download problem
Only for people who were security conscious and willing to not load certain web pages. For normal people, click-to-play was just another pop-up to click through. I do generally support people's abilities to choose to do insecure things, but there's a strong argument that the point of the web is to securely run untrusted code, and allowing developers a single step to bypass that sandbox is kind of antithetical to what the web is.
> Perhaps more importantly, would an objective assessment of today's browsers really find that they are significantly more secure than the plug-ins were
I would be very surprised if this wasn't the case. It's not just that modern browsers are less bug-ridden, it's also that their permission models are fundamentally different. HTML5 still doesn't allow you the same level of filesystem access that Java and Flash did, and its replacements allow debugging and extending at the DOM/script/network level. It's hard to imagine a version of adblockers that would work with Java applets. In contrast, I can use uMatrix to turn on/off individual request types to specific subdomains.
I mention elsewhere that part of the problem with deprecation was that none of these companies allowed for effective emulation of the web stack. To be fair, part of the reason why emulation was (is) hard is that to this day, Java applets and Flash applets still have capabilities that can't be emulated in a web page. But that's also part of the security problem; we don't want those capabilities to be emulatable.
> because people seem to overlook the all too similar failings in the replacements
Flash just didn't work well on Linux. I couldn't watch Youtube videos. I remember how excited I was when Youtube started moving to HTML5 video containers instead of Flash, because the web doesn't have those problems, and I was so sick of trying to configure Flash plugins for Firefox in Ubuntu. Java plugins were also an issue, albeit to a somewhat lesser extent. But I used to always curse whenever I would see a Java plugin loading up, even as recently as 2015-2016 when I was using legacy enterprise apps. Not to mention Silverlight -- it's annoying that Apple uses proprietary codecs, but for a long time I just couldn't recommend Linux to anyone who wanted to have a Netflix account.
People have a rosy view of these systems, but they weren't necessarily the open utopia that people remember. They just worked well for some people in some configurations.
Given that post-deprecation Adobe still hasn't open-sourced any of its SWF runtime, I don't think there's strong evidence that this would have gotten any better without moving away from proprietary technologies and forcing devs to use Javascript. By and large, I think the replacements have all been a lot better. The only big exception I can think of is the awful DRM proposals for video, but at least the technology works mostly cross platform.
Even at the video level, a proprietary video codec just isn't comparable to a black-box piece of code where I can't look at the network requests, that has a completely separate permission model from my browser, etc... There's a reason why everyone was comfortable providing DRM in Flash/Java/Silverlight, but why in a post-plugin world Google felt it was necessary to provide a completely separate 'solution' rather than just move the DRM into Javascript.
Every major browser had put Java applets behind at least a click-to-play safeguard long before that time.
I strongly suspect that the security arguments were always more of a convenient smokescreen than an honest concern. Browser developers wanted to drop Java applets because they wanted to dump some legacy plug-in infrastructure that was painful to maintain, and their management probably viewed support for old and unprofitable technologies as an acceptable loss to achieve that goal.
Everyone knows what happened. But the result was that a huge part of our history was lost. When we write a book, it is archived in the Library of Congress. As publishing moves online, and we deprecate technologies due to technical convenience, that's just lost.
(1) The poster arguing this was 10 minutes was being dishonest.
(2) As the original article said, it's a different internet if the only way to get something up is to go through Square Space or Github pages. It's much less decentralized, and much more corporate.
Yes, I do think the internet could have evolved to where a tech-illiterate mum could host her own web page from her router at home. It didn't, and we lost something in that process.
Which will if you listen to the advice of HN will be an ec2 micro instance. Which means you're handing more of the internet over to "the big guys" exactly as the author of the article points out.
Firewall should be a separate machine. I am using 2 x 2012/2013 fanless industrial PCs next to the server rack(one main + 1 spare).
The idea is that you're not losing anything or changing anything on the original website/machine. You just add one in front of it and you're done.
Would work with anything ethernet enabled as far as I know.
I never worked with SGI Irix or DEC Ultrix but I assume that they can handle ethernet connections if they are serving websites.
Of course it's readily available, you have a $5000 Cisco ASA or F5 appliance sitting next to the $50000 SGI or HP workstation, to perform SSL termination and firewall.
Somewhat tangential: I maintain an internal webapp that runs PHP on IIS (I know, I know...). Does anyone know how I can add a legit SSL certificate to a setup like this? Everyone currently accesses it using a http://<friendlymachinename>/ URL, and I've somehow been unable to find information on how to HTTPS-enable this app!
I'm currently using the DNS challenge of Lets Encrypt for something similar. My setup is a VM running docker with multiple sites. I just setup a DNS record (it only points to the IP of the VM which is a private (eg 192.168...) one) and setup traefik as the reverse proxy with the DNS challenge. Works really well except that my router blocked the DNS record at first.
The machine that's running this has no Internet connectivity though (which is a big reason why it's running that stack in the first place!), so I'm not sure if that approach would work?
It's a workplace server as well, so I don't really have the freedom to punch holes for outside access.
As its internal, you'll need to look into setting up a PKI. You'll need to create a certificate authority that has its public cert installed on every host accessing the internal site, and then you use that CA to sign the certificate for the internal site.
This sounds like it could work. Since it's a workplace server and is only accessed internally by workplace-issued machines (which are always on the workplace VPN), I think there might be some sort of public cert already in place. Guess I just have to hunt down a certificate!
It's still preferable to use a real DNS name and a real certificate, if you possibly can, which means that nobody has to install a CA.
There's currently no way on any modern system, as far as I'm aware, to install a CA but limit it to only a specific domain and its subdomains; any CA you install can issue a certificate for any domain. (There are theoretically some certificate extensions that allow limiting a certificate to subdomains, but as far as I can tell, implementations don't reliably support those extensions.)
You cannot obtain certificates in the Web PKI ("SSL Certificates" that "just work" in people's browsers) for private names like this "friendlymachinename". Public CAs are forbidden from issuing anybody such a certificate.
Such names are a bad idea for a wide variety of reasons and you should definitely look to give the machine a name from the Internet's DNS (even if the machine isn't accessible in any way from the public Internet), but assuming you cannot or don't want to for now:
You can use a variety of thin "reverse proxy" services to just wrap the HTTP service as HTTPS. Many such webapps won't care that this happened, as the maintainer you probably have a good sense of whether it could work (does the webapp use Javascript that cares about its own URLs for example because that could be a problem?). HTTPS servers such as nginx are well suited to this problem. Security between the wrapping proxy HTTPS server and your PHP on IIS setup is still zero in this setup but that might be acceptable.
Everyone mentioning their quick and scrappy solutions to setting up TLS termination is completely missing the spirit of the author’s letter. Did y’all even read it?
You're right. Commenters seem to comment based strictly on their perception of the title.
I think however, that authors point was moot already - your network connected machine can't be static, it shouldn't be in years. There are constantly new RCE's and other exploits since ages. Your network connected machine must be maintained, whether it's a basic web server or your phone.
Wouldn’t there be a point where we run out of readily exploitable vulnerabilities against a specific platform ?
For instance if I was running a server on an 50 yo IBM framework serving static pages, how many serious attack vectors have been left unpatched at this point ? (ignoring DDOS type of issues where the content is not compromised)
There was a 26-year-old bash bug a few years back. How would you ever know when you'd found the last bug? Unless you do some formal verification of that 50yo IBM framework, I certainly wouldn't trust it to be exposed to the internet.
You're modeling ability as a binary when it's more like a bell curve. Most attackers are somewhere in the middle and old systems are going to be most vulnerable to them.
You might be right but still let me see if can get this analogy right:
The author is upset that we have to build a new house and we can't live in the old huts because they are not considered safe anymore.
The scrappy solution would be to to keep the hut as it is and build a wall around it. You still risk someone jumping over the fence though.
I think in this analogy the issue I see it that we treat a one-man hut and airport terminal the same. For some buildings it's fine to have higher risks than others.
Of course people would need to be educated on those risks, which would probably be the biggest issue.
It’s more that you can’t live in a house now, you have to stay in a flat built and continuously maintained by others. Where before you could have built a simple, sturdy, and drafty castle that would stand for centuries, now you get a flat in a modern super-secure condo, which is very energy-efficient but requires constant maintenance not to crumble and decay.
> (At the same time this is necessary to keep HTTPS secure, and HTTPS itself is necessary for the usual reasons. But let's not pretend that nothing is being lost in this shift.)
So, to stay within your analogy: He acknowledges the need for new houses, but says that huts had a unique flair which is lost now.
You mean the point that "you could have set up a web server in 2000 and it could still be running today, working perfectly well"
Try to setup a windows 98 machine as a web server and see how it goes (Windows XP only came out in 2002). It doesn't do HTTP/1.1 so it's good question whether clients would be able to connect at all.
> Try to setup a windows 98 machine as a web server and see how it goes
Windows 98 was a client OS, it was never intended for this. A proper test would be Windows NT 4.0 Server. Or more realistically for the time frame, Solaris 7 or 8.
Any web server software set up in 2000 and still running today unpatched could be pwned quickly. Including and especially NT 4.0.
When you're running a server, TLS is not the only service you are dependent on; you're also dependent on security updates. If they're not backported, you'll need to make version upgrades.
Arguably it's better to think of every piece of software running on a server like it's a service, to maintain security and performance in an Internet full of hostile actors.
I don't even understand the mindset of wanting to run a live server on ancient software, aside from doing it as a hobby. In which case, it's pretty typical for such hobbies to require extra work and care. Driving around in a car from 1940s takes more maintenance work, and is less safe, than a modern car, and everyone gets that.
I think you misunderstood my comment, I'm not advocating doing this. I was simply correcting the person above me who appears to be under the impression that web servers in the 90s ran on a client OS.
Come, now. In '98 I was writing cgi-bin scripts in perl & c serving websites over apache; by 2000 I was on LAMP which was becoming a de-facto standard web stack.
Of course, I was rolling my own query sanitizers, which was the style at the time; and my php.ini did allow GET/POST to inject global variables. Not to mention CVEs discovered between now and then. So I wouldn't want that server from year 2000 to stay running untouched, but win98 is a strawman.
Incidentally, in 2018 I decommissioned the last perl scripts in the largest US bank, originally written decade(s) ago and handling billions per day (if not trillions).
Yes, making websites secure requires work and maintenance and modernisation. The author even admits this. I think i'm ok with what's being lost in this transition.
Everyone who adds "certbot is EZ" comments: it makes you rely on a service. This is the very problem of certificates, because self-signed was never trusted and is not an option.
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.
> This is the very problem of certificates, because self-signed was never trusted and is not an option.
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?
In theory there is the CERT DNS record type that could be used, but no OS/lib uses it unfortunately as prior to DNSSEC there was no way to prevent the CERT record from being manipulated/intercepted :/
> 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?
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.
A DKIM like service? For emails I find it very convenient, publish your public key with DNS and sign outgoing emails, outgoing emails are now "certified" coming from your server and the recipient can easily verify it, no CAs involved.
What Letsencrypt does (and all other providers of certificates to end users do) is verify that you control the domain you are requesting a certificate for.
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.
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.
But isn't the point here (and a source of confusion I share with all the other posters) that DNS is the actual root of trust? Heck, forget DNSSEC even, because it's not like Let's Encrypt demands it. You say that LE verifies
>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 value of certificate authorities is to be the roots of trust, as said.
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.
>The value of certificate authorities is to be the roots of trust, as said.
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.
This was proposed already in 2012 with RFC6698. DNS based Authentication of Domain Entries, DANE.
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.
Yes, and browsers solution has been to tunnel those queries over some protocol that middleboxes can not mess with. Because losing the DNSSEC fields is the lesser of the problems they cause.
There are a bunch of reasons why this doesn't work, but first among them is this: This would require browsers to make DNSSEC queries, and if those queries were blocked or otherwise failed, the browser would have to fail closed and present a certificate error. (The alternative, failing open and allowing users to visit a site if the browser doesn't get a response to the DNSSEC query, would be completely insecure, because the whole point of HTTPS is to defend against MITM attacks, and an MITM could simply block all DNSSEC traffic.) This is impractical because there are a bunch of existing firewalls and middleboxes that don't understand DNSSEC and that (contra Postel's Law) block DNS traffic that they don't understand; implementing this change would be cutting off everyone behind those firewalls and middleboxes from the Web.
> This is impractical because there are a bunch of existing firewalls and middleboxes that don't understand DNSSEC and that (contra Postel's Law) block DNS traffic that they don't understand; implementing this change would be cutting off everyone behind those firewalls and middleboxes from the Web.
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.
> Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure),
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.
But most of the websites today are not sending sensitive data back and forth, they are simply sending public data from public websites.
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?
Making 99.9% of websites ask for js permissions, and often break if the user clicks no, is just adding unneeded friction for the huge majority of cases. “Do you want to accept X” is also a terrible security boundary since most users won’t be able to tell when it is reasonable vs an attack scenario.
The HN community loves static sites and the old web. But this is a tiny tiny tiny minority.
> Making 99.9% of websites ask for js permissions, and often break if the user clicks no, is just adding unneeded friction for the huge majority of cases.
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?
You want that as a default. You aren't wrong for your own needs. But your needs are different than other people. The large majority of web usage is not interacting with documents. It is interacting with applications.
"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.
> But most of the websites today are not sending sensitive data back and forth, they are simply sending public data from public websites.
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?
> But most of the websites today are not sending sensitive data back and forth, they are simply sending public data from public websites.
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).
Contra GP, could you clarify how DNSSEC itself even important in this though? As far as I can tell, nearly all of my typical stack ultimately comes down to my domain. If my registrar, account with them, or DNS is compromised that's it. Let's Encrypt will cheerfully issue all the certs hostile attackers want. They'd have the ability to get most new emails (except for PGP/custom S/MIME) and in turn most accounts as well except for those with out of band pre-shared keys required (SSH, webauthn sites, maybe SMS). "Required", because realistically with that level of access many services that claim to require 2FA could probably be socially engineered around.
So I guess I'm confused how
DNS records hold a public key rather than _acme-challenge
would be any worse? Is it that while browsers may not be able to consistently get DNSSEC, Let's Encrypt consistently can for those that use it so it provides a weak bit of OOB workaround? I can see how that might be of some value, but not sure it's worth the trade off. I hope there's at least a concerted effort to someday secure DNS in general, thus making CAs (including LE) obsolete unless they do something beyond domain checks.
You seem to be looking at it from the point of view of attacks against the domain owner.
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.
Thanks for taking the time to flesh that out! I was guessing something like that might be it in a neighbor post, so automatic web CAs at this point are essentially a bit of a hack/workaround on a common inability of clients to securely verify DNS itself? And from reading it looks like there are plenty of ways to do that (from DNSSEC to DoT/DoH or even for low sophistication attacks simply hard coding a DNS server rather then depending on DHCP, though some of these themselves create other headaches), but those ways are far from universal and in some cases could have conflicts with other network middlemen?
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.
Are you saying, there exists some goofball who filters DNSSEC traffic, therefore DNSSEC isn't possible? If that's how you want to play it then Google now has a moral duty to implement NAPTR and SRV too. That way fallback and load balancing can happen in the Chrome client. Thus folks won't have to pay for BGP or VIP privilege anymore to be able to serve internationally.
IIUC the Chrome developers ran experiments to determine how many users would break if they rolled this out, and the number was above whatever they consider an acceptable threshold.
Which L Team member came to that determination? Would he or she like us to help by setting up public RRDtool monitoring of the policy impact on Internet properties?
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.
> ... DANE has been seeing deployment success for SMTP, ...
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.
MTA-STS doesn't so much "not require" DNSSEC so much as explicitly work around ever needing it; that's stated as one of the goals of the protocol in the RFC.
On the other hand HTTP was supposed to allow everyone to author and distribute content, or perhaps only to some people. Much like any protocol, issues start to arise when it starts seeing adoption: credentials mustn't be divulged to anyone on the network, a client must be sure the content is genuinely from who authored it and no one else, middlewares are funking up with content on the way, etc...
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 ?
HTTP originally didn't have credentials. If your site had a WWW server installed, you just put a file in your ~/public_html/ directory, and there it was on the WWW. Like, you could literally put HTML on the web by typing two lines of text into your shell:
mkdir ~/public_html/
echo 'My Samoyed is <b>really</b> hairy.' > ~/public_html/index.html
There were no headers and thus nowhere to put credentials in an HTTP request. We trusted the network because we didn't give root to people we didn't trust.
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.
> If the people steering the dominant browser projects think that allowing everyone to author and distribute creative work is important
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.
When I joined the internet in 1992, it was pretty symmetric among machines but not among people; I typically used a DECstation that had another 50 or so people using it at any given time, and we didn't have root. We couldn't set up an FTP server, and although we could run an HTTP server on port 8000 or something, we couldn't run it on port 80. And if we started up a long-running process, it was liable to get shut down for loading down the machine. We didn't have access to cron; I don't think we even had access to at.
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.
I don't necessarily disagree with what you said, but for every person who pays attention to the difference between HTTP and HTTPS, and understands what it means, whenever visiting a website, there are probably many more who don't.
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.
This would be a stronger point if the most popular provider of the service you would have to rely on wasn't a non-profit who provides their services for free and makes tools that are extremely easy to use and understand. It's a pretty fantastic outcome given the need for encryption in modern times.
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.
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.
That is only one, the most basic purpose and the only that self-signed certificates can do.
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.
Self-signed certs don't protect against active man in the middle attacks, but they do establish an encrypted channel that is secure against passive eavesdropping and after-the-fact decryption of network captures. So there's still some security benefit there.
There really isn't a real-world situation I can think of where I'd care about passive eavesdropping or after-the-fact decryption and not also care about active eavesdropping.
So I'm going to disagree. No, there is no security benefit to encryption without authentication.
While the impact of all these things are the same, the likelihood is not.
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.
You don't, but I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs) than no encryption.
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.
Yes they can. They simply decrypt, and reencrypt with their own self signed cert. If you have no way to verify the self-signed cert, you would never know.
> I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs) than no encryption
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.
> Of course it's worse when the user thinks the connection is encrypted when he actually has no idea who he's talking to.
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.
> 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.
> but now my traffic is in plaintext for anyone on the local network to trivially intercept
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?
So, a big concern which drove much of the adoption of HTTPS and other security technologies for the Internet is mass public surveillance, often justified as for "national security" purposes.
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.
> 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.
> a false sense of security is worse than having (knowingly!) no security at all.
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.
The brick wall (it's unfortunate that there have been overrides in Chrome under phrases including 'badidea' because they encourage people to use them, correct design here is to make the brick wall unpassable, that's why we built it in the first place) is only present if this site has HSTS or similar requiring HTTPS.
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).
Everything what you're saying is true, but it doesn't change the fact that HTTPS with self-signed certificate is more secure than HTTP.
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.
> I don't like that mindset that an unverified certificate is somehow not better or even worse (see browser UIs)
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.
> 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.
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.
It just moves the basis of trust from a diverse network of private CAs, any of which can be individually punished or distrusted if they misbehave, to the single centralized system of DNS, which rolls up to whomever controls your TLD of choice--entities who usually can't be removed, punished, or replaced.
There's a blockchain project that attempts to decentralize TLDs - people would actually own their TLDs (by cryptography!), and would issue their own certificates. Only you and no one else would be able to issue a certificate for your TLD.
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 :)
Lets Encrypt (and most other issuers) are happy to issue certificates to whoever controls the DNS for a domain, which could be your TLD administrator at their whim.
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.
I want to believe that somewhere out there, Orlando Bloom is signing everyone's certs with his usual ambiguous Legolas expressions. That typo was such a happy little accident.
Completely agree. HTTP isn't affected by any of the politicking going on in Mozilla, but it certainly affects users. Purporting to be a user-agent, Mozilla (and to a degree the other big browsers) have taken away a few of the sharp objects lying around, to extend protection to less savvy users.
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.
Its a hoop to jump through to get things to work- and an external dependency. I mean I remember the days when I first got a cable modem, I could just start up IIS or Apache and immediately have a web page on the internet. With a little hackery with dynamic DNS, it could be a "proper" webpage with a domain name.
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.
Self signed just means you have to create and distribute a CA cert, and your platform has to support adding CA certs. AFAIK Chrome, Firefox, IE, Edge, and mobile browsers on Android and iOS can do this.
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.
Indeed, the main problem of trust is the third party and agreement.
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?
Ugh. I have a bunch of "projects" of mine on the internet, many of which run the most minimal (I'm talkin [0]) http servers on embedded hardware and stuff like arduino where HTTPS just isn't possible.
And the only I keep them online is because they don't require any upkeep whatsoever, and don't rely on external services for certs or whatever, and because the occasional web browser stumbles upon them and finds them useful. I really don't want to actually put work into them though.
Users are all about privacy and security until they realise they have to actually maintain their websites to achieve it, then it becomes an unnecessary chore.
Not exactly your use case but when running software that has a complicated HTTPS cert system, I just add nginx in front of it and then use let's encrypt.
But what is "lost"? All the user gets is a warning that this site is not secure. Which is true. As long as browsers don't block these sites, or even until there is a maintained browser that can, this is just a necessary security feature.
"until this long list of conditions don't change, even though the industry has repeatedly changed these very constraints several times" is not something I would classify as trivial
These warnings are a preparation to permanently block pre-TLS1.2 HTTPS. For some time after that, you will still be able to set a hidden preference to unblock them, but sooner or later, the code implementing pre-TLS1.2 HTTPS connections will be removed.
Maybe we could use a doctype that allows for plain websites (no js, no forms, no inputs) to be accessed without a warning from the browser when not using https.
All of that can be achieved with CSP headers. But I think browser vendors will ratchet up their rhetoric and claim it's still unsafe and must be warned about because someone may learn which site a user visited.
MITM attacks aren't much of a problem if you are just displaying some static HTML from a random blog, can't show anything else, and the user has a large confidence his browsing history won't be used against him by any large internet party (any telecom, government, your hotel, etc, even the ones not on the obvious path).
I guess that last one is a pretty big dealbreaker, but I can understand somebody saying "it's just a site full of old jokes, I don't care about it".
Lost forever is the trust internet users shared twenty years ago. We didn't worry about exploits and security updates because we didn't have to. Even if somebody cracked a server, it was to learn and for the lulz.
Now that the global internet is overrun with cybercreeps we have to use TLS and release and deploy security patches regularly.
If the early net protocols had been designed security-first, we wouldn't have this situation. But, if they had been designed security-first, the internet wouldn't have taken off. TCP/IP would still be competing with MAP/TOP and the whole x.whatever stack.
While I personally agree with making the entire web run on https, I can definitely see the argument that it requires more monitoring and maintenance, especially when your certificate provider changes their protocol.
I wonder if there can be a future drive for a system where this is not required anymore, and where we can create a decently standardized form of encryption of the same or better quality as TLS, without being dependent on external services.
I agree with the author's points entirely, but I'm going to be the devil's advocate here and argue that this is fine.
Sure, old websites will stop working, but just as we shut down our FM radio and analog TV to make room for new amazing technology, and therefore rendered several generations of radio and TV devices useless, the internet will need to learn to live with the fact we can't possibly support its entire spectrum of functionality forever.
However, I see this as a tooling and ergonomics issue. Despite what people say about certbot, it is still not 100% trivial to use it. If your stack differs slightly from the canonical HTTPS server, you're gonna have issues. I'm not saying these problems are inherent to certbot, just that there is room for improvement.
Once we have normalized how certificates are signed and verified, and use encryption methods that can easily be tuned for increased computing power, and more importantly, once HTTP 1.0 is no longer an expectation, I believe the amount of manual work needed to maintain a server will go down again.
We're at a transition phase and we all know these are never easy (except if you're Apple and you're transitioning CPUs architectures, apparently).
My very, very old Telefunken FM Radio in my workshop full of dust and dirt works flawlessly. I tried to replace it with a modern, shiny one. But this new one broke after a few months. Now I placed the old one where it was for centuries and now it happily plays my favorite program again.
Analog TV had to be moved because it was taking up limited resources. Old websites aren't taking up valuable real estate. There's no benefit to shutting them down.
Of course there is. If they're HTTP, they're insecure, which makes them an open attack vector.
Modern computer security is about removing as many known possible attack vectors as possible.
So that's the benefit.
EDIT: to those saying browsers are sandboxed or that there's nothing sensitive, it projects against e.g. Comcast injecting JavaScript into pages from other sites. [1] There are all sorts of types of bad actors out there. Surely I don't need to list them all here.
There's no point having a web browser that doesn't browse just because it's more secure that way! Browsers have never had better sandboxes. Firefox disables certain features for sites served via plain HTTP. It's safer now to browse unencrypted sites than it was five years ago. There's no reason to remove functionality now.
Here I disagree. HTTPS gives guarantee to visitors of the site that they can trust the information being served to them.
A malicious actor hijacking plain HTTP connections does not necessarily have to inject code that harms the user's computer directly. He/she could also just alter bits and pieces of the served content to trick the user into doing something not in his/her interest.
So while having better browser sandboxing and protection is good (and welcome), HTTPS is still necessary.
Old and unmaintained websites are not collecting any information, let alone sensitive information. They’re mainly read-only, informative content that the web would be infinitely worse-off without.
> Of course there is. If they're HTTP, they're insecure, which makes them an open attack vector.
If so they are only insecure because malicious JS can be MITMed into them, and realistically speaking browsers can’t defend against malicious JS.
> Modern computer security is about removing as many known possible attack vectors as possible.
So let’s remove enabled-by-default JS permissions instead of removing HTTP-content. Most old websites don’t depend on JS and would in fact be just fine.
Even better: make JS opt-in only for HTTP websites, and let users like me refuse the “upgrade” to HTTPS.
> If they're HTTP, they're insecure, which makes them an open attack vector.
No it doesn't. HTTPS ensures that the data is not spied on or tampered with by those in the middle (so it does protect against what Comcast does), but does not prevent any other sorts of attacks (e.g. the server operator adding malicious files into their own server).
> it projects against e.g. Comcast injecting JavaScript into pages from other sites.
I should add a script to detect such things then, and if it finds one, display its own message to the user, to tell the user to disable JavaScript, with instructions about how to do so.
Indeed. As I understand it, *BSD users are currently left out of wildcard certs from Let's Encrypt. HN runs behind an nginx proxy because the forum software doesn't support HTTPS.
There are a few certbot clients for openbsd, at least. I’m using one that was written in bash with httpd, and I think they added a new one to the base image. Using the script was a bit annoying because I had to install bash from ports.
As on my Linux and Synology machines, the bash script has broken once or twice because it’s against modern best practices to define and stick with stable protocols.
Sometimes I think it would be easier to rewind to the 90’s web and build a sane ecosystem on top of that. Every aspect of the web that I interact with has gotten worse in the last decade.
(Also, HN’s is using a non-wildcard cert from digicert, at least according to my web browser).
I chose the bash client over the python client because I didn’t want to use pip to pull unvetted software from randos on the Internet. (Also, I hate python, and eliminating use cases for it makes me happy.)
Anyway, the bash script is still quite popular, and is extremely reliable. Since I used it, they eliminated the bash dependency, and now it is unix shell compliant:
Some old sites are valuable for archeology, some because they contain information that’s still true and not replicated anywhere else, some simply because they are interesting culturally.
To say it’s ok to bail on all old sites is to say that it’s ok to bail on all old books.
Someone put time and effort in to freely sharing these things for a reason, and it’s a loss for us all to throw it out in the name of “new”.
Books, under normal conditions, will not decay by themselves either. However a librarian is still very much needed to preserve and organize them.
The main issue is that HTTPS as it is developing right now is the antithesis of HTTP1. Everything that HTTP1 relies on is defines as bad by HTTPS. Either we change the direction of HTTPS or we drop HTTP. We can't have both.
Of course, if the server is up and connected to the internet, it will always be accessible by browsers that can be configured to ignore the missing HTTPS features, as it is now. But as I said on a different comment we should not rely on this being here for much longer.
The problems with archiving the web are numerous but I find it frustrating when this argument is used without getting historians involved. It feels like people use the idea of archiving as a cudgel rather than actually supporting real work in this area.
Funding is the core problem. My wife is a historian and every time the potential of things like digitization or archiving digital content comes up it always comes back to "grants are so incredibly small and archives don't have enough money to just maintain the books they already have, let alone expand". There's a lot of interesting research in this area but it isn't being put into practice because there is no funding.
Replacing FM radio is a huge societal mistake. Its simplicity enabled countless innovations that would and will not be possible with satellite radio. The technology (unlike analog TV) works perfectly fine for its core purpose and has numerous spinoffs (from radio clocks to OP-1 built-in radio sampler).
And as you sunset FM radio, you cut huge swaths of humanity out of yet another communications channel. FM radios are cheap, well-established technology, perfectly suited to mass communications (as in emergency alerts, etc). It survives suboptimal conditions (fuzzy broadcasts are still intelligible, receivers can be operated on hand-crank power, replacing equipment can be done at a dollar-store, etc). The amazing new technology that replaces it is without exception more complex, less reliable, and requires more infrastructure, and the associated costs invariable lock some segment of society out of participation.
On the web side of this analogy, we're so fortunate to have people like Neocities trying to rebuild those bridges to the beginners, the resource-deprived, and the other edges of society, but with every crank of this ratchet we (literally!) excommunicate another set of our species, and that's depressing as hell.
On the software side, we're getting HTTPS churn now, because we've only relatively recently started taking it seriously, after over a decade of ignoring it. TLS 1.0 is from 1999!
Hopefully, we'll eventually figure out how to make a TLS stack without endless buffer overflows and padding oracles, so it won't be necessary to upgrade servers all the time.
I like that HTTPS forces you to actually care about improving and maintaining your website. Somehow, leaving your site alone forever to gather dust is considered a good thing. The author totally missed that one.
Yes, some sites serve basic content that can stay up forever without change (thistothat.com comes to mind as a good example) but it really doesn't hurt to force people to put a little bit more care into their sites.
Books get written once. Why can't websites? We still learn from documents that are centuries old, and when a cache of them is found, it makes the news.
Yet on the other side, we let so much information expire because the underlying technology is obsolete.
Books are not going to turn into a botnet node.
Books hardware is not getting less efficient when new paper is produced.
Electronics will not live centuries unless you spend loads of money to maintain it.
- Book contents frequently get updated. Revisions, translations, editions, adaptations.
- Book formats see change. There are at least some works which have seem multiple forms (oral traditions, clay tablets, vellum codices, stageplays, printed books, operatic adaptations, three-ring binders/loose-leaf circulars, magazine serials, paperbacks, radio serials, cinema series, comic-book adaptations, Broadway musicals, TV series, PS documents, PDF files, podcasts, videogame adaptations, YouTube channels, ebooks, ...)
Generally, websites are less a document format than a publishing mechanism. Print-on-demand-on-steroids.
We have the Internet Archive (archive.org) to backup lots of this information via the likes of the Wayback Machine.
Books & physically documents can decay naturally or be damaged physically, digital media can be damaged physically too. A hard drive or SSD can fail at any time, a disc can be scratched, a tape can get tangled. Easier and more accessible redundancy is an advantage of digital media.
But if you really wanna run a webserver for the next 20 years without maintaining it, isn't HTTPS the least of your problems?
What about system and software updates to fix critical vulnerabilities? Hardware failures? I feel these things would take much more maintenance time than the occasional certificate renewal.
I’m pretty sure ftp only works on browsers with patches/flags to enable it that are added by district maintainers. I remember most major browsers dropping it in official builds.
All this switch to HTTPS just so Google can guarantee its ads are being seen. You get some other benefits as a side effect... but that is the real reason HTTPS is everywhere.
The root problem here seems to be that web browsers (and to some extent servers) have become quite insecure in practice due to the insane complexity of all the different protocols they now support. If you are using Mosaic to access ancient web sites the most an attacker can do is to change the content.
Now remote attackers have a simply vast attack surface. They can actually run code on your computer. History has shown such code can never be perfectly sandboxed. So you need to be very sure you are where you think you are and that you are only getting content from that place. TLS is an essential band aid fix.
The same sort of thing comes up anywhere HTML is used. People sometimes claim that email is inherently insecure. In most cases it turns out that html email is inherently insecure.
It seems that any popular protocol eventually gets extended to the point where it is impossible to keep it secure. It also seems that the popularity of the protocol causes a period of denial.
Let’s be honest: remote attackers could run remote code on your computer running mosaic a lot easier than today with modern chrome.
RCE in mosaic or Netscape was probably trivial, it just wasn’t as well studied as today. Just look at how many times those browsers would crash in the normal course of web browsing, even back then. Nobody was intensely fuzzing their html parsing engines, image processing libraries, scripting elements, plugins etc.
Heck, IE used to load and run arbitrary code as “activex” controls. No fancy exploit needed!
Opera not much, it was pretty decent and full of features. But nearly all decent "web" software required IE with Active X thru an OCX. Also there was a Netscape plugin I think.
I don't agree... I think browsers are not the weak link here.
I'll agree they have a large attack surface, but the communication channel needs to be secure regardless of what client receives it.
> the most an attacker can do is to change the content.
Sure , but I would argue, depending on on the content, that malicious content can be just as bad as malicious code. Just ask anyone who has been phished.
> Even with automated renewals, Let's Encrypt has changed their protocol once already, deprecating old clients and thus old configurations, and will probably do that again someday.
Just another hurdle to our effort to make things last on the Internet [1]
> In the era of HTTP, you could have set up a web server in 2000 and it could still be running today, working perfectly well (even if it didn't support the very latest shiny thing).
I'm not sure this assumption is right, looking at the CVE list and in particular entries associated with Apache.
I agree - it's completely naive to believe that any software deployed 20 years ago, and open to public attack, with zero maintenance wouldn't be attacked, and compromised.
I'd like that to be the world we live in - and with the continual evolution in secure programming practices, maybe one day it might be, but it's not.
As a profession of software engineers, we have not achieved the level of quality at the costs that is willing to be met to engineer public facing websites that won't be vulnerable to attack at some point in the next 20 years, and will still be running.
On the other side, it is now almost impossible to use the internet on a retro computer.
I absolutely understand the drive to use more secure TLS, but it's a really sad experience to see that you can load Google, but have nearly every link unable to load.
It wasn't that long ago that I could try out some ancient browser on some modern website, and at least see it fail to render well. Now you can't even connect.
This leads to interesting situations with, say, PowerPC Mac software sites. Either they have http connections, or they use user-agent sniffing to downgrade TLS.
> This leads to interesting situations with, say, PowerPC Mac software sites. Either they have http connections, or they use user-agent sniffing to downgrade TLS
That doesn't work. The user-agent is passed after the encryption channel is established.
What they do is offer all the options, and the client picks the best one they can support.
However, why would this need to be HTTPS to begin with? If you're not transmitting anything private, HTTP works just fine.
Downgrading TLS only works so far, a lot of older clients won't understand SHA-256 signatures on modern certs. I don't think anybody will do SHA-1 certs anymore, so you would need to give those users a self-signed certificate or something.
...and old web navigators. Protocols evolve, security requires old encryption schemes to go away, thus the OS you use has to keep up as well, and if you try to use a reasonably old live bootable DVD, you might have some surprise.
466 comments
[ 5.5 ms ] story [ 280 ms ] threadI also disagree with the idea that HTTPS introduced the problem of requiring maintenance; anything you expose to the public internet needs maintenance and security upgrades.
Is there a better way? I r not cryptographer.
It's a bit like complaining that you can no longer take your origami collection outside without an umbrella. Well, the umbrella isn't the problem, the rain is. The umbrella is a solution. But of course being under an umbrella isn't the same as being outside on a sunny day. So sure, lament the change in the weather; lament the inconvenience of carrying an umbrella around all the time; but don't blame the umbrella for the rain.
It wasn't very safe a few decades ago either.
In 2000, I had naively set up a Linux box under my desk with a public IP, thinking maybe I could host a blog on it. It got a number of portscans within minutes of being set up, and subsequent monitoring showed lots of intrusion attempts. Luckily the box was patched, but I was essentially one zero-day away from being 0wn3d. But I did learn a lot before moving the box behind a firewall.
I guess that back in the day, some people could wish these away as unproven threats well into the early 2000s until malware like Nimda / Code Red well and truly destroyed that illusion.
For example, if your "old" server is a colocated physical server and your proxy server is a fancy cloud VM.
IMO: https is actually overhyped, it solves some problems but has plenty of its own
If it can't run a modern web server as a proxy directly.
Then maybe you could set up a VPN tunnel between the server and your fancy cloud VM.
But running some ancient hardware not for historical reasons but taking user data, is wrong.
They could use something like VLAN to isolate that physical server on its own network, put the VLAN behind a firewall, and have an HTTPS reverse proxy that goes through that firewall.
Depending on how their network is built, it might even be possible to make this self-service where you enable a setting in your account and your physical server gets wrapped in this additional layer.
Eh. I sort of disagree with this specific phrasing.
People shouldn't focus only on targeted attacks on the server. Of course if you have an HTTPS proxy in front of an HTTP server, you can be MITMed between those two servers, and that's very bad.
But even with that flaw you're getting benefits. Public networks can't inject malware/ads into that webpage, a MITM attacker between your proxy and the main server will have a harder time correlating a request with a specific person, ISPs will have a harder time scanning the traffic for use with ads/metadata.
This is a similar argument that comes up sometimes about VPNs. I know people who argue that a VPN does nothing because it just moves trust from one party to another. But the reality is that if you search my public IP address, you will get a pretty decent approximation of where I live. In a world without a VPN, I'm not just choosing whether or not I trust my ISP, I'm choosing whether I'm comfortable giving a decent marker of my physical location to literally every single website that I visit.
That doesn't mean the "moving trust" concern isn't valid, it just means it's not the full picture of what a VPN (either privately hosted or through a 3rd-party) protects you from.
In the same way, it is a valid concern that behind the scenes data might not be encrypted between a proxy and a server. But that's not the full picture of what HTTPS protects you from. HTTPS also protects you at the router/network level.
Although this argument doesn't allow for the huge number of websites that are not on the public Internet, but instead running on someone's internal network or embedded in some device.
It is a dangerous trend for us to rely on browsers made mostly or entirely by businesses who care little for those environments because they make no money from them. There are good reasons that long-lived standards and forward compatibility are important, not least that whoever first developed some useful in-house service with a web front-end or manufactured some long-lived, high-value device may no longer be around to update things routinely according to the whims of Google or whoever.
The issue is that the security landscape has gotten so much worse and continues to become more hostile, and private IP address space and a packet filter don't provide nearly as much protection as a lot of people want to think, and attacking internal applications from "outside" is commonplace. The trend towards zero-trust and such is driven more by the fact that there's no such thing has home anymore, at least as far as networks are concerned - there's no realistic way to keep the internet out.
And those IoT devices with long-lived security holes are landmines, not assets. I'm much less worried about "long-lived, high value" ones, because those are far more likely to get updates than cheap, fire-and-forget webcams and such.
I agree entirely that forward-compatibility is an extremely important consideration. Security, however, frequently pulls in the opposite direction, leaving an unpleasant tradeoff.
The trend will not reverse - I don't see how it realistically could. We live in the Red Queen's world.
The world is far bigger than cloud computing and IoT devices. There must be millions of little in-house web applications someone wrote long ago that are still useful, probably running on some 10-year-old PC in the corner, with some sort of scheduled back-ups if you're lucky. There is also no guarantee that even a high-value, long-lived engineering device manufactured a decade or more ago and still in perfect working order also still has ongoing software support. There is a huge amount of value locked into these old systems, and arbitrarily dismissing their relevance if they don't meet modern security standards that may or may not even be relevant in all the circumstances is like designing a building with such robust security that no-one can get inside, even the owners.
Hi. I've been online since 1982, when I built my own modem from parts sold out of the back of a magazine. What you just wrote might as well have been instructions for assembling a DIY fusion reactor, for all I know.
That's what the author means when he suggests that something is being lost. I now have no realistic choice but to go through a centralized gatekeeper to post content on the Web. That sucks. It wasn't supposed to be that way.
So there is new stuff you need to know. On the other hand, these days you'll find that blog post that walks you through installing nginx and certbot on your $5/month VPS, prepackaged with dependencies, just works out of the box, in a very short order. From what I recall from the late 90s, setting up a plain old fashioned HTTP server felt a lot more difficult then.
That's my home internet connection.
I've got a laptop in my cupboard that is connected to my router.
That's my server for a lot of simple things.
This is the critical part. Even though Let's Encrypt is not-for-profit, etc. It is still a single entity. Until someone can go and start their own CA in that 10 minutes that works across the world, we're moving away from and not towards what HTTP was.
These are just the general (and unsolved, or perhaps even unsolvable) problems associated with PKI. I think there’s a solid argument to be made about separating the encryption of communication from the authentication of server identity. That would solve one problem, but it would also just take an existing bad problem and (arguably) make it a lot worse. Given all of its horrendous shortcomings, the CA system is still the most successful PKI ever created, by quite a large margin.
It is worrying that Let's Encrypt is currently the only major provider of free, relatively easily arranged certs, though. Its success has been impressive, but it's probably also one of the biggest single points of failure in modern Web infrastructure now.
All decentralized web of trust models lean towards one of those problem categories. They can be too onerous to be usable (like the original PGP proposal), easily abused, or simply create even more dubious shadow authorities. There is no known PKI model that solves all of those problems at once, and not really any basis for even presuming it’s possible.
Yes, any such method would inevitably require a different process to how things work today, most likely including some sort of administrative action to get a new domain recognised when setting up a new site. Still, if you'd suggested seven or even six years ago that anyone would be able to set up effective HTTPS hosting with relatively little effort and without paying for an expensive certificate from some big name CA, you'd probably have been laughed out of the building. Five years ago, Let's Encrypt was starting its rapid rise to dominance, and as the various limitations in the original scheme have been removed, that rise has shown no sign of slowing down.
The PKI you choose for the internet needs to work for all internet users. The web of trust model only works for highly motivated and technically competent users, and even then, such a user cannot possibly authenticate all of the identities they need to for typical internet use. They end up with a small group of people they can communicate with more securely. They aren't heading off the google HQ to sign their TLS keys, and if they discover a new web service they want to use, they're not going to hold off on using it until a proper key signing ceremony can take place.
Such a system is not fit for the purpose of securing internet communication, and it's not fit for use amongst the majority of web users. Your options for improving those shortcomings is to either create a system that can easily be gamed, by requiring users to trust some sort of community consensus, or to establish trusted authorities (which is just reinventing CAs, and probably in a way that's worse than the current CA system).
The web of trust model simply cannot work for this purpose, there's currently no plausible approach for improving it, and it's not obvious that such an approach is even possible.
That depends on what you're trying to prove. At the moment, CAs typically accept that someone attempting to create a certificate for a certain domain is the legitimate owner if that person can demonstrate immediate control over something like the content of the website or the DNS. Attempts to enforce stronger verification, such as EV certificates, have largely fallen flat. An equivalent standard would be no worse as the basis for a web of trust system than it is as a basis for major CAs issuing certificates today.
The biggest problem with today's CA system isn't that there are trusted authorities, it's that for any given cert there is one and only one ultimate trusted authority and if there are further certs involved then the dependency chain is strictly linear. This creates both gatekeepers and single points of failure. A system where multiple reputable sources could indicate their trust in a certain identity and where authentication was based on looking for multiple trusted paths to verify a claimed identity would address several of the practical weaknesses of our current CA-based infrastructure.
Just to clarify, I'm not necessarily talking anything as specific as signing a certificate. I'm talking about the problem of authentication in general, whatever mechanism it might use.
Maybe we're talking at cross-purposes as I'm not sure exactly what problem you're trying to solve here, but my argument is that the main problem with existing CAs is that they represent single points of failure in several respects.
Authenticating against multiple sources from a potentially larger pool does then change the dynamics in exactly two very important ways: it means neither the site host nor the site visitor is reliant on a single CA and thus a single potential point of failure any longer. This isn't a complete solution to all possible problems with the existing CA system, but it does offer a conceivable way to mitigate some known weaknesses in that system.
Getting that far doesn't really even need a full web of trust system, just a mechanism for seeking confirmation from N of M ultimate authorities where N is chosen such that 1 < N < M with whatever safety margin on either end you deem appropriate. But a more comprehensive web of trust would potentially allow for a fully decentralised system in the sense that anyone could operate their own final authority but how much it was trusted would depend on the properties of the web (as would how much any default authorities included with browsers as standard were or potentially were not to be trusted).
The core issues with PKI are establishing trust. The only way to do that for most applications requires an authority. You’re not improving the system by requiring multiple authorities to sign every certificate. You’re not making things less authority-reliant or more resilient. You’re just making it more complicated, and leaving the real underlying issues around authentication unchanged.
Would you trust the authenticity of content that originated from a site signed with such a CA? If so, why?
PKI is just a technology for verifying trust over untrusted channels. But that trust is created in and remains rooted in the real world, and is itself built on societal chains of trust.
No technology, centralized or decentralized, will replace real world trust in human societies any time soon. Trustless tech only works if it's based on a society with trust. Otherwise the tech is meaningless.
I don't know where you got that. You'd install an nginx (or caddy, my preference) reverse proxy on exactly the same hardware you were running your HTTP site, or if that machine is too foreign you can buy an old laptop, put the reverse proxy on it and forward to your site. There is nothing centralized with that.
The person above forgot that those things require a lot of skill and experience just to understand what you're told to do. We're a long way from building websites with FrontPage and uploading them over FTP.
The thttpd web server can run modern TLS with this approach, and the footprint is much lighter than with Apache.
Uh, no — in the past you could have purchased a hosting solution, that does it's own TCP termination (such as shared hosting) to completely forget about your site. Many static websites still exist solely because of that.
Now you can accomplish the same thing by paying Cloudflare (or some other party) to terminate your TLS connection. One more kind of parasites has been enshrined in technological stack.
Now, of course that's an item on the maintenance list if you're hosting the web page yourself, but as mentioned above: You still need regular updates, having certificate renewal on that list doesn't make any noticeable difference.
The point of the article is that not even this is enough, because letsencrypt will change protocols, TLS versions and ciphers will be obsoleted, etc etc.
Basically your entire stack will need to be kept continuously up to date.
Just setting up Nginx in a Ubuntu LTS release won’t be enough, because you always will need to have everything up to latest always. And obviously you need to automate that self-update process too.
So because the browser is insecure and allows JavaScript, everyone else who wants to serve a simple index.html will now need to be a full-on DevOps-expert.
To me that sounds pretty backwards. How about we just fix the JavaScript-security issue in the browser instead? Or would that be just too simple???
This is breaking the web in the sense that everything which is old will perish instead of being preserved.
Maybe I’ll go back to making my sites HTTP only. It certainly sounds simpler and more reliable than this...
Then ask someone to foot the server bill. See how many takers you get.
This is fine for corporations with IT departments, but when I was a high school student, I had a web page, and my web server was sitting under a desk in a random office. When I was in college, professors ran their own web servers.
A lot of innovation bubbled up, bottom-up.
Big tech stuck that with a fork. That's not a good thing.
Look at how many useful but Java-based demonstrations on academics' websites became inaccessible when the browsers decided Java plug-ins were evil and should be removed. What happened was not that people who had voluntarily spent considerable time over the course of possibly several years developing useful little bits of software suddenly dropped everything to redo all of that work again in a different language just because the browser developers had decided that other language was now flavour of the month. Instead, lots of valuable work was effectively lost.
How? It's Java. You should be able to download the JAR and run it on any compatible JVM.
This has also come up with Flash, where Adobe still hasn't opened up the technology to the point where people can effectively emulate it.
If a technology is insecure, and it gets removed from a specific environment for security reasons, and simultaneously a company makes it so that it's impossible to run outside of that environment -- the deprecation wasn't really the problem then.
The reason we've lost massive numbers of Java applets and Flash apps isn't because they got deprecated from web browsers, it's because alternative environments and emulators were never built or given the support they needed. Mozilla/Google can't just decide to change the Java security model for native applets.
The changes by the plug-in developers were often unhelpful in the final days before we gave up on those technologies entirely, but let's not pretend they were the root cause of the plug-ins' demise.
That's a very good point.
I don't think they were the root cause, but even though there are scenarios like you're talking about, I still think we'd be in a different world today if different companies were handling those plugins.
It's worth noting that from a preservation perspective, today we're at the point where people are pretty realistically looking into emulating SWF runtimes in Javascript inside web browsers. If that happened, you wouldn't even need click-to-play. SWFs would just work with the same sandboxing guarantees as the browser.
The biggest reason that hasn't really taken off is because the SWF format still hasn't been opened up. The reason why there isn't just a drop-in WASM library that lets you run Flash code on the web is because of Adobe, not Mozilla or Google.
Of course, especially in the case of Java we could only ever emulate features that browsers support. But that's why the plugins were deprecated in the first place; because they supported inherently insecure features that we either don't want in the browser, or don't want to support in the same way.
But that's true for lots of platforms, and yet I can already run C/Rust/Lua code in a web browser. The Lua runtime had been cross-compiled to ASM.js before Flash was dead (although today we have a lot better speed). But the difference between Lua/C and Java was that the most common Java runtime was proprietary. OpenJDK browser plugins would break most sites that I was using. So there wasn't anybody who was sitting down to say, "excluding the features that browsers don't support, is there any of this code that's salvageable?" They weren't really allowed to do that.
If someone can own my browser by mitm’ing a static html page, then they can do it more easily by serving malicious ads, or using seo / social engineering to steer me to a web server they control. I don’t buy that argument.
Also, browsers could run in a simple and secure legacy mode when they connect via http.
Even if there are good reasons, it;'s still effectively deleting decades worth of the internet.
To blithely say that it's trivial to slap together a reverse proxy and keep it updated is both factually wrong and missing the point: something has been lost, and it's sad.
:) What if, purely as a theoretical proposal, they display the webpage as normal, but just show a little icon in the address bar that marks the website as insecure?
Have I missed something? Is anybody actually talking about removing HTTP support from browsers? I don't think that this is the same scenario as Java or Flash at all, HTTP still works fine. All of the static websites that people are complaining about losing still load without any problems.
And even if it was the same scenario, Java is not a great example to use here, because the deprecation of Java and Flash, as painful as it was to many people, was also very clearly, almost universally recognized as necessary for security.
Java and Flash are probably the two best examples you could come up with if you wanted to argue, "sometimes it's necessary to take painful steps that break things to make a secure system. Sometimes you can't trust developers to do the right things until you force them."
Am I sad about Flash and Java? Of course, I have a fair amount of personal background in that area. We lost precious things. But should we have kept Java? No, of course not. Obviously not, that would have been such a terrible idea for both security and the Open web. I remember the pain of trying to get decent Flash support on Linux. It was a fantastic, open system for some people. But it was also proprietary, and filled with security holes, and being used in ridiculous ways for DRM and circumvention of Open browser standards, and frankly, the slow deprecation path just wasn't working.
I wish Flash had been handled better, but... I mean, we did have to get rid of it. I don't believe anyone could seriously argue to me that the web would be better if we were still using Java and Flash today.
So even in a theoretical world where we're actually talking about deprecating unencrypted HTTP support, we should still only be talking about preserving or emulating sites that will be lost. We shouldn't be talking about continuing to do something that's insecure.
I'm not sure arguments about the proprietary nature of the old plug-ins are very strong either. After all, the main cheerleader for dumping them initially was Apple, but to this day Apple relies on proprietary and patent-encumbered technologies for playing multimedia content on iOS where just about everyone else in the world is using technically superior formats with open standards by now.
I don't know if I would claim that the web would be better if we still had Java and Flash today. I think there are too many different dimensions to consider to make such a blanket statement. But I do think a lot of value was lost by turning them off, and I do think the security and openness benefits have been overstated, not because the plug-ins weren't deeply flawed in those respects but because people seem to overlook the all too similar failings in the replacements.
Only for people who were security conscious and willing to not load certain web pages. For normal people, click-to-play was just another pop-up to click through. I do generally support people's abilities to choose to do insecure things, but there's a strong argument that the point of the web is to securely run untrusted code, and allowing developers a single step to bypass that sandbox is kind of antithetical to what the web is.
> Perhaps more importantly, would an objective assessment of today's browsers really find that they are significantly more secure than the plug-ins were
I would be very surprised if this wasn't the case. It's not just that modern browsers are less bug-ridden, it's also that their permission models are fundamentally different. HTML5 still doesn't allow you the same level of filesystem access that Java and Flash did, and its replacements allow debugging and extending at the DOM/script/network level. It's hard to imagine a version of adblockers that would work with Java applets. In contrast, I can use uMatrix to turn on/off individual request types to specific subdomains.
I mention elsewhere that part of the problem with deprecation was that none of these companies allowed for effective emulation of the web stack. To be fair, part of the reason why emulation was (is) hard is that to this day, Java applets and Flash applets still have capabilities that can't be emulated in a web page. But that's also part of the security problem; we don't want those capabilities to be emulatable.
> because people seem to overlook the all too similar failings in the replacements
Flash just didn't work well on Linux. I couldn't watch Youtube videos. I remember how excited I was when Youtube started moving to HTML5 video containers instead of Flash, because the web doesn't have those problems, and I was so sick of trying to configure Flash plugins for Firefox in Ubuntu. Java plugins were also an issue, albeit to a somewhat lesser extent. But I used to always curse whenever I would see a Java plugin loading up, even as recently as 2015-2016 when I was using legacy enterprise apps. Not to mention Silverlight -- it's annoying that Apple uses proprietary codecs, but for a long time I just couldn't recommend Linux to anyone who wanted to have a Netflix account.
People have a rosy view of these systems, but they weren't necessarily the open utopia that people remember. They just worked well for some people in some configurations.
Given that post-deprecation Adobe still hasn't open-sourced any of its SWF runtime, I don't think there's strong evidence that this would have gotten any better without moving away from proprietary technologies and forcing devs to use Javascript. By and large, I think the replacements have all been a lot better. The only big exception I can think of is the awful DRM proposals for video, but at least the technology works mostly cross platform.
Even at the video level, a proprietary video codec just isn't comparable to a black-box piece of code where I can't look at the network requests, that has a completely separate permission model from my browser, etc... There's a reason why everyone was comfortable providing DRM in Flash/Java/Silverlight, but why in a post-plugin world Google felt it was necessary to provide a completely separate 'solution' rather than just move the DRM into Javascript.
I strongly suspect that the security arguments were always more of a convenient smokescreen than an honest concern. Browser developers wanted to drop Java applets because they wanted to dump some legacy plug-in infrastructure that was painful to maintain, and their management probably viewed support for old and unprofitable technologies as an acceptable loss to achieve that goal.
Forever.
It's sad.
Internet connections are much faster. Most people aren't under CG-NAT.
Even a raspberry pi can be a server.
What are you arguing here?
Why is your tech illiterate mum setting up a http server but can't do https?
Wouldn't it be better to create a blog on medium?
Or a site on square space?
How about a free site with GitHub pages?
I just don't understand the idea that people want to set up something and forget about it. That's how you get hacked and turned into part of a botnet.
(1) The poster arguing this was 10 minutes was being dishonest.
(2) As the original article said, it's a different internet if the only way to get something up is to go through Square Space or Github pages. It's much less decentralized, and much more corporate.
Yes, I do think the internet could have evolved to where a tech-illiterate mum could host her own web page from her router at home. It didn't, and we lost something in that process.
The time it takes to do an action is not enough to evaluate the task
Would work with anything ethernet enabled as far as I know. I never worked with SGI Irix or DEC Ultrix but I assume that they can handle ethernet connections if they are serving websites.
I have an SGI workstation and an HP workstation next to me. They cost $0.
That was >15 years ago, freecycled. Pretty sure they are less than $0 by now!
It's a workplace server as well, so I don't really have the freedom to punch holes for outside access.
The crucial question is: do you control your users's DNS?
I had a setup like this in college, and wrote this: https://blog.sdslabs.co/2014/07/sdslabs-domain-working
There's currently no way on any modern system, as far as I'm aware, to install a CA but limit it to only a specific domain and its subdomains; any CA you install can issue a certificate for any domain. (There are theoretically some certificate extensions that allow limiting a certificate to subdomains, but as far as I can tell, implementations don't reliably support those extensions.)
Such names are a bad idea for a wide variety of reasons and you should definitely look to give the machine a name from the Internet's DNS (even if the machine isn't accessible in any way from the public Internet), but assuming you cannot or don't want to for now:
You can use a variety of thin "reverse proxy" services to just wrap the HTTP service as HTTPS. Many such webapps won't care that this happened, as the maintainer you probably have a good sense of whether it could work (does the webapp use Javascript that cares about its own URLs for example because that could be a problem?). HTTPS servers such as nginx are well suited to this problem. Security between the wrapping proxy HTTPS server and your PHP on IIS setup is still zero in this setup but that might be acceptable.
Only problem is that you'll need to update DNS records every three months to get a new cert; some DNS providers have APIs that certbot can use.
I think however, that authors point was moot already - your network connected machine can't be static, it shouldn't be in years. There are constantly new RCE's and other exploits since ages. Your network connected machine must be maintained, whether it's a basic web server or your phone.
Why not? Imagine if it's a purpose built webserver on a microcontroller[^1] which only serves strictly static pages or text files.
[^1]: http://tuxgraphics.org/electronics/200611/embedded-webserver...
For instance if I was running a server on an 50 yo IBM framework serving static pages, how many serious attack vectors have been left unpatched at this point ? (ignoring DDOS type of issues where the content is not compromised)
And many/most of them connected to the TSL/HTTPS-stack, due to the complexity it brings.
Of course people would need to be educated on those risks, which would probably be the biggest issue.
Frankly, that's impossible in any reasonable timeframe compared to just not allowing unsafe "huts".
If you don’t keep up the repairs, eventually the roof fails, rain gets in & then it’s a relatively quick slide into total ruin.
> (At the same time this is necessary to keep HTTPS secure, and HTTPS itself is necessary for the usual reasons. But let's not pretend that nothing is being lost in this shift.)
So, to stay within your analogy: He acknowledges the need for new houses, but says that huts had a unique flair which is lost now.
Try to setup a windows 98 machine as a web server and see how it goes (Windows XP only came out in 2002). It doesn't do HTTP/1.1 so it's good question whether clients would be able to connect at all.
Windows 98 was a client OS, it was never intended for this. A proper test would be Windows NT 4.0 Server. Or more realistically for the time frame, Solaris 7 or 8.
Obviously forget about any security.
When you're running a server, TLS is not the only service you are dependent on; you're also dependent on security updates. If they're not backported, you'll need to make version upgrades.
Arguably it's better to think of every piece of software running on a server like it's a service, to maintain security and performance in an Internet full of hostile actors.
I don't even understand the mindset of wanting to run a live server on ancient software, aside from doing it as a hobby. In which case, it's pretty typical for such hobbies to require extra work and care. Driving around in a car from 1940s takes more maintenance work, and is less safe, than a modern car, and everyone gets that.
Of course, I was rolling my own query sanitizers, which was the style at the time; and my php.ini did allow GET/POST to inject global variables. Not to mention CVEs discovered between now and then. So I wouldn't want that server from year 2000 to stay running untouched, but win98 is a strawman.
Could have been yours ;)
Just so you know, Windows 2000 is vastly more stable than the 9x branch and is perfectly usable, so you should upgrade.
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.
I think the main reason is that they're on the whole pretty racist towards dwarves.
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.
solve the root trust problem and claim your nobel prize.
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
would be any worse? Is it that while browsers may not be able to consistently get DNSSEC, Let's Encrypt consistently can for those that use it so it provides a weak bit of OOB workaround? I can see how that might be of some value, but not sure it's worth the trade off. I hope there's at least a concerted effort to someday secure DNS in general, thus making CAs (including LE) obsolete unless they do something beyond domain checks.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.
https://stats.dnssec-tools.org/
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.
---
[0]: https://tools.ietf.org/html/rfc7672
[1]: https://tools.ietf.org/html/rfc8461
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.
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 ?
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.
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.
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.
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.
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.
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.
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.
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?
And the only I keep them online is because they don't require any upkeep whatsoever, and don't rely on external services for certs or whatever, and because the occasional web browser stumbles upon them and finds them useful. I really don't want to actually put work into them though.
[0] https://stackoverflow.com/questions/16640054/minimal-web-ser...
Not exactly your use case but when running software that has a complicated HTTPS cert system, I just add nginx in front of it and then use let's encrypt.
This is the trend though, and ultimately I get the impression that Google/Chrome will just say "no".
Not an expert on SEO, but I remember Google saying back in 2015 that sites using https will be preferred in search results?
These warnings are a preparation to permanently block pre-TLS1.2 HTTPS. For some time after that, you will still be able to set a hidden preference to unblock them, but sooner or later, the code implementing pre-TLS1.2 HTTPS connections will be removed.
I guess that last one is a pretty big dealbreaker, but I can understand somebody saying "it's just a site full of old jokes, I don't care about it".
Hard ask given how many don't work with JS disabled.
Now that the global internet is overrun with cybercreeps we have to use TLS and release and deploy security patches regularly.
If the early net protocols had been designed security-first, we wouldn't have this situation. But, if they had been designed security-first, the internet wouldn't have taken off. TCP/IP would still be competing with MAP/TOP and the whole x.whatever stack.
I lament the loss of innocence.
"Hell is other people."
I wonder if there can be a future drive for a system where this is not required anymore, and where we can create a decently standardized form of encryption of the same or better quality as TLS, without being dependent on external services.
Sure, old websites will stop working, but just as we shut down our FM radio and analog TV to make room for new amazing technology, and therefore rendered several generations of radio and TV devices useless, the internet will need to learn to live with the fact we can't possibly support its entire spectrum of functionality forever.
However, I see this as a tooling and ergonomics issue. Despite what people say about certbot, it is still not 100% trivial to use it. If your stack differs slightly from the canonical HTTPS server, you're gonna have issues. I'm not saying these problems are inherent to certbot, just that there is room for improvement.
Once we have normalized how certificates are signed and verified, and use encryption methods that can easily be tuned for increased computing power, and more importantly, once HTTP 1.0 is no longer an expectation, I believe the amount of manual work needed to maintain a server will go down again.
We're at a transition phase and we all know these are never easy (except if you're Apple and you're transitioning CPUs architectures, apparently).
Modern computer security is about removing as many known possible attack vectors as possible.
So that's the benefit.
EDIT: to those saying browsers are sandboxed or that there's nothing sensitive, it projects against e.g. Comcast injecting JavaScript into pages from other sites. [1] There are all sorts of types of bad actors out there. Surely I don't need to list them all here.
[1] https://thenextweb.com/insights/2017/12/11/comcast-continues...
A malicious actor hijacking plain HTTP connections does not necessarily have to inject code that harms the user's computer directly. He/she could also just alter bits and pieces of the served content to trick the user into doing something not in his/her interest.
So while having better browser sandboxing and protection is good (and welcome), HTTPS is still necessary.
If so they are only insecure because malicious JS can be MITMed into them, and realistically speaking browsers can’t defend against malicious JS.
> Modern computer security is about removing as many known possible attack vectors as possible.
So let’s remove enabled-by-default JS permissions instead of removing HTTP-content. Most old websites don’t depend on JS and would in fact be just fine.
Even better: make JS opt-in only for HTTP websites, and let users like me refuse the “upgrade” to HTTPS.
No it doesn't. HTTPS ensures that the data is not spied on or tampered with by those in the middle (so it does protect against what Comcast does), but does not prevent any other sorts of attacks (e.g. the server operator adding malicious files into their own server).
I should add a script to detect such things then, and if it finds one, display its own message to the user, to tell the user to disable JavaScript, with instructions about how to do so.
https://github.com/acmesh-official/acme.sh
As on my Linux and Synology machines, the bash script has broken once or twice because it’s against modern best practices to define and stick with stable protocols.
Sometimes I think it would be easier to rewind to the 90’s web and build a sane ecosystem on top of that. Every aspect of the web that I interact with has gotten worse in the last decade.
(Also, HN’s is using a non-wildcard cert from digicert, at least according to my web browser).
The Arc Language app that this forum runs on doesn't support HTTPS, so wherever the cert comes from, accessing the site is through a reverse proxy.
https://man.openbsd.org/acme-client.1
I chose the bash client over the python client because I didn’t want to use pip to pull unvetted software from randos on the Internet. (Also, I hate python, and eliminating use cases for it makes me happy.)
Anyway, the bash script is still quite popular, and is extremely reliable. Since I used it, they eliminated the bash dependency, and now it is unix shell compliant:
https://github.com/acmesh-official/acme.sh
I would definitely use it in the future if I was configuring a Linux box to renew certificates.
The breakages I encountered were all on the Let’s Encrypt side, and broke all the clients, including the official one.
Anyway, it has been trivial to use Let’s Encrypt with OpenBSD for many years.
To say it’s ok to bail on all old sites is to say that it’s ok to bail on all old books.
Someone put time and effort in to freely sharing these things for a reason, and it’s a loss for us all to throw it out in the name of “new”.
The main issue is that HTTPS as it is developing right now is the antithesis of HTTP1. Everything that HTTP1 relies on is defines as bad by HTTPS. Either we change the direction of HTTPS or we drop HTTP. We can't have both.
Of course, if the server is up and connected to the internet, it will always be accessible by browsers that can be configured to ignore the missing HTTPS features, as it is now. But as I said on a different comment we should not rely on this being here for much longer.
On the web side of this analogy, we're so fortunate to have people like Neocities trying to rebuild those bridges to the beginners, the resource-deprived, and the other edges of society, but with every crank of this ratchet we (literally!) excommunicate another set of our species, and that's depressing as hell.
Hopefully, we'll eventually figure out how to make a TLS stack without endless buffer overflows and padding oracles, so it won't be necessary to upgrade servers all the time.
Yes, some sites serve basic content that can stay up forever without change (thistothat.com comes to mind as a good example) but it really doesn't hurt to force people to put a little bit more care into their sites.
Yet on the other side, we let so much information expire because the underlying technology is obsolete.
- Book contents frequently get updated. Revisions, translations, editions, adaptations.
- Book formats see change. There are at least some works which have seem multiple forms (oral traditions, clay tablets, vellum codices, stageplays, printed books, operatic adaptations, three-ring binders/loose-leaf circulars, magazine serials, paperbacks, radio serials, cinema series, comic-book adaptations, Broadway musicals, TV series, PS documents, PDF files, podcasts, videogame adaptations, YouTube channels, ebooks, ...)
Generally, websites are less a document format than a publishing mechanism. Print-on-demand-on-steroids.
Books & physically documents can decay naturally or be damaged physically, digital media can be damaged physically too. A hard drive or SSD can fail at any time, a disc can be scratched, a tape can get tangled. Easier and more accessible redundancy is an advantage of digital media.
What about system and software updates to fix critical vulnerabilities? Hardware failures? I feel these things would take much more maintenance time than the occasional certificate renewal.
All this switch to HTTPS just so Google can guarantee its ads are being seen. You get some other benefits as a side effect... but that is the real reason HTTPS is everywhere.
Ah well.
Now remote attackers have a simply vast attack surface. They can actually run code on your computer. History has shown such code can never be perfectly sandboxed. So you need to be very sure you are where you think you are and that you are only getting content from that place. TLS is an essential band aid fix.
The same sort of thing comes up anywhere HTML is used. People sometimes claim that email is inherently insecure. In most cases it turns out that html email is inherently insecure.
It seems that any popular protocol eventually gets extended to the point where it is impossible to keep it secure. It also seems that the popularity of the protocol causes a period of denial.
RCE in mosaic or Netscape was probably trivial, it just wasn’t as well studied as today. Just look at how many times those browsers would crash in the normal course of web browsing, even back then. Nobody was intensely fuzzing their html parsing engines, image processing libraries, scripting elements, plugins etc.
Heck, IE used to load and run arbitrary code as “activex” controls. No fancy exploit needed!
> the most an attacker can do is to change the content.
Sure , but I would argue, depending on on the content, that malicious content can be just as bad as malicious code. Just ask anyone who has been phished.
Just another hurdle to our effort to make things last on the Internet [1]
[1] https://jeffhuang.com/designed_to_last/
I'm not sure this assumption is right, looking at the CVE list and in particular entries associated with Apache.
http://cve.mitre.org/cve/
https://www.cvedetails.com/product/66/Apache-Http-Server.htm...
I'd like that to be the world we live in - and with the continual evolution in secure programming practices, maybe one day it might be, but it's not.
As a profession of software engineers, we have not achieved the level of quality at the costs that is willing to be met to engineer public facing websites that won't be vulnerable to attack at some point in the next 20 years, and will still be running.
I absolutely understand the drive to use more secure TLS, but it's a really sad experience to see that you can load Google, but have nearly every link unable to load.
It wasn't that long ago that I could try out some ancient browser on some modern website, and at least see it fail to render well. Now you can't even connect.
This leads to interesting situations with, say, PowerPC Mac software sites. Either they have http connections, or they use user-agent sniffing to downgrade TLS.
That doesn't work. The user-agent is passed after the encryption channel is established.
What they do is offer all the options, and the client picks the best one they can support.
However, why would this need to be HTTPS to begin with? If you're not transmitting anything private, HTTP works just fine.