A third of you slackers out there still aren't using HTTPS by default Almost a third of the world wide web's top million sites are still not using HTTPS by default, according to infosec researcher Scott Helme's analysis. In his Top 1 Million Analysis, in which he runs crawlers over a guessable number of websites, Helme published his findings on a variety of common internet security technologies …
I found out about this the hard way when my browser refused to connect to a site quoting some obscure key exchange error. It never occured to me that anyone would be so stupid as to require certificates on all sites because a relative handful of ecommerce sites need it. Althugh there's a huge industry built on the back of it the Web is just not a secure place, we wish it were so and so we all pretend it is like a mass halluncination (and are forever surprised when sites and transactions are compromised).
But then the web itself is just a huge pile of ever more complex kludges built on a simple idea -- it seems that there's little to no thought about how the system could be made properly secure.
The point is that "encryption" also includes proof that what you have received is what the site sent you, so man-in-the-middle attacks are harder. Of course, if (like most people?) you are blindly accepting anything that is signed then you'll accept the man-in-the-middle's signed malware so this point isn't actually useful.
Firefox has that setting to check the cert signature hierarchy up to the top level.
It's chromium based browsers that rely of Google cache instead. Which is fine for big sites like banks, but since the cache list is not published publicly, and since Chromium based browsers don't check the cert signature hierarchy for sites not in the cache, visiting less-visited sites is inherently risky.
Chromium could easily offer the option to check the cert signature hierarchy for sites not in the cache, but they do not.
Verifying message integrity and sender authentification are useful when you are downloading critical information such as compiled software, an install iso, etc.
It is completely pointless when I am reading a simple read-only blog or similar content. I don't need to be able to verify message integrity when I am reading a recipe for pizza dough, a webcomic, read someones thoughts on the social life of dolphins, or follow the newest rant why (spaces, vim, c#) are better than (tabs, emacs, java).
Not all information is critical.
self-hosted web pages (I like setting up my own frequently used link pages this way) and embedded systems (that only access 'localhost' let's say for a web-based UI) ABSOLUTELY DO NOT NEED HTTPS or SSL (in general).
For this reason as well, "legacy" (not encrypted) http access MUST remain available.
And can you imagine implementing SSL on an ARDUINO? You _CAN_ implement a config web page (I have done it) using a wifi or ethernet shield... using "legacy" http.
I am the webmaster for a square dancing website hosted by bluehost. One day I was surprised that pages could be read with both http and https. The links on the website are all relative so if you connect with https all of the pages will be served using https. You get your choice.
Although I'm not sure of the advantage of encrypting square dance schedules, club news etc.
If a site is not exchanging any private and/or sensitive information, what's the point?
A https stream prevents Google competitors offering analysis?
I mean, there must be a reason why a data thief like Google supports SSL - you can be certain that it's not because they have your interests at heart.
We could argue that not having a redirect in place is a good thing from a protocol perspective. With one of my different hats on I would argue that it shouldn't be explicit.
All that being said, convenience trumps strictness so I'm not surprised that the majority of sites are doing a 301/302 to the https equivalent even though as far as I understand it a 301 with a protocol change is discouraged (I'd find a reference, but it's been a long time)
As a case in point,if you're running a public artefact repo (sonatype/jfrog etc) and you stick a 301 in to protocol switch http -> https, there's no guarantee that all the build tools in question will play nicely if they're configured for http...
… as python-using folks found out a while ago.
Fortunately, that could be fixed quite easily: browsers already send "upgrade-insecure-requests:1" in the request headers if they want that, so you can redirect conditional on that and that wget from CentOS 5 that doesn't speak TLS 1.2 and doesn't know today's CAs¹ will be none the wiser.
Combine with a moderately-sized HSTS and, given that Key Pinning is deprecated, you have a reasonably-good-of-both-worlds.
¹ if that sounds suspiciously specific, it's because it is. Busybox offered a working wget, once I hid the old openssl from it so it would use its own implementation.
So you are saying that your information has no value? You are being way too harsh on yourself mate.
The point of moving to HTTPS was to stop ISP from profiting from your browsing - profits that would be moved from the people that track you. Securing you is of secondary concern.
...with no login features or transactions taking place?
They display text. There is no login, there is no transactions. There are no cookies. The page visitors give up no secrets they aren't giving to their ISPs anyway.
Forcing "HTTPS Everywhere" on such pages is similar to locking every door in a house, not only the front door. It doesn't increase security,
So that the man-in-the-middle can't inject malware, or adverts, or divert the existing adverts to their own (so they get the revenue)
And why do you think that it's good to give the consumer ISPs more secrets? BT don't need to know that I have a fetish for midget porn and I wouldn't want them to start advertising such things to the family members who use the same connection.
I maintain / update information a website for a not for profit local group, its purely read only, just has various info useful to that group*
Its not hosted by me (using one of the lots of hosting companies out there).
No need for https for that scenario, so its staying http (if it was free and hassle free to enable https with current hosts then I would, but their certs are non free & not fiddling around to see if its possible to get it to work with a free cert as that's not my idea of a fun way to spend some spare time, lots of things I want to do take precedence over that, even typing these inane reg comments )
* deliberately not using fb or similar to push out the info as lots of group members don't use social media whereas website open to anyone to read.
If your host doesn't give you an easy to install free option, they are pretty crap IMHO.
HTTPS means that when someone is on some dodgy WiFi somewhere, there's no-one injecting code into your site to compromise or track your users. Same with ISPs, there's a history of ISPs injecting adverts/code into websites, against end user best interests.
If dodgy WiFi somewhere/your ISP injects adverts/code into "websites", they are pretty crap IMHO. BTW, it is not the websites having adverts/code injected, it is web browsing sessions.
Realistically, the injection can occur even with HTTPS when adverts/code are being delivered from third party sites which is nearly always these days. <sarcasm>But those third party sites are mostly using HTTPS so they are secure.</sarcasm>
Additional observation, if advert/code injection is occurring; the problem is deeper than HTTP/HTTPS. The entire communication channel should be encrypted. Maybe use a properly implemented/not crap VPN.
People decrying HTTPS on this comment section have short memories.
Phorm 'partnered' with BT (*Major* UK ISP) to inject ads to non-encrypted websites.
HTTPS kills it (and similar systems) dead. Bonus points if you don't use your ISPs DNS servers.
That said, if you're just going to switch to Google's DNS and continue using Googles' browser and mapping services...
I am with you - I can't believe that folks forget multiple home router companies and/or ISPs and/or cell companies have deployed on a large scale:
1. Injecting ads into normal HTTP web sessions, either over the top of other ads or just straight up "click-thru" pages
2. overriding DNS "not found" requests to redirect you to their ad spam sites (not quite HTTPS' territory but modern HTTPS will kill some kinds of this evil with CERT pinning). This broke multiple things as you got a valid webpage back, instead of a DNS not-found for every request!
I'm sorry, but allowing your transport layer to know what is happening, beyond traffic class for QoS is just a bad move - think of it as "forced separation of concerns"? - I now like this phrase...
The last few paragraphs of this article are confused and confusing, and really should be rewritten. RSA is in ubiquitous use today by both TLS 1.2 and TLS 1.3 for server authentication, what with almost all certificates out there still based on RSA.
What's been removed from TLS 1.3 and is deprecated in TLS 1.2 (see RFC 7525) is the RSA *handshake*, as opposed to "first use Diffie-Hellman to establish an encrypted connection, then authenticate with RSA".
I agree with Scott that people should be moving to ECDSA certificates, but unfortunately this has been slow going.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
