4 ms·
How old is the last device you know of that supports insecure HTTP but not HTTPS?
by josephcsible 3y ago
How old is the last device you know of that supports insecure HTTP but not HTTPS?
- sam_lowry_ 3y agoMy Mikrotik routers? My Openwrt routers? Lots of networking equipment works over HTTP only, still. I am actually really pissed off that I can not use Chromium password manager to save HTTP credentials for these devices.
- Railander 3y ago> Lots of networking equipment works over HTTP only, still. MikroTik has supported https for a very very long time, though it comes disabled by default and even if it didn't it wouldn't work because it requires the user creating/importing a cert to use with it. At least the cert manager is quite intricate and they have a video (assuming the device has a valid WAN IP) on how to set it up with letsencrypt.
- josephcsible 3y agoBoth of those do support HTTPS: https://wiki.mikrotik.com/wiki/Manual:Webfig#Enabling_HTTPS https://wiki.mikrotik.com/wiki/Manual:Webfig#Enabling_HTTPS https://openwrt.org/docs/guide-user/luci/luci.secure https://openwrt.org/docs/guide-user/luci/luci.secure
- sam_lowry_ 3y agoThis is not the default, and frankly should not be.
- bscphil 3y agoUsually 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.
- pixl97 3y ago2007 on the modern internet... how fast was it compromised when you clicked the wrong link.
- forgotmypw17 3y agoI 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.
- josephcsible 3y agoFirefox 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.
- forgotmypw17 3y agoI'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 https://news.ycombinator.com/item?id=35800566
- josephcsible 3y ago> 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.
- forgotmypw17 3y agoNot that old, if you take into account that older HTTPS versions are often not supported by the server. As little as 5 years, in my experience.
- josephcsible 3y agoWhat 5-year-old device only supports older than TLS 1.2? (I assume that's what you meant by "older HTTPS versions".)
- forgotmypw17 3y agoI understand your skepticism, but I'm coming from years of actual testing on many real-world devices that people use everyday and have no agency in upgrading for various reasons. As I mentioned in other comments, there are many possible areas where HTTPS can present a barrier to a user's access to your resource. Some of these I listed in another comment, which I copy below: --- 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 https://news.ycombinator.com/item?id=35800566
- josephcsible 3y agoThat doesn't answer what I asked at all, and I already rebutted those points in the other place you posted that: https://news.ycombinator.com/item?id=36597183 https://news.ycombinator.com/item?id=36597183