Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Usually supporting HTTPS is combined with requiring relatively recent versions of TLS and cipher suites, for security reasons. I've been in a position where I needed to use a computer from ~2007 or so briefly and found that I couldn't access a huge fraction of websites, despite the fact that the browser "supported" HTTPS.


2007 on the modern internet... how fast was it compromised when you clicked the wrong link.


I regularly use old and older devices in my work, and they work fine as long as I don't go to random shady corners of the Web.


Firefox 27 runs on systems as old as Windows XP SP2, and it supports TLS 1.2 and the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites, which are still considered up-to-date and don't have any known vulnerabilities. If a computer from 2007 couldn't reach modern TLS sites, then it was just behind on updates that were available to it.


Right - I did end up doing basically this. In this case, though, it was a massive pain to figure out what version of a web browser (a) supported enough cipher suites, and (b) would run on the system in question. And then I had to figure out a way to get the browser on the system to begin with; all the download sites I tried required cipher suites that were too recent!


I've commented on this issue before, as I do a lot of testing in the accessibility space, so I'm just going to paste a previous comment:

---

Only a few of the barriers presented by HTTPS:

Clock sync would be a requirement for access.

A recent device would be a requirement for access (not everyone can afford a new one).

Site admin keeping up with certificate registration would be a requirement.

Approval from the centralized certificate authority would be a requirement.

Server's self domain name matching accessed domain name would be a requirement.

These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.

Just a few of the reasons why all my websites still allow HTTP.

HTTP is also way faster on slow connections.

---

https://news.ycombinator.com/item?id=35800566


> Clock sync would be a requirement for access.

If you have Internet access, NTP trivially gives you this.

> A recent device would be a requirement for access (not everyone can afford a new one).

That's literally the point I addressed in the comment you replied to. Computers that are over 20 years old are still capable of connecting to websites using modern TLS.

> Site admin keeping up with certificate registration would be a requirement.

No, ever since ACME came out, certificate renewal can trivially be fully automated, with zero admin work required when one is about to expire.

> Approval from the centralized certificate authority would be a requirement.

Which is trivially granted as long as you actually own the domain you're trying to get the certificate for.

> Server's self domain name matching accessed domain name would be a requirement.

You can get multiple certificates and have the server use SNI to send every client the right one, or get one certificate with a bunch of domain names.

> These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.

This is like saying that it's dangerous to go outside because there have been real cases of people being killed by meteorites.


> If you have Internet access, NTP trivially gives you this.

This is not always true, and the user is not always at liberty to change the clock settings on their device.

> That's literally the point I addressed in the comment you replied to. Computers that are over 20 years old are still capable of connecting to websites using modern TLS.

This is just not true. I do a lot of testing, and there are many devices as young as 5 years that cannot access some websites due to TLS incompatibilities. I have a very nice device that's 10 years old which I use daily that experiences this on a regular basis.

> No, ever since ACME came out, certificate renewal can trivially be fully automated, with zero admin work required when one is about to expire.

Automation breaks, and certificates expire. I encounter websites with broken certificates almost daily.

> Which is trivially granted as long as you actually own the domain you're trying to get the certificate for.

It is not trivial at all. It requires a lot of administrative work, and many people around the world do not have access to this process at all.

> This is like saying that it's dangerous to go outside because there have been real cases of people being killed by meteorites.

No, it is like saying there are people out there who want to access information on the device they have access to, and we should enable them to access that information as much as possible.


> there are many devices as young as 5 years that cannot access some websites due to TLS incompatibilities. I have a very nice device that's 10 years old which I use daily that experiences this on a regular basis.

Can you name the specific models?

> Automation breaks, and certificates expire. I encounter websites with broken certificates almost daily.

How many times have you seen that where the expired certificate came from Let's Encrypt? I'm guessing never, and that when you've seen it, it's always been from legacy ones without any automation in use.

> It is not trivial at all. It requires a lot of administrative work, and many people around the world do not have access to this process at all.

It only takes a few minutes to set up. Who has the required resources to own a domain but not to use Let's Encrypt?


Any sane reasons to use a 10 years old tls library ?

I fail to find any;


The most basic one is that you have a device which you cannot upgrade past that version.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: