Luckily, Dashboard widgets are just editable html and javascript files, so I rewrote a portion of Apple's weather widget to use the DarkSky API instead. Since the entire point of this project was to support a legacy feature (the Dashboard), I really wanted it to work on the full gamut of OS X 10.4 Tiger – 10.14 Mojave.

My modified version worked fine on 10.9 and above, but on 10.4 – 10.8, users reported being unable to retrieve any weather data. After some back and forth of looking at logs, I found the problem—old versions of OS X didn't support the modern iteration of HTTPS required by DarkSky. I couldn't fix this, because DarkSky doesn't offer their API via HTTP.

Was this really necessary? Weather forecasts are public information, so what level of safety is provided by HTTPS to the point where it should be not just a default, but the only option for developers?

(Luckily, I had the chance to rectify this when Apple bought DarkSky and forced me to change APIs. I'm now using Weatherbit, which offers HTTP. I would have preferred to use HERE, but like DarkSky, they're HTTPS-only.)

https://forums.macrumors.com/threads/i-fixed-apples-broken-w...

Even if it's public information, you should protect against an attacker modifying the payload to exploit a weakness in your browser/application, and to protect against any any other kind of unauthorised modification of the payload. (I see Cthulhu_ already mentioned this.) We've discussed the non-obvious advantages of HTTPS before. [0][1] There's a reason Netflix encrypt video streams. I agree it's probably not worth breaking existing applications to encrypt the weather data, but it's worth doing going forward.

[0] https://news.ycombinator.com/item?id=22933774 (Forgive me linking to my own comments)

[1] https://news.ycombinator.com/item?id=21912817

This is pretty deep down the threat modeling hole though, and no, normal people don't need to care about this.

HTTPS is useful, and it should normally be the default for web traffic potentially crossing any untrusted network, but let's keep it in perspective. It's an application layer protocol. It can't protect you against attacks at lower layers.

Remember Upside-Down-Ternet? [1]

[1] http://www.ex-parrot.com/pete/upside-down-ternet.html

But who is going to set up a hostile router in an office of five people? Or in someone's home?

The admin of having to rotate keys and help customers with their TLS and SSL related problems (which is many in Enterprise, Java 5 and 6 is fucking rampant still) just isn't worth it.

Yes, someone could MitM the connection. Do we care? No. The data has very little consequences if it's corrupted.

HTTPS by default is good, because you don't know what could go wrong. What if there's a security vulnerability in the dashboard widget that someone who can intercept and manipulate the response can abuse?

0: https://darksky.net/dev/docs

"Always lock your front door" is good advice, just like "always use https" is good advice. But I'm not going to lock and deadbolt my door if I'm only walking out to grab something from my car and returning immediately.

They could include a script tag and then run JS in the context of the widget which may have undesirable effects.

If the traffic is traveling over a connection you aren't 100% sure you control entirely, wrap it in HTTPS.

The only workaround is to use a VPN since so many servers still have not moved from HTTP to HTTPS.

Tech support states unless I accept the agreement this will not stop and may connection will be disconnected which is complete BS since HTTPS prevents this from working properly!

So yes, even ISPs are bad actors when it comes to HTTP.

Yours was a facetious point to make. Potential worst case scenario in this example may be that someone thinks its the wrong temperature, but normalising and arguing against the use of secure protocols is stupid and dangerous.

The point I'm making is that security always comes at a cost, and sometimes it just isn't worth it. In the OP's example, using https literally breaks the application. Whereas switching to http has very little downsides. So while https should be seen as the default, it makes sense to use http sometimes.

Do you use full disk encryption on every machine you use, with a separate TFA key for every device? Do you have bullet proof windows and a reinforced steel door? Have you purchased and set up a commercial firewall for your home network?

You can always increase security. Where you draw the line depends on you and your application. Throwing out all nuance because "you must always use $SecureThing at all costs" is just not helpful.

What you actually said went quite a bit further than that. You outlined a scenario that involved arbitrary code execution.

> Yours was a facetious point to make.

"Facile", maybe? Even with that correction, the point was not facile—after all, it forced to you walk back from the original picture you painted of an RCE to a place where someone may get told there's going to be a mid-summer blizzard.

https://rationalwiki.org/wiki/Motte_and_bailey

https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

Unsecure http is essential to the free flow of information.

Let's get the right solution before we force everyone to use it.

Am I being paranoid for not trusting Google, Facebook or the federal government?

On the one hand, we have matter of privacy - people presumably request the forecast for their present location, or their travel destination. This may be sensitive information, depending on personal circumstances.

On the other hand, we have usability - in the name of security, people got stopped from using a convenient feature. This seems pretty close to the trouble of planned obsolescence, and seems to be a somewhat common trend, of security running counter to usability and hackability (in the DIY sense).

I don't follow. The TLS handshake negotiates the appropriate ciphersuite. With the exception of dropping SHA1 in TLSv1.3, how was the macOS SSL module not able to negotiate a handshake? There should be plenty of suites available. What did Darksky ask for in the TLS handshake???

For example: I'm still running Mojave, and here's what I see from the handshake with the Darksky.net site on :443 ...

:

:

issuer=C = US, O = Amazon, OU = Server CA 1B, CN = Amazon

---

No client certificate CA names sent

Peer signing digest: SHA512

Peer signature type: RSA

Server Temp Key: ECDH, P-256, 256 bits

---

SSL handshake has read 5538 bytes and written 439 bytes

Verification: OK

---

New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 :

:

:

They aren't even using TLS1.3 on the main page.

https://www.ssllabs.com/ssltest/analyze.html?d=darksky.net&s... (scroll down to "not simulated clients" and click "expand).

I don't actually understand that much about the internals of https, but my assumption is that there weren't any cipher suites supported by both DarkSky and Mountain Lion.

That site requires exactly TLS 1.2 (not newer or older)

So an HTTPS implementation like Mountain Lion that only speaks TLS 1.1 or earlier will begin by saying it can do TLS 1.1 and the server says too bad, go away.

TLS 1.2 was defined in about 2008 but despite that a lot of products shipped without TLS 1.2 implemented for the next several years, because backwards compatibility meant they still worked, and it didn't seem like a priority, while forward compatibility had frequently proved problematic. Why ship something "more secure" that breaks for 1% of your users?

For example Firefox only added TLS 1.2 by default in 2014, after Mountain Lion was shipped (but before it ceased to be supported).

Tiny addendum, what I saw was different by one version: DarkSky worked fine in Mavericks, just not Mountain Lion.

    <?
    header('Access-Control-Allow-Origin: *');
    $url = $_GET['url'];
    echo file_get_contents($url);

    http://theWebServer.com/thePhpFile.php?url=https://darkSkyURL

I very briefly considered setting up a public instance, but I'm not a professional web developer and didn't know what the implications would be, either for the overall security of my server, or in bandwidth costs, particularly if malicious users started using the "proxy" for other things. All of the client-side code is out in the open, so it also wasn't clear how I'd make an authentication scheme. I'm sure there's a way, but again, not a web developer!

If your Worker code hardcodes the Dark Sky domain, the worst an attacker could do is either use up your free worker quota from Cloudflare, or hammer Dark Sky at the Worker ratelimit (1,000/minute, which Dark Sky should easily handle).

AWS, Azure, GCP all also have free tiers for their serverless services. RunKit (http://runkit.com) might also work.

These are all likely to be HTTPS-only, but hopefully at least one of them supports TLS v1.1, rather than being 1.2-only like apparently is the problem with Dark Sky.

A. DNS record (foo.example.com CNAME api.darksky.net)

B. TLS forward proxy (e.g. Cloudflare Full SSL https://www.cloudflare.com/ssl/)

C. Host header rewrite (e.g. Cloudflare Page Rules https://support.cloudflare.com/hc/en-us/articles/206652947-U...)

Huh, that's odd—it's absolutely programmed to look at city and state individually. I had to interface with that code in my version.

When I type Minneapolis into my version, it correctly displays both cities (alongside Minneapolis, NC) the drop-down, and lets me choose between them. I would have expected the original to do the same thing, but I obviously can't check now.

HTTP isn't supposed to rely on external services that can die, cut you off, block you, etc.

This is not a matter of how easy it is to align with the current browser dictated situation.

EDIT: LoTR typo (elf vs self) fixed.

HTTP alone doesn't serve its initial purpose at the large scale. That's like having a process for building homes out of dirt and hay, a totally viable way of doing your own house today, but it definitely won't be enough to house the 10 billion people of tomorrow.

The real alternative to provide what HTTP once wanted to provide, if not HTTPS (because of its reliance on points of contention), is in the decentralized web: dat, zeronet, ipfs ?

    mkdir ~/public_html/
    echo 'My Samoyed is <b>really</b> hairy.' > ~/public_html/index.html

If the people steering the dominant browser projects think that allowing everyone to author and distribute creative work is important, they'll keep supporting HTTP, and they might also direct effort to supporting dat, zeronet, ipfs, onion sites, and so on. If they don't think that's important, they probably won't do any of those things, even though, yes, the tradeoffs are a little different.

Since most of them are at Apple and Google, I think the iOS App Store and the Google Play Store probably represent the future of the web. I think that sucks but I don't know how to stop it.

As for adobe, it's pretty labor-intensive and slow as a way of doing your own house, and it doesn't work that well in very damp climates like Seattle. But there's no difficulty at all in scaling it up to 10 billion people, and indeed with compressed-earth brick presses, it might work better with modern industrial machinery than with the traditional North African craft processes that we now use all over the New World. There's plenty of suitable dirt and hay out there.

The answer is in the question: they're building _browsers_, to consume content but certainly not to create it or spread it. The last mainstream browser that did that (Opera) vanished a few years ago.

In fact, thinking about the problem a little bit more I realized that the heart of the article is kind of true but isn't articulated to show it clearly: Internet, while it was still young, was pretty symmetric because every node could be a producer and/or a consumer, and it seems everyone was. Today things are really different, because while there still are producers, the important gap is that they're not distributors anymore, and they're far fewer than consumers anyway.

The article states that the switch to HTTPS has somehow "changed" things, because you can't start a super basic HTTP process and expect it to run for a long time. This conversation has shown that while it's technically true it's very easy today to run an HTTPS reverse proxy to mitigate the situation, so from the point of view of TLS the point is mostly theoretical. However there's something that is very important today, it's that people who want to produce mostly can't also be distributors: NATs and firewalls and the complexity of configuration has in practice prevented everyone but the most tech-savvy of us from self-hosting. I think this point is more detrimental to the initial promise of the WWW than the technicalities of the encryption that has allowed us to make this protocol more viable at the scale we're at right now.

The answer is, as I've said before, the decentralized web: I personally believe that dat is the right model, but I might be wrong and the details don't matter that much because the important point is that they all allow us to get past connectivity issues and be both a producer _and_ a distributor. Hopefully that's where we're going to be headed in the coming years.

Regarding adobe, there's no question it _can_ be used if we just want to; what I had in mind (and I did not express it, my bad) is that this kind of material usually comes with the associated manual process that's so prevalent in the communities working with it. Scaling it to 10 billion people, all using this method, will definitely change the way our societies are built: tall buildings aren't possible anymore, at least not the way we're used to. Structures take decades, not years or months to be built. I doubt this can scale to 10 billion people.

I didn't have root then, I didn't have root a couple of years later when I was doing sysadmin intern tasks on the math department's machines, and I didn't even have root on my desktop SPARC 5 in 1996 when I was working at a company, although I did on my roommate's Linux box at home and, later that year, my own. But IIRC our internet access was through Slirp on a shell account: we didn't have our own public IP address. (My workplace SPARC did.)

That was about the time the unwashed AOL colonist hordes started thinking they owned the internet and remaking it in the image of the world they knew, giving primacy to commerce rather than knowledge and sharing; but, of course, they didn't have public IP addresses either, or I think even private ones.

I'd say that the internet was still young then because it was only 23 in 1992 and only 25 in 1996, and now it's 51. But I think it's actually easier for people to put things online now, despite the NAT growth and HTTPS churn and whatnot, because an awful lot of people at the time had some kind of internet access but no distribution capabilities and no usable software. I don't know how long it would take an average internet user to learn to spin up a DigitalOcean droplet and start running nginx on it with LetsEncrypt, but I imagine it's on the order of a day or two, and the startup cost is like US$5 or something.

But however much easier it may be to initially put something online today, it's enormously harder to keep it online, and I think that's a terrible price to pay. And we're increasingly vulnerable to arbitrary censorship decisions made by Google, Apple, etc., even if currently that is more a potential risk than an active catastrophe — much like the next pandemic was a year go.

Today the menace is not so much commerce — though it continues to be a pervasive corrupting influence on our discourse and a frequent excuse for political censorship, it is also the underpinning of the internet since the beginning — as it is partisanship. Want to distribute health "misinformation", such as advocacy of wearing face masks (a month and a half ago, anyway, when this contradicted official guidance from the CDC)? Better hope Google and Fecebutt don't find out.

The whole problem of a self-signed cert is unless you have a priori knowledge of the cert somehow, it then is trivial to MITM a self-signed cert. That is why it was never trusted. That is the point of a signed cert, you are inherently trusting a third party to tell you the cert a website is giving you is good.

It does bring up an idea of making an individual a CA (i.e. you know someone's PGP key and that PGP key signs a cert, and that is a way to trust it). But you still fallback on the same issues with PGP email, you ultimately need someway of trusting it in the first place.

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

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.

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

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.

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.

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.

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.

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.

Passive collection, where you search through the accumulated data after the fact.

In what real-world situation is that an upgrade?

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.

I do not enough to solve that problem really.

You generate a CA cert using a utility like xca and then create client certs signed by it. You can use signing requests if you don't want to know the password that protects the certs (in my scenario, I was fine with that).

You then export your client certs, with your CA cert included, and coordinate with people who need access to install the cert on their browser or OS.

Your users will get prompted to trust a new CA (as they should).

Combine with a webserver that supports routing requests based on certificate status, like nginx, and it's pretty neat. You can allow access to only those who have a cert signed by your CA.

I did this for the longest time before letsencrypt was a thing, and if letsencrypt goes away, I'll go back to it.

What I don't get, with DNSSEC getting rolled out more and more, why can't every site operator simply stick the fingerprint of their HTTPS cert in DNS and have DNSSEC take care of the trust chain?

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.

So I guess I'm confused how

  DNS records hold a public key rather than _acme-challenge

If someone gets control of your domain, then yes, there really isn't much difference between a system where a public key in your domain's DNS records is used by clients to tell they are talking to your sites and a system where a certificate issued by LE is used for that.

As you note, once they have control of your domain they can get new certificates from LE for it.

But attacks against the domain owner aren't the only kind of attacks. There are also attacks against the domain's visitors.

Suppose Bob has an old router at home with out of date, buggy firmware that I know a remote exploit for that allows me to change his DNS settings. I change it so that instead of using the DNS servers it get from Bob's ISP via DHCP to resolve DNS requests from the LAN, it uses my DNS server.

My DNS server points your domain to one of my sites instead of yours, where I run my nefarious fake version of your site.

Under the public key on DNS server approach, it's my DNS server, so I can put a public key on it that corresponds to my keys on my fake version of your site, and everything will check out from Bob's point of view.

Under the LE approach, this does not work. To get LE to issue to me a certificate for your site, I have to get LE to use a DNS server I control to resolve your domain.

That's the difference. Under the current system to securely hijack your site I need to compromise your system, your DNS provider, your domain registrar, your ISP, or your hosting provider. Under the keys in DNS approach, I just need to compromise end users.

It definitely makes sense, and I completely understand how this sort of workaround can be necessary to get stuff done. But it's also too bad and I hope there can be a push towards securing DNS sooner rather then later, as it really should be the minimal source of trust in most cases. Having DNS be reliable for that with widespread support would open up a ton of additional new possibilities too, and not just for public websites.

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.

The HN community loves static sites and the old web. But this is a tiny tiny tiny minority.

"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).

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

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.

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.

>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.

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.

EDIT: why on earth was this question downvoted? It was genuine, I honestly don't know how to do it.

Let's also not forget that having a HTTP website relies on other services that are maintained by others as well; this isn't going from "full independence" to dependence, it's going from N dependencies to N+1.

Certbot is not a silver bullet and is easy until it's not.

There are a lot of websites out there that just want to serve some static data or host a blog, and https IMHO adds nothing but a layer of complexity for no benefit.

Until someone who is trusted, technically capable, and has a better and sustainable solution that optimises collective good, I'm not sure that the current situation we are in is really that bad.

The DID and VC standards have an interesting approach. Use self-signed public keys, and third-party-signed credentials. To prevent MITM use credentials, to encrypt channel use the keys.

The agreement part, however, remains difficult because the protocols are always evolving.

Maybe in a few years we'll get it solved, just like Bitcoin solved double-spending without centralization?

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.

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 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.

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 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...

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.

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.

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.

Obviously forget about any security.

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.

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)

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.

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".

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).