Even more interesting: In the current Firefox nightly inputs with `type="password"` on insecure origins are being marked explicitly as insecure. This also includes common anti patterns such as loading an iframe from a secure origin on an insecure page.
There's a screenshot of this on my latest blog post[1] and another article[2] on this topic.
I am very happy to see browser vendors pushing for HTTPS adoption and forcing the hands of developers. Further highlighting poor security like this also means that users are made aware and can opt out of using websites with poor security practices.
There is (of course) a Tumblr site for sites that do this[0]
I found a bunch of local websites including utilities and email providers that do this[1] and seem completely unaware of the risk. Emailing them to explain the problem didn't help much as the vast majority simply ignored me. Hopefully this will make it into all the mainstream browsers soon because not protecting sensitive data with HTTPS is really inexcusable in 2016. It's not like it costs a lot of money to do.
Yeah, mine is a shameless copy of the Plaintext Offenders Tumblr (http://plaintextoffenders.com/) which I've known about for years, but I wish I had spotted the HTTP Shaming one earlier as I would have saved myself time and submitted the local sites there instead. Oh well.
I really love what plaintextoffenders is trying to do, but i've lost all confidence in it.
Most of the sites on there are because of things like they will email you a temporary password forcing you to change it on first login. Digital ocean has a big red banner because if you don't provide a private key, they send you a randomly generated root password for new servers you make.
FFS apple.com is on their list because someone SENT IN an email with their username and password for their phone on it, and they replied with a "work authorisation" letter that included the message they sent it...
The old plan was to enable it in Fx 44 (the one that was just released). But a couple of bugs caused a delay and it was pushed back. It was just enabled in nightly/dev builds [0], so Fx 46 will probably have it.
AFAIK and contrary to what others have said, there's no plan to enable this in a release version of Firefox anytime soon. There are too many affected sites and most average users would probably just start ignoring the crossed out lock or get scared and use some other browser.
It's in dev edition / aurora because those aren't "release" builds, and the security.insecure_password.ui.enabled default value depends on a RELEASE_BUILD ifdef. So no, it won't automatically be enabled when current aurora moves to beta.
I was under the impression that it worked like an Alpha and the intention is for features in it to eventually end up in stable unless critical problems are found in them?
This is usually true but not in this case. Or if you want to put it this way, the anticipated critical problem is that this UI would confuse average end users and thus we won't enable it for them.
Loading an iframe over http is at least not going to expose the users password to a passive attacker. I would really hate if we repeated the error whereby sites signed with non root ca keys got marked with a big scary error, because it wasn't as secure as it could be.
Somewhat off-topic:
I feel that Firefox has improved significantly lately, even though it ceased to be the "star" browser a while ago.
Its usability is much better than other browsers. On Linux for example, it integrates with GTK and the rest of the OS seamlessly.
Also websites tend to display and function more accurately than in Chrome. This is subjective, it might be just me who experienced more broken websites lately.
I have noticed that Firefox on Android seems to keep up much better on bigger pages. I regularly browse SBNation sites and Chrome locks up to the point that I have to kill the entire browser. Firefox handles it much better, also in my anecdotal experience. That it allows you to install plug-ins like uBlock is simply a bonus.
That being said, the performance on OSX at my last check seemed to be inferior to Chrome unfortunately. The development tools are still inferior, too. I want to move away from Chrome on OSX but still can't justify it.
I disagree with their rationale in changing the padlock used to indicate a DV certificate from grey to green (and thus mirroring EV certs) to a point: Yes, the connection is secure, but given the numerous free and automated options to obtain DV certificates, phishing sites are going to increasingly use TLS, and mostly do so using DV certificates.
I guess this boils down to me actually favouring a clear divide between EV and DV. My EV connection to bankofamerica.com should be as visually different from the DV connection to the phishing site bank0famer1ca.com as possible. As it is, the Firefox UI improves visibility of encryption while I think it might be more appropriate to improve the differentiation between encryption and authentication.
As for all the other states: good work. The new iconography seems more streamlined and clear to me.
For me the presence of the organisations name in green letters emphasizes the difference. (Besides the green/grey lock difference alone is small enough to miss)
The UI choice i don't like is having a hazard sign for secure websites with mixed active content blocked . Hazard sign implies some hazard exists - but in this case the hazard has been averted, so why show a hazard sign still?
> Hazard sign implies some hazard exists - but in this case the hazard has been averted, so why show a hazard sign still?
The way I see it, the browser actively blocked a hazardous action. The site continues to be hazardous, and another browser might not properly block the action in question. As long as the site is trying to do hazardous things, it should be considered as such (and warned against).
what i really want is an indicator of how many 3rd party https domains have dumped active content onto the page. better yet, disallow this behavior entirely.
the fact that banks and other critical portals can dump third party scripts like optimizely and stuff from https cdns is truly disturbing.
it's such an obvious oversight to me that i dont understand how a green anything can be shown on mixed https domain sites. am i not understanding something?
Mixed content means HTTP+HTTPS resources, not HTTPS-only resources from multiple domains.
And it's not always clear what's "third-party", as a common optimization technique is to serve static assets form a second domain, to increase the number of parallel connections.
Working around browsers' maximum concurrent connections settings is a major reason to use multiple hosts. This table of browser [0] is somewhat dated but these limitations have been have always been present since the first browsers, I doubt they've radically changed in the last few years.
I could have outdated information; in either case speed isn't as important as security.
Why haven't servers started advertising how many connections they are willing to accept? The need for other domains could be easily removed with something like an HTTP response header:
200 Ok
...
X-Max-Parallel-Connection: 10
...
This type of header could even be used to give per-page values:
>> increase the number of parallel connections.
> I believe that trick is to save bandwidth by not sending the (large) cookies that would normally be sent to the normal domain.
No, Internet Explorer (and other browsers) used to only allow a small number of connections per domain. Long running COMET requests ate up these connections, so if you wanted to simultaneously download multiple resources from a single domain, and reduce time to page ready, then you had to use multiple domains.
The limit is per host, not per domain. Before using CDNs became commonplace, it was not unusual for a site to use multiple hostnames of their own to spread out their content and have more parallel connections for a single page load; example.com img1.example.com, img2.example.com, etc.
my argument is that there should be no need for the average user to install noscript to prevent injection from third party "secure" domains. the default should be to deny loading them in the first place.
there should be a "yesscript" for those who want to assume the risk.
But how do you know which resources from a separate domain are third party ones, and which are from (for example) a dedicated CDN run by the same people who operate the site you're visiting and fundamental to its normal operation?
For now, there are still performance-related reasons you might want to do this, and many high volume sites do.
Security is always more important than performance. It's irresponsible to sacrifice security simply to make page loads faster.
And where does functionality fit in, in your black and white world? It's easy to make a lot of things perfectly secure, but if in doing so you give up the essential functionality that made those things useful in the first place, what have you really achieved?
If you make JS whitelist-only, no exceptions, then you will break the web for huge numbers of people on huge numbers of sites they value, because JS is useful. Those people aren't going to thank you for keeping them safe, they're going to say your browser doesn't work, and then they're going to use someone else's browser that does work instead.
In reality, security is nearly always a sliding scale, and the best results are nearly always achieved by balancing security against other factors like performance and functionality to keep the user as safe as possible while still providing whatever it is they actually want.
You are presumably willing to trust the first-party website for content and it is not a big stretch to trust the third-party content they chose to include as well. Not much difference between trusting them to serve jQuery themselves (which they must source from a third-party initially) or link to it directly at the third-party site, for example.
The code they source from the third-party initially can be audited and then self hosted. If the code is not self hosted, the third party can change the script to be malicious (or be compromised) without the first party ever knowing.
I think this is why integrity hashes should be included anytime a CDN is used to load a third-party library. Bootstrap does this, for example: http://getbootstrap.com/getting-started/
I'd like to see more lib providers, and even CDNs themselves, follow suit.
Thank you, i always thought about this but didn't know it already existed. This should definitely be used for any content included on a page, especially third party CDN, it could also allow caching if the address changes but the content is the same.
I agree generally, although Subresource Integrity[0] and Content Security Policy[1] somewhat solve the problem. Not that any of this will ever be deployed[2], because they're two of the most invasive defence measures and fragile wrt updates.
> Not that any of this will ever be deployed[2], because they're two of the most invasive defence measures [...]
SRI is going to be a tough sell. CSP, not so much.
Case in point: within two years, HSTS use by Swiss Banks has gone from 0% to 40%. I managed to get the first deployment up and running, and at this point we made it into the preload lists. If just one company gets any of this stuff up and running (and whomever did it keeps pestering their colleagues at some others about it), adoption is possible.
Right now I'm working on getting some traction with HPKP and CSP. HPKP is going to be challenging as doesn't offer protection against user-installed (or malware-installed) root certificates, but seeing how the cost of adoption is low, it shouldn't be impossible.
CSP should be easier. Being the responsible bank we are, we aren't dropping any javascript files from CDNs into our pages. Anything running in our domain originates from there, so it's basically down to starting with -Report-Only, unsafe-eval and unsafe-inline options and gradually moving towards *-src 'self'. And it provides valuable protection against all sorts of Adware and Malware.
Ping me in a year. I'm confident we'll get there by then.
Sorry, I don't have a public reference. The first number came from my (unpublished) 2013 bachelor's thesis, where I surveyed the 20 biggest banks (by balance sheet) in each of CH, DE, AT, IT and FR. HSTS was very new back then, so the 0% was no big surprise. The full thesis is in German. I can send you the PDF if you're interested.
For the second number, I had a look at 15 banks represented at Vontobel, Credit Suisse, J. Safra Sarasin, PostFinance, Raiffeisen, Swissquote, UBS, Valiant and the State Banks from Basel, Geneva, Grisons, Schaffhausen, Thurgovia, Zug and Zurich. Of these 15 banks, six were using HSTS: CS, PostFinance, Raiffeisen as well as Basel, Thurgovia, Zug and Zurich.
Switzerland has over 200 banks in total, but many of these are small private shops, only a couple dozen actually offer e-banking. The majority of people is banking with one of the top 5 (PF/CS/Raiffeisen already are, and I'm hoping for UBS and Valiant to adopt HSTS soon-ish). The 15 I had a look at in December 2015 are responsible for the vast majority (90+%) of online banking done in Switzerland.
Then you need to detect CDN's that actually serve your content. Images and such. They can also come from your subdomain(s) of course. Maybe you could whitelist the subdomains only.
I think it's safe to assume HTTPS when it comes to browser indications is broken. In a sense that majority of user don't care or understand.
I once had a client who wanted an EV cert, so the company name gets "shown nicely in the address bar". After explaining about encryption for half an hour, the only question was why should I care. It was a simple website for a company. Contacts and about us mainly.
I often ask regular users, and they don't know what difference does it make, the click everything and as far as they care, the lock can even be purple. Which doesn't mean we shouldn't keep pushing https mainstream of course.
> I think it's safe to assume HTTPS when it comes to browser indications is broken. In a sense that majority of user don't care or understand.
I'd agree with this as well. I find summarising it as "if you enter secret details when the green lock isn't there, a hacker could steal them" isn't concrete enough to sink in for most non-technical users. To really understand what the HTTPS lock icon means let alone what mixed content warnings means requires a lot of background knowledge most of us take for granted (web servers, networking, hacking, how a web page loads scripts/images/css).
Given many people still use simple passwords and the same passwords everywhere because of lack of understanding of what hackers can do, I think it's a lost cause.
People do pay attention to e.g. Chrome's big red "this site is not secure" screen that you have to bypass when there's something wrong with the SSL certificate though. Showing something like this as standard would help.
I managed to get my mother to use a password manager. I did my due diligence in explaining the security aspects, as far as "well if someone gets your Facebook password, how likely is that to be your Gmail password" , but mostly had to frame it as a convenience feature of being able to use all these complicated passwords without having to remember any of them.
I've lost count of how often I've heard friends and family say things like "well there's nothing important in my computer/email/Facebook anyway". I try to explain about how hackers can use credentials to eventually get into their bank accounts, steal their identity, use their computer in botnet and spam schemes etc. but it usually comes across as farfetched for some reason. I'm sure it sinks in when they or someone they know is directly impacted by a hacker but I think the problem is this doesn't happen often enough.
I think the part that is hard to grasp for people without a technical background is the danger of automated attacks. It's hard to explain that even if nobody is interested specifically in their computer/email/Facebook, they can still be a victim of a dragnet kind of an effort.
Yeah, I struggle to think of any good analogy that would help explain the problem. You could explain HTTP as like sending a postal letter where an attacker can intercept and read the letter undetected, reply back as if they were the receiver etc . but that's already pretty abstract. Drawing a real-world analogy with automated password attacks seems even harder.
"There's a gang around here that like to walk up to every car in the parking lot and try every door. They aren't targeting you specifically, they just try every door knowing that some doors will be unlocked. So always lock your doors"
Why would you do that? Did you also try to explain the beauty of diffie hellman key exchange and the details of TCP selective acknowledgement before helping your client get an EV cert?
> I once had a client who wanted an EV cert, so the company name gets "shown nicely in the address bar". After explaining about encryption for half an hour, the only question was why should I care. It was a simple website for a company. Contacts and about us mainly.
What does encryption have to do with EV specifically? And why did you care? I'd happily help a business client get an EV certificate for conducting business, that's exactly why they exist.
The real truble with Firefox UX regarding security is that a HTTPS connection with an untrusted certificate is more hassle than an unencrypted connection. But from a security concern, HTTPS with an untrusted certificate is better, it prevents passive eavesdropping at least. It's certainly not worse than unencrypted traffic.
And yet firefox continues to make it hard to accept untrusted certificates.
It is worse, and this has been discussed to death: when you go to www.facebook.com, what UX will help people distinguish between trusted certificate (all good) and untrusted (active attack)?
I understand their motivation as sending traffic that is expected to be secure to the wrong person is worse than knowing ones traffic is visible to all hops.
Everyone always defends this, and I can't understand why. Here's the way I see it:
unsecure-cert= me + some unknown entity can read it.
no-cert = me + anyone can read it.
I'd rather have some shady unknown entity read it, than everyone read it. Of course, a warning for both should exist, but IMO, the 2nd is much worse. Am I mis-understanding how this works?
An encrypted-but-unauthenticated connection is not readable just by some unknown entity, but by an arbitrary, unbounded number of unknown entities, which is practically the same as "anyone."
Anyone who's in a position to passively eavesdrop an unencrypted connection is usually able to actively eavesdrop an encrypted-but-unauthenticated connection with just a bit more work.
An unencrypted connection isn't "absolutely" seen by others. If no one eavesdrops on it, it's private, just as an encrypted-but-unauthenticated connection is private if no one actively attacks it.
Theoretically, an untrusted cert is the lesser evil since active attacks should be harder/more expensive than passive attacks, but no one knows exactly how much harder/more expensive they are in practice. This makes me very hesitant to declare one better than the other.
Ultimately, browsers are going to start warning about unencrypted connections, and hopefully one day browsers will treat them just as severely as connections with untrusted certs. Unfortunately, we have to undo decades of bad practices first, which is a slow process.
Lets take the common case of public wifi with no encryption. I can trivially listen to all the connections and get what information is being sent - how do I intercept the traffic?
Use ARP spoofing to masquerade as the router, use DHCP spoofing to deliver a rogue default gateway or DNS server, or set up your own access point that uses the same SSID.
People look for a lock - that's the only thing everybody knows about web encryption. An open lock is still a lock, thus plenty of people will understand it as secure.
On what case do you want the open lock? If this is about the active mixed content warning, I do think it's worse than the previous version. But well, it can only happen by manual intervention, so nobody will ever see it.
There's a screenshot of this on my latest blog post[1] and another article[2] on this topic.
I am very happy to see browser vendors pushing for HTTPS adoption and forcing the hands of developers. Further highlighting poor security like this also means that users are made aware and can opt out of using websites with poor security practices.
1: https://hugotunius.se/2016/01/24/how-browser-vendors-are-pus...
2: https://www.fxsitecompat.com/en-CA/docs/2015/non-https-sites...