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.
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.
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.
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.
IMO: https is actually overhyped, it solves some problems but has plenty of its own
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.
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.
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.
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.
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.
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.
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.
Is there a better way? I r not cryptographer.
The thttpd web server can run modern TLS with this approach, and the footprint is much lighter than with Apache.
The time it takes to do an action is not enough to evaluate the task
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.
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.
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.
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.
:) 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.
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.
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.
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.