Slashdot Mirror
Mozilla To Support Public Key Pinning In Firefox 32
Trailrunner7 writes: Mozilla is planning to add support for public-key pinning in its Firefox browser in an upcoming version. In version 32, which would be the next stable version of the browser, Firefox will have key pins for a long list of sites, including many of Mozilla's own sites, all of the sites pinned in Google Chrome and several Twitter sites. Public-key pinning has emerged as an important defense against a variety of attacks, especially man-in-the-middle attacks and the issuance of fraudulent certificates. The function essentially ties a public key, or set of keys, issued by known-good certificate authorities to a given domain. So if a user's browser encounters a site that's presenting a certificate that isn't included in the set of pinned public keys for that domain, it will then reject the connection. The idea is to prevent attackers from using fake certificates in order to intercept secure traffic between a user and the target site.
They should enable the user to visit an HTTPS site (e.g.: his bank) and tell Firefox to remember the entire certificate chain. If a subsequent visit uses a different chain, show an warning and do not continue without manual intervention.
This is a good idea, but I bet it will not work well on corporate networks that do MITM attacks: every cert will be wrong. This same thing happens if you use the SSL Observatory add-on. This clearly shows how the public key infrastructure implementation is completely flawed.
"Known good," eh?
Sorry! I'm totally wrong! The corporate MITM will work just fine once it is updated:
The UA will not be able to detect and thwart a MITM attacking the
UA's first connection to the host. (However, the requirement that
the MITM provide an X.509 certificate chain that can pass the UA's
validation requirements, without error, mitigates this risk
somewhat.) Worse, such a MITM can inject its own PKP header into the
HTTP stream, and pin the UA to its own keys. To avoid post facto
detection, the attacker would have to be in a position to intercept
all future requests to the host from that UA.
Lets patch an inherently broken system with another inherently broken system that does not scale and will cause a whole new range of unwanted side-effects and problems.
What ever public-key pinning is. How about a stable 64-bit version for Windows, and actually fix the bugs in their software (yeah, Thunderbird too) that have been actively open for *years* instead of wasting time a mobile OS that nobody uses, and features that aren't really relevant. Hell, just working on the things that are broken might fix the issues they're pushing through as new features.
Okay. But where's the warranty for guaranteeing these "pinned" public keys?
When will Firefox support killing CPU-hogging tabs individually?
That's the only killer feature from Chrome I'm waiting for to switch back to Firefox.
In Chrome, if I've got 50 tabs open (not uncommon) and one of them starts spiking my CPU, I can pull open Activity Monitor (on OS X) and kill the "Google Chrome Helper" that's eating all the CPU.
That kills the one tab that was the problem, not the whole browser. And lets me reload it when I actually care about that tab again.
I haven't found a similar way to imitate this workflow in Firefox.
The whole noscript / flashblock / adblock / etc approach hasn't worked. Tried it with Firefox, still had constant CPU issues after whitelisting sites I need JS or Flash turned on for, still had no way to kill runaway processes individually.
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
and now they are just nother browser. Mozilla is trying too hard to be like Google. This is killing their chances at being a successful stand-alone company.
The default is:
1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)
So CAs inserted by the corporate networks will be allowed, only verified for CAs shipped by Mozilla
The Firefox, just as Chrome does, supports a list of pre-pinned sites. For these sites there is MITM protection because they don't first access the site to get the PKP header. Both Firefox and Chrome have a mechanism for you to submit your site for inclusion in their list.
That being said this will still not break corporate MITM because the default setting for both browsers is to ignore pinning if the certificate is signed by a CA added to the local CA store versus the public CA store which ships with the browser or OS.
... will have air gapping and sneakernet.
My salute to FF -- you are not the problem, but you are not the solution either.
And that is the intention, I don't want MITM attack by my company or anyone else.
The whole point of certs is to prove that something came from you. If anyone can sign your page and browsers will accept it then what was the whole point of certs? Why don't certs work like this allready?
Maybe I should go RTFA now.
Then perhaps you should browse personal sites on your own dime, not the company network.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You will want to avoid working for companies that will soon have mandated data leakage prevention policies, such as those governed by FFIEC or HIPAA. Auditors and federal examiners will interpret the mandate to mean all outbound Internet traffic must be inspected.
Why does the list have to be hardcoded? Why not pull the records from DNSSEC... there's a whole specification for this, RFC6698
Wonder what the public key field is for?
That is why people who care about privacy should avoid such employers.
Sorry! I'm totally wrong! The corporate MITM will work just fine once it is updated:
Props for correcting yourself. Integrity's sexy.
Or be private in private.
Then perhaps you should browse personal sites on your own dime, not the company network.
Then what's the problem? Mozilla will no longer let employees do that.
Can we hope for a blue snowfox who's pinning for the Fjords?
So people who care about privacy should avoid working for companies that are being forced by regulations to care more about privacy? That somehow does not seem to be the best recipe for success in helping companies who should be caring about privacy.
...Pale Moon for ever!!!!
http://www.palemoon.org/
I have yet to encounter corporations applying policies or default configurations to firefox. Often there are just instructions left for configuring the browser in my experience (as opposed to the corporation Chrome, IE installs).
Change is certain; progress is not obligatory.
Without commenting on whether, and in what circumstances, it's wise for companies to operate MITM firewalls:
It seems to me that this change should, in fact, make such firewalls more secure, because it'll encourage web server admins to start using PKP, which will allow the firewall to better verify the remote server identity. (Whether the creators of the firewall software will actually implement this feature is of course another question, but anyway...)
In fact, PKP itself will be more effective if it's implemented at the firewall, because in that case only *one* user has to visit a given site for *everyone* to be protected against future MITM attacks.
I, for one, hope it puts companies like Blue Coat Systems Inc and their re-encrypting internet appliances out of business.
But I don't see mention in any of the links about how they maintain integrity of the public key list itself. Mozilla itself is not immune to compromise or influence but even if we assume that the source list will always be secure how about when it's in-transit to the browser clients? Even over SSL there could still be MITM attacks that modify the contents of the list to include the MITM attacker's public keys. Presumably the in-transit list will be public-key signed, as with manifest files, so as to be verified by the browser before it updates or replaces its existing list. How will it then be secured in the browser's file system? In memory?
So therefore it is guaranteed to screw up on any device that uses multiple networks. Such as corporate laptops or BYOD.
Lets face it, the only browser that seems to give a toss about the corporate environment is IE, as much as that pains me.
Google Chrome recently had a serious bug that hammered corporate authenticating proxies with huge numbers of requests for over a month before they released a fix. Users couldn't revert to an earlier version, and the only workarounds required manually getting users to follow certain steps every 7 days.
I think many corporate environments banned chrome after that, looks like firefox will be next.
Usually certificates have an arbitrary high cost, expire yearly, need to be reissued because you need to add a subdomain (and "wildcard" certificates are usually very expensive). I can see trouble for all but a few domains, who will register certificates for decades, maybe because they have their own c.a.
If you are the IT director of a big corporation, you have no option but to MITM SSL traffic. The alternative is providing a perfect way for malicious insiders to steal corporate secrets (like a whole pile of credit card numbers or the blueprints/source code for the companies latest products). And providing a vector for malware or attacks to bypass all the edge-level intrusion detection systems.
And providing a way for the people on the inside to access things that they shouldn't (whether its pornography, pirated content, or anything else). That last one is even more important in, say, a school or educational environment or library than in a corporate network.
You mean what corporate networks are doing is wrong. That is the biggest flaw.
They should move to a model of a proxy configured in the browser. The browser then can trust the proxy.
New things are always on the horizon
You can also configure every browser to use a proxy-server and then block all the other webtraffic at the firewall.
New things are always on the horizon
So they have given up on certificates alone, don't they?
But how many of my addons won't work? The version number wars between the browsers is silly.
We've had some source code theft recently at my job, so we have an SSL MITM proxy that generates a work SSL cert for everything. At first I hated it, but it is a work comp, and they provide a dirty LAN, so just bring your device if you want to browse your mail.
But, this would break Google searches for me. I wouldn't be able to look at any Google site, no Google searches, no wikipedia, no stackoverflow on my work comp with this. Make this a hard to find, no normal person would be able to find it, only geeks can flip the switch, config to turn this off please.
Except that the proxy server will have to MITM SSL for it to work.
See subject: It uses it between it & its upstream updaters + OpenDNS = patched vs. Kaminsky flaw (security issue in redirect poisoning).
As you pointed out: 99.999% of ISP DNS', don't, & aren't patched vs. Kaminsky bug either
(Even though a patch has been out for nearly a decade (due to MX records setup problems iirc)).
I use it because of that, in combination with custom hosts files which I have COMPLETE LOCAL CONTROL OVER!
(For extra speed, security, reliability, & even anonymity (vs. dns request logs OR to get around DNSBL's I may not like), & they do so more efficiently and DO MORE than any 1 browser addon does, minus their messagepassing & cpu + ram hogging overheads in slower usermode, since hosts are part of the kernelmode IP stack + the 1st resolver queried by the OS... heck with redundant SLOWER browser addons).
* OpenDNS + custom hosts files go together like 'bread & butter' for faster, better & more reliable, + safer websurfing, all the way around (& hosts fix dns security issues too - bonus) + DNS admins must love me (lol) - I lighten up their request loads too.
APK
P.S.=> APK Hosts File Engine 9.0++ 32/64-bit: http://start64.com/index.php?o...
... apk
This AC makes a key point: It is the auditors who decide the real policy. Sometimes that is good since I don't want politicians deciding those details. But the bad part is that the auditors, when faced with ambiguous language, will overreact and require nearly impossible things like keeping all web pages served for the next 10 years.
I am unclear on all this, but "the browser then can trust the proxy" seems to mean that same thing as the MITM. The proxy issues a cert, and the browser has to trust that cert. It is a form of MITM attack: except you know and (supposedly) trust the MITM.