Updated Firefox Security Indicators
blog.mozilla.org
blog.mozilla.org
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...
Do you know what the plans are for enabling this in all editions of Firefox?
[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10
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.
[0]http://httpshaming.tumblr.com/
And yes I see the irony in having an HTTP site for this, but at least Tumblr does a proper HTTPS form post action...
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...
That's not what it's meant to stop...
Me too, but the fact that the update downloads automatically via plain HTTP ruined it a bit for me...
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 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.
There's way less clutter in the address bar too, so the difference is more striking:
If Firefox believe users don't know understand the difference, the logical thing is to help fix that, not make it worse.
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?
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).
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?
Douglas Crockford warned[1] us about years ago about the dangers of mixing 3rd party Javascript. Unfortunately, very few listened to that warning.
there should be a "yesscript" for those who want to assume the risk.
For the moment, unfortunately, we're stuck running noscript (or similar).
For now, there are still performance-related reasons you might want to do this, and many high volume sites do.
> performance-related reasons
Security is always more important than performance. It's irresponsible to sacrifice security simply to make page loads faster.
Some of these problems can be worked around in the future with authenticated hrefs (such as with a hash-check aka subresource integrity).
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.
But your point stands. That should be done in the browser by default
the desired behavior is: when on https, auto-blacklist everything except current and sub-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.
That's already defined by the same-origin policy.
> a common optimization technique
Optimization should never happen at the expense of security. (and yes, 3rd party scripts are a security risk)
> 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.
[0] http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-co...
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
...
X-Max-Parallel-Connection: 20, scope=local-page-only
Yes, I know these are not supported by browsers yet, but sensibility is one of the best features of HTTP.
[0] https://www.w3.org/TR/SRI/
[1] https://scotthelme.co.uk/content-security-policy-an-introduc...
[2] https://scotthelme.co.uk/how-widely-used-are-security-based-...
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.
That's awesome. Do you have a reference? Not doubting you, just want to read more.
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.
https://www.npmjs.com/package/csp-by-api can help with that: it contains CSPs for popular APIs so you can just add the the APIs you're using to your own CSP:
var policy = cspByAPI(basePolicy, ['twitter', 'mixpanel', 'googleFonts', 'stripe', 'typekit', 'ractive'])I'd like to see more lib providers, and even CDNs themselves, follow suit.
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.
Correct me if I'm wrong.
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 wouldn't want some shady ISP or a public hotspot injecting ads (or worse) into my company site.
What I wanted to tell is that even after explaining, the person in question just wanted "that green lock with company name". That's it.
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.
I assume it's somehow related to the 44 having just been released?
I have no idea what they mean, other than the plain grey lock and plain green EV lock and name.
And yet firefox continues to make it hard to accept untrusted certificates.
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?
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.
unsecure-cert= me + some unknown entity + possibly others
no-cert = me + some unknown entity + absolutely others
So, and insecure-cert still seems like the lesser evil?
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.
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.
Can the company name text inside the green bar for EV certificates be spoofed and used for phising?