Chris's Wiki :: blog/web/HTTPSNoOldServers Commentshttps://utcc.utoronto.ca/~cks/space/blog/web/HTTPSNoOldServers?atomcommentsDWiki2020-05-13T23:08:30ZRecent comments in Chris's Wiki :: blog/web/HTTPSNoOldServers.By mobiushorizons on /blog/web/HTTPSNoOldServerstag:CSpace:blog/web/HTTPSNoOldServers:0e774306e19f808a6c27fa4e72f105b09de835a9mobiushorizons<div class="wikitext"><p>Well I agree this is unfortunate, I think the public internet is too malicious a place to leave servers without updating (regardless of if you have TLS support). Old hardware and non-standard operating systems will help somewhat to avoid the script kiddies and automated tools, but I think there is a real case to be made that it is irresponsible to leave servers unpatched on the internet not just for you own sake, but also for the sake of others on the internet. Your users could be getting malware if you are hacked, or your servers could be used in a DDOS attack (for instance).</p>
</div>2020-05-13T23:08:30ZBy Hales on /blog/web/HTTPSNoOldServerstag:CSpace:blog/web/HTTPSNoOldServers:60930a61f40be63add1497575cc91265a47d80fbHaleshttps://halestrom.net<div class="wikitext"><p>We should never abandon HTTP 1.0/1.1 in browsers. With HTTPS we can go "forward", but we can never go "back". When something goes wrong we need simpler tools like plain HTTP to fix or workaround it. Things always go wrong, you should not build yourself into a corner.</p>
<p>For an interesting (but socially important) side-thought: death of website owners. Simple websites, using things like static pages and simpler protocols like HTTP, are less of a maintenance burden. It <code>might</code> be possible to convince their hosts to keep a site going if it's a simple one (either pro-bono or you just throwing them a few dollars occasionally), but regardless if you ever hope that someone (anyone) will keep an old site online it's best to make their job as easy and simple as possible :)</p>
<p>Sadly there are some cases where the HTTP server itself has security or reliability flaws. Changing HTTP server can be anything from a nightmare to a no-op, depending on how the website is implemented. Hint to website devs: try to make your sites as HTTP server independent as possible, it helps everyone (including you) fix things down the track. Use common scripting interfaces, not ones where there is only a single implementation, and test across a few hosts. Some HTTP proxies might work-around some issues, but not always.</p>
</div>2020-05-13T22:50:39ZBy Dan on /blog/web/HTTPSNoOldServerstag:CSpace:blog/web/HTTPSNoOldServers:7663d83be13081d71587ba003acf5854c0b89410Dan<div class="wikitext"><p>@45.72.246.255:
Well, that'll work for a few years, but my impression is that browsers don't intend "not secure" warnings for HTTP as the final step. Eventually there'll be an interstitial warning page with stronger language. At some point the "continue anyway" button on that page will go away, and you'll have to change a configuration setting. Likely in about:config or the like, they won't expose it in general preferences. At some further point they'll refuse to talk to any server that won't do TLS, no matter what.</p>
<p>Though given that extensive HTTPS adoption is one of the few bright spots in the security and privacy realm, I can't say I feel that bad about this. There's plenty of other "a valuable intangible quality has been lost" areas that I feel worse about. And also a lot of areas of software where there's far more churn and maintenance headaches than web-server configuration. (One of which may be what you put in the pages the web server is serving, if they're anything other than static files. But that's a separate issue.)</p>
</div>2020-05-13T22:06:19ZBy Andrew Reid on /blog/web/HTTPSNoOldServerstag:CSpace:blog/web/HTTPSNoOldServers:d07aabdac54b6763126058c061a356d1849fc94cAndrew Reid<div class="wikitext"><p>Ran into this just today. In my case this was due to a ancient Dell PE2900 server and the associated web server to manage the PERC Raid card. It used a self signed certificate and TLS 1.0; nobody wanted to talk to it.</p>
<p>I had to dig out an old laptop with an equally ancient browser so I could replace a disk. And this isn't even the DRAC interface which uses a long forgotten version of Java ( !!!) which barely worked on the best of days ten years ago.</p>
</div>2020-05-13T18:23:26ZBy David Waite on /blog/web/HTTPSNoOldServerstag:CSpace:blog/web/HTTPSNoOldServers:67525a9358cc042c99675500ff1aa3770f3e66e9David Waite<div class="wikitext"><p>If you set up a HTTP server in 2000 then forgot about it, that server has likely been thoroughly defaced through known remotely exploitable compromises, and likely was taken offline by whatever hosting provider used due to the volume of malicious traffic coming from it.</p>
<p>If the content and hosting of that website somehow survived, you might have also now have received over a decade of complaints due to people not being able to see the Adobe Flash or Java applets you added to spruce up your content. You might also find that most modern browsers don't render the site correctly because you originally styled things based on Internet Explorer 4-5.</p>
<p>I don't believe it has ever been possible to stand still within a network and not accumulate layers of rust and dust.</p>
</div>2020-05-13T16:32:48ZBy wvh on /blog/web/HTTPSNoOldServerstag:CSpace:blog/web/HTTPSNoOldServers:3ba355f26942ef65f51a2a8adbfa286809af07dewvh<div class="wikitext"><p>Isn't that what happened to email a long time ago? Some big players, and a lot of work and uncertainty for small fish.</p>
<p>I remember setting all that stuff up in the nineties, and even though my responsibilities have moved nowadays for other reasons, I'm happy I don't have to babysit email servers in this day and age.</p>
<p>Yet, it would be nice to be able to keep the playing field open to all.</p>
</div>2020-05-13T13:49:42ZFrom 45.72.246.255 on /blog/web/HTTPSNoOldServerstag:CSpace:blog/web/HTTPSNoOldServers:88ffd12fd5753f653f6b895985650620e8c97a32From 45.72.246.255<div class="wikitext"><p>I wonder if some people will simply say "<em>forget this</em>", run plain-HTTP, and just deal with the 'this site is insecure' icon that most web browsers have nowadays.</p>
</div>2020-05-13T10:43:22ZBy Blue_Monk on /blog/web/HTTPSNoOldServerstag:CSpace:blog/web/HTTPSNoOldServers:193196fc85860b818a905a21377fca8a16a379d5Blue_Monk<div class="wikitext"><p>How about using a pfsense firewall with HAproxy and certbot enabled ?
Not much to do after it's set up. Maybe update it every now and then but that is it. You can serve old school website all day long and still comply with the new rules.
I'm what you would call a noob but it still takes me only 30 min to get it set up and ready to go for a 1 domain basic setup(Maybe 1h if I set up a few subdomains too)</p>
</div>2020-05-13T10:02:33Z