just noticed at number 114 we have..... dah dah.... dailymail.co.uk
Not as if anyone is really interested!
Its at the top for the UK:
https://whynohttps.com/country/gb
And I never knew it was such an important website.
How's that migration to "HTTPS everywhere" going? With some Chrome browsers* now flagging insecure sites, there's a lot of work still to do, according to security bods Troy Hunt and Scott Helme. Sceptical looking people check something on a laptop Google Chrome: HTTPS or bust. Insecure HTTP D-Day is tomorrow, folks READ MORE …
Once again, Troy and Scott massively overstate the problem. It is nonsense to suggest that a website served over HTTP is going to immediately expose you to phishing or malware, which is what they seem to be saying.
What does it matter if speedtest.net or bbc.com are accessible over HTTP?
if you want to create an account or login, then those pages are served over HTTPS anyway.
MITM attacks are not common, and not usually carried out by script-kiddie level perpetrators, they are much more likely to be carried out by ISPs or Governments (Like the Chinese Firewall), who will happily MITM HTTPS as well.
Shuould I trust, for example "China Financial Certificate Authority", "GUANG DONG CERTIFICATE AUTORITY CO., LTD", and many others? Do you vet personally every CA that is pre-installed in your OS and browser? Do you believe it's hard for a government to get one listed? Do you check the chain of trust of every certificate a site use?
This post has been deleted by its author
The argument about government CAs isn't a good one.
You can always verify who issued a particular certificate, so if you went to Google.com and you noticed their SSL certificate was issued by a Chinese CA it would be blatantly obvious.
For most potential targets various monitoring would pick it up so manually verifying it each certificates CA isn't needed - it'll be noticed by others.
No, if I were a government agency and I'm doing MITM for specific targets, I wouldn't do a blank replacement of certs for everybody - I would specifically target only the "people of interest" - exactly to avoid easy spotting.
Again, how many do check the chain of trust of a certificate? Pinning could help, but it has its disadvantages, and Chrome removed it, while MS never used it. And if badly implemented, it's still vulnerable:
https://www.schneier.com/blog/archives/2017/12/security_vulner_10.html
They do it where I work, a complete MITM attack on almost all web sites (they did leave out some banking sites). The "official" browser is IE, and our intrepid IT department installed a bogus certificate in the Windows certificate store to keep IE quiet about it, and also Chrome, because it uses the Windows certificate store.
Fortunately, I use Firefox, which has its own store that hadn't been tampered with, so I was warned immediately. I deleted private accounts I had at work (mainly IMAP email) off my work computer and changed all the passwords.
It requires getting control of trusted CA certs. I suppose they could try and get one of their own listed as trusted, but I think someone would notice.
I'm not sure I understand your point. I would have thought the TLAs have access to the original signing cert and just create their own certificate for google.com and happily sit in the middle.
You mean that certificate pinning which is already on the way out again (deprecated in Chrome) before it's even fully arrived (no support in Edge yet), because between short-lived certs and spare private keys, you actually need some amount of planning to deploy it reliably?
This post has been deleted by its author
"Twitter's T.co URL shortener, the BBC (.com), Fox News, Speedtest.net, Fedex, 4chan, or Australia's ABC or Bureau of Meteorology (to name just a few) have no such excuse."
For most of these who the hell cares? What is so secret about the weather forecast? I can look out the window and see it. Or a speed test, a short URL that redirects to a longer URL or news? None of these things need to be encrypted.
I agree, this whole everything must be secured is absolutely stupid. If the site doesn't do login's, it doesn't need an ssl certificate. Its not like every site being secure actually adds to any protection from phishing sites...90% of them nowadays are just registering domains, setting up email, getting a lets encrypt certificate and voila from zero to phishing in 15 minutes....sheeple are stupid and will click links anyhow without looking at the address anyhow. www.micr0soft.com is the same as www.microsoft.com to most people anyhow...
How exactly is that site now NOT giving an SSL warning really providing people with better security?
HTTPS isn't just about hiding the content. It's also about proving that the content is intact, as it left the source server, and that the source server is who they claim to be.
That URL shortener, for example, if someone MITMs that they can make any shortened URL redirect to a site of their choosing. That opens the door to all manner of phishing attacks. (URL shorteners are a ludicrous blight anyway, but that's off-topic)
At a bare minimum level, a MITM could change the advertising token so that the site's authors no longer receive the credit for that advertising, but the attacker does instead...
"You just want tamper resistance. SSL slows down low power devices."
But encryption is the only way to ensure the signature isn't also altered on the fly to match. If not the page itself, then the signature must use some system where someone without an authentication certificate can't just change the page then change the signature to match.
HTTPS isn't just about hiding the content. It's also about proving that the content is intact, as it left the source server, and that the source server is who they claim to be.
Sometimes that matters. Other times it really doesn't: who cares if it was some anonymous MITM who inserted your comment? And there are much-lower-overhead ways to achieve such goals: for example, the rarely-used Content-MD5 HTTP header offers a way to verify intactness of content against accidental damage, and similar use of a cryptographic signature such as PGP could protect where it really matters.
There are also legitimate reasons to rewrite content on the fly. My own involvement with such go back to about 2002 when I was working on accessibility tools, and provided a proxy that would rewrite elements of HTML on-the-fly to make it more readable to someone with a linear or text-only browser. Remove some of hurdles faced by blind users, or by Granny Arthritic who stands no chance chasing script-driven menus with a mouse.
"Sometimes that matters. Other times it really doesn't: who cares if it was some anonymous MITM who inserted your comment?"
What if the comment was actually malware? Chinese Cannon inserted malware in unencrypted pages, what's to stop anyone else, and it need not be JavaScript, it could be something that could pass through even NoScript, for all we know.
To stay safe, pick a hard-to-guess password
The simplest way to make a hard to guess password that is memorable is to use a film quote or song lyric etc.
Using "Frankly, my dear. I don't give a damn." from Gone With the Wind, which was released in 1939, you get something like:
FmdIdgad!GWTW1939
If you aren't geeky about songs or films, pick something you have a wide field of knowledge about, it makes it easier.
No, because hackers aren't stupid. Those kinds of mnemonics can be easily figured out, and if you try to mangle them to make them harder to remember, you make them harder for YOU to remember. Even xkcd's famed method has flaws, especially as the site count rises (Now was it correcthorsebatterystaple or donkeyenginepaperclipwrong?)
This is a lot more common than most people think. The reason is pretty simple. For corporations who don't use experienced penetration testers and rely on application and web scanning tools. This is because findings from these scanning tools typically state HSTS and other "header" misconfiguration findings are considered "LOW". Because of this, the risk is typically accepted or placed deep in the queue to be fixed.
For those who hire good penetration testers or have them on staff, they will consider most header findings as a medium; even for internal sites (it doesn't take long to fix) to ensure these findings are corrected. Once the developers and middleware admins get used to this, it doesn't take them long to ensure all headers are correctly added and configured for each site.
this obsession with https is overstated, especially when you're more likely to get f*cked by companies mishandling the data you willingly gave to them anyway.
https is good for verifying the authenticity of the message. but that's it. if we're seriously going to be talking about it in terms of security, we need to focus on other, more common vulnerabilities instead. eg user training, data handling policies such as gprd, tougher fines for security negligence by companies etc.
User Training is a lost cause when you're up against Joe Stupid. The only solution there is a license to use the Internet, and do you REALLY want to license things done in the privacy of homes? As for data handling policies, that's going to be difficult to enforce outside the EU, especially for sites whose contents and handlers never touch Europe.