Closed Bug 398721 (KCM) Opened 17 years ago Closed 9 years ago

Key Continuity Management (KCM) - Remember previously encountered certificates for a given host, alter NSS/PSM trust model for those certificates

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: johnath, Unassigned)

References

(Depends on 1 open bug)

Details

Garfinkel ( http://groups.csail.mit.edu/uid/projects/secure-email/soups05.pdf ) and Guttman ( http://www.cs.auckland.ac.nz/~pgut001/pubs/underappreciated.pdf) both make the case that the real issue in many interactions that use SSL is not whether the site has been identified by a particular CA, but rather whether it is the same site as the last time you visited. The argument is most often applied to mail, but it can easily apply to web sites too. In bug 327181, we changed PSM from using security dialogs with immediate overrides to error pages which require explicit (and complicated) user interaction to override, and this treatment extended not just to invalid certs (expired, domain mismatch, etc) but also self-signed certs. Self-signed certs were included, in part at least, because of the potential for fraud & MitM attacks, if they are accepted. What if we used KCM? What it would mean is that we'd have to start indexing the cert for every SSL site we encounter, and rather than treating self-signed certs as instantly erroneous, we could instead treat them as nothing in particular - neither good nor bad, accept the encrypted channel and proceed - as long as the site in question didn't have a non-matching cert on file. It feels like this would prevent the same attacks, while allowing private sites to employ self-signed SSL as a means of encrypting the channel. I understand that the economic argument for SSL sites, that CA-signed certs cost money, is less-compelling in a world of $10 certs (or sometimes free) but in general, if we can prevent the same attacks without causing as much annoyance to web developers, I'd like to explore the option. How deadly would it be to keep this index and check it? How would we handle cases where there was a mismatch? Is this even a worthwhile idea? There are clearly questions here, but I didn't want bug 327181 to spiral off into debating the merits of KCM, so let's do it here instead.
My employer pushes SSH a lot, and recently there has been much discussion among employees and users that SSH users do exactly the same thing that Mozilla users do, the very thing that we're deliberately changing with this UI change: whenever they see the prompt that says that the host is using a previously unseen key, they simply click past it without a second thought, whether it appears on a host they use frequently or infrequently. It seems that even the SSH community is awakening to the propsects of MITM attacks. We're just ahead of them on the learning curve by virtue of having more users. Before we spend much time on KCM, I want to ask: what percentage of firefox users worldwide actually use self-signed certs in the course of a typical week, or month? I wish we had some objective way to measure that. I'd be quite surprised if it is even 1%. In the past we've been weakening the protection offered to the other 99% for the convenience of that 1%. That strikes me as definitely the wrong tradeoff.
> Before we spend much time on KCM, I want to ask: what percentage of firefox > users worldwide actually use self-signed certs in the course of a typical > week, or month? How in the world do we answer that question? I guess when we ship the beta with the obscure UI for enabling connections we'll start hearing from people. Firefox users I would imagine not so much (though they're more common on academic and corporate intranets), but Thunderbird users seem to encounter them a fair amount (and if not self-signed, mismatches due to virtual hosting). KCM would seem to work reasonably well in the mail situation, but don't we have a proposed design to grab those certs on Account set up? How do you handle cert expiration using KCM? How can you tell the difference between an expired-cert switchover and a MITM attack?
In further reply to comment 0, IMO, you definitely do not want to use KCM for ALL SSL server certs. You definitely do not want to use them for certs issued by trusted CAs. The reason is simple: the public keys for servers that use certs from trusted CAs WILL change, typically annually. If you throw up a dialog or error page for every site whose cert has been "renewed", and now has a different public key, you will again train users to ignore and skip past error dialogs. The KCM model depends on servers never changing their keys, and offers no solution to key compromise (no revocation checking is possible). The model of trusted issuers does not depend on long term continuity of keys, and indeed changing keys periodically is believed to reduce vulnerability to long term attacks (e.g. factoring). So, the conditions that are thought to be error indicators in one model are not error indicators in the other. If you apply a single set of criteria for determining errors (either KCM criteria or trusted issuer criteria) to both sets, the criteria will always find fault with sites that operate according to the other criteria. SO, it's best not to apply KCM criteria to certs that pass the trusted issuer tests. In reply to comment 2, Dan, you're right that we'll start to hear complaints from the people who do encounter self-signed certs. And we won't hear ANYTHING from the majority of users who don't encounter them. The newsgroups will have lots of messages saying "I'm unhappy", and none from others saying "it all works fine for me". If Mozilla products continue be steered by the "squeaky wheel gets the grease" algorithm, the products will continue to be more responsive to the desires of the 1% than the 99%. IMO, we *need* a way to find out the real numbers for our users. There are ways to do this, but they run the risk of being accused of "phoning home". OTOH, users seem quite happy for their browsers to phone Google. Isn't FF3 checking with Google as part of some malware detection/avoidance feature ? If we're using some Google service as a sort or revocation service for non-SSL sites, should we do that for self-signed SSL sites, too?
The big problem I have with KCM is that it seems to be particularly vulnerable to phishing (or at least it offers no resistance to phishing). It never complains on a first visit to a site. The first time a user visits a phisher's site is when she clicks on the link in the phisher's email. She winds up looking at a page that looks on its surface like her bank, or like paypal, and she sees no negative indicator that it's not who it appears to be. Since it's NOT her bank's real site, but rather is a phony she never visited before, there won't be any alarm about a public key change. And if she returns to that site, there won't be any warning either. IMO, KCM is OK for very low value stuff, but heaven help a user who does his online banking on a KCM site. If there was a way to detect that the user is trying to do her online banking, and alert her to the fact that she's banking at a KCM site, that might be OK, but I've never heard of any way to detect that.
I would argue that that to safely use KCM requires a fair degree of sophistication, not something you want to unload on the average firefox user. I've heard of cases here where someone mistypes the domain name in ssh and winds up with a 'do you want to trust this key'. Since this happens frequently, the person blindly says 'yes', winding up failing to connect and then realizing that he probably just gave his coorporate username/password to someone he didn't intend to. This muscle memory is well ingrained. In the older versions of firefox (like 2.0;), you were able to override and remember, pretty much the same activity as KCM. The problem was that we had so many sites, most users did not even see the dialogs. We've had conversations that go like this. "You need to fix the cert on your website, It's throughing security dialogs?" "No I don't see that dialog" "Oh, you must have trusted it explicitly start a new profile" "Nope, still don't see it" "OK, try this again, We'll type each character one at a time together.... ok there" "Oh, hey, there's a dialog" That says any sort of automatic click through will just train users where to click through. The current model that we've now checked in is really KCM done safely for the home user. That is the home user, for the most part, will continue use use CA certificate authentication. The KCM user, however, can turn off trust for all certs and explicitly enable each website. The trust is now certificate bound to host/port. Only those sites you have explicitly configured to trust will be trusted, no accidental leakage to untrusted sites. Less sophisticated users need to be come sophisticated enough to go explicitly enable the web site. They have to do it for each and every website exception, meaning they have that extra time to think "is this really what I want to do". We knew about the KCM model, both it's usefulness and it's pitfalls, when we designed the current exception handling. We picked up the useful parts and protected against the rest. (BTW this leaves out the whole issue of revocation, which KCM punts on, but the current model handles). bob
I agree with Nelson (#3) that if you do implement KCM in whatever variant, alongside the existing PKI/CA security model, then you should be very careful to not mix the security models, initially. Not because it can't be done, but because it looks too hard to reliably design without making some blunder. Limiting KCM to self-signed certs for now seems a mighty fine first step, and only extend it later if experience supports that. otoh, I disagree with the need for numbers. People don't use self-signed as much as they could, simply because it gets a dirty look from the browser. Fixing that and adopting the KCM security model could radically change the numbers, so old numbers aren't as relevant. That said, securityspace.com does report high numbers of SSL self-signed certs, around 8% http://www.securityspace.com/s_survey/sdata/200709/certca.html On Jonath's economic discussion: It's not just $$$. Management of the CA process is also another cost that the sysadm has to bear. This might be getting access to the company credit card, or it might be hassling with the interface to check ownership of domain ... either way, all these costs are swept aside by the self-signed cert, so sysadmins will continue to favour them for certain tasks. And, you still have these costs even with a free CA like cacert or startcom. On Nelson's first time visit bug: browser should complain in some sense! That's when you set the petname, on the first visit. On the question of revocation and replacement certs: I don't think it is reasonable to take PKI's features and impose them over another security model as requirements. The desire is not to replace PKI but augment it. Certainly, replacement of certs is a plus in PKI's favour. If a sysadm wants that, he knows where to get it. For free, he gets what self-signed certs do for him.
> On Nelson's first time visit bug: browser should complain in some sense! If I understand correctly, this enhancement bug requests "do not warn on first sight". But I agree we Nelson and Ian. We must warn on first sight, too.
Severity: normal → enhancement
I had mentioned an idea on bug 399275 that really should have been on this bug, but having not seen anything similar mentioned here, I'll mention it here as well. My idea there was not to explicitly tie a given cert to a site, but only remember if that site had a valid CA-signed cert or not. If a site that previously had a valid CA-signed cert last time we visited it suddenly shows up with an invalid cert, then we absolutely refuse to go there, period, on the grounds that a site that already had a valid cert would be maintaining it. If a site which has always had an invalid cert (self-signed, hostname mismatch, etc) that the user agreed to override, then we prompt the user for an override again if the cert changes.
Alias: KCM
basically the way it's handled now is quite good: It helps unaware users staying secure. it handles the commercial-certificate (assure IDENTITY AND ENCRYPTION) use-case. BUT: for free (self-signed) certificates it is desastrous: At the moment the only option for these site is to remove ssl completely, as many users don't dare to enter. so i suggest for the free (assure "SAME IDENTITY" and ENCRYPTION) use case: - when the user hits a self signed page: --------------------------------------------------------------------- | WARNING - self signed certificate - identity can not be verified | --------------------------------------------------------------------- -> option to handle all future cases in the ssh way - need to keep a list of these keys + allows encryption and "anonymous" identity verification for private pages too, instead of discouraging use of sll (the ssh way: first time warning, if certificate changes: reject connection)
In reply to comment 9: Get a free ssl server cert from a real CA, such as startssl.com Then users have nothing to do to make the certs work.
free cert isnt the final solution... it helps, but isnt perfect. routers, appliances and other embedded things you cant change the cert web server that you dont control, you cant change the cert certificate history management is still needed to overcome this problems and will also help increasing the security for other sites (router or dns hijack, pointing to a fake https site)
> routers, appliances and other embedded things you cant change the cert Yes and to that point I've been using Safari to manage Mozilla's HP servers and their out-of-band management (iLO) and for accessing HP's server management homepage (HP SMH).
Manufacturer's of routers and appliances can act as CAs and put valid certs into their appliances. At least one router vendor is attempting to do just that.
Yeah, because having thousands of devices with the same cert is so much better. AFAIK, if you make a exception doesn't Firefox only make an exception for that particular cert? Not just a URL?
(In reply to comment #15) > Yeah, because having thousands of devices with the same cert is so much better. > > AFAIK, if you make a exception doesn't Firefox only make an exception for that > particular cert? Not just a URL? Exceptions are bound to a host:port, not just global trust for that cert. Otherwise you could get users to trust your cert for joeslolcats.com and then use subjectAltNames to claim that the cert was also valid for paypal, bankofamerica, and gmail.
I think it is also worth examining KCM as an application level policy rather than a toolbox-led development. Especially, email is practically already KCM in that the addressbook in modern mailers remembers the emails that were sent, and users more or less accept that as authentic. If there is any question, they get on the phone, or the plonk the email. Unlike Firefox users, email users do have to deal with bad emails all the time. So it may be that for email, the more appropriate model is to extend the addressbook to cache the keys seen than to build the KCM app into a "crypto store" like NSS/PSM. This view might have it that the certs (or their fingerprints?) are stored in the addressbook, and the checking and verification against history is done by the app. Whether this means that Firefox should do its own KCM and only use NSS/PSM as a dumb cert store I don't know. But it might be that the low-hanging fruit is better found in Thunderbird hacking; right now all the crypto in Tb is pretty much wasted, even expert users and communities can't sustain S/MIME in operation conveniently. (arguably, corporates with LDAP can do S/MIME better, but these are not the end-users I'm looking for!)
I think this is a great suggestion. For me, the fact that SSL does *not* enforce key continuity is *the* key weakness and makes it entirely unusable for me. Esp. for email. But also for critical websites (where critical does not mean $$, but gaining access to confidential data). I agree that CAs can help establishing the first connection between me and a third party. After the first connection, all I want to know is that I always speak to the *same* party. This is where CAs are more harmful than helpful, and it's easy to see why. CAs *will* make errors once in a while, they say that themselves. An error means that somebody else can get between me and somebody I already know and already have a cert for. This is an unnecessary risk. If we rely on CAs for first connection, and then ensure key continuity, we solve both the first connection problem and ensure that I always talk to the same party. For the cert expiry problem (which IMHO was a bad idea to start with, and mainly a way for CAs to make more money - revocation in case of private key loss would have been sufficient and works fine with GPG), I suggest the following solution: * Require website owners to continue using the same private key. * A fingerprint of that private key is put in the certificate. * We store on first site: host, port, cert fingerprint, private key fingerprint * After expiry of the cert (even now, only the cert expires, not the private key), the web site owner requests another cert from the CA, which certifies the same private key for another year, with a new certificate. * We see that the private key stayed the same, and we're happy - it's the same party. We can implement "KCM". * Revocation in case of key loss via CRL or OSCP is still possible. * If, for some reason - be it key stolen, cryptographic weakness, or that the admin prefers to generate a new private key all the time - the private key changes, the public cert *must* also be signed by the old private key, in addition to the CA. This is what GPG does, too. This shows us, who stored the old key, that the new key is authorized by the old owner. The CA certification shows that it's not a fraudster. * The only problem is if * The admin is ignorant of this new scheme and does not sign the new cert. * The private key is lost insofar as the admin cannot find it anymore. If that scheme above works, we have both CA ensurance and I can be sure that I always talk to my friend / trusted party, without having to worry about badly behaving CAs. I could start trusting SSL and S/MIME. As said, and I can't stress this enough, the lack of key continuity enforcement is *the* key weakness of SSL (and quite some security people agree). This was for CA-verified certs. For self-signed certs, the same would apply, obviously without the added ensurance of CAs. What happens on first sight of such a cert is to be decided. We could stay with what we have, or we could treat them like normal http (no lock, no blue, maybe even make the "s" grey), which would be my preference, given that it's no less secure than http, and we'd have rooted out the possibility that a self-signed certs gets into the way of my bank connection without me noticing. FWIW, we could implement the KCM as pref-off at first, until admins get used to it. Or for other apps like Thunderbird or custom xulrunner apps. "This is by-design behavior, not a security vulnerability. " -- Scott Culp, Microsoft Security Response Center, discussing the hole allowing ILOVEU to propogate, 5/5/00. http://www.samsimpson.com/static/cquotes
Does this bug exist for any reason other than to invite advocacy? We generally discourage advocacy in bugs, so it seems out of place to have a bug whose purpose is to invite advocacy. Can we please take advocacy out of bugzilla?
T: Nelson, Could you point to the definition of advocacy? If advocacy is: 1) Political opinions ("Gaza sucks, Israel rules") 2) Technical Snobbery ("Linux Rules, Windows Sucks") 3) Irrelevant requests ("Firefox should work with my blender!") Then, fine, I agree. If advocacy is: 1) Carefully considered and discussed suggestions on the implementation of fixes to user pain points 2) Statements that you disagree with Well, then you're just telling the people who care about this project to shut up and stick their head in a bucket. This issue exists, and despite the _advocacy_ of the folk who believe in the One True SSL Way, the problems with the One True SSL Way seem to be getting deeper, not better. I appreciate the careful thought exhibited in the recent posts and hope that the last year+ of helpful suggestion will make its way into the roadmap.
Nelson, a lot of what you write also sounds like advocacy to me (and enrages me quite a lot, FWIW). The same must be allowed to me. The majority of my comment was about details how it could work.
(In reply to comment #21) > Nelson, a lot of what you write also sounds like advocacy to me (and enrages me > quite a lot, FWIW). The same must be allowed to me. The majority of my comment > was about details how it could work. Without trying to speak for him, I think Nelson's point is that a bug is about "we have a problem, let's find the solution, write the patch, test, review and land it." It's not for "Me too!" or "I can't believe this hasn't been fixed yet." It's also not for writing new policy - we have other fora like newsgroups for that. Whether the comments on this bug count as one or the other is a point people could debate, but it won't get us closer to deciding this question. In answer to Nelson's question, I don't think this bug is purely an advocacy lure, or at least, I don't think it is necessarily so. The summary made it seem that way though, so I've changed it slightly. This bug may be WONTFIX, that debate is probably a policy one of the type best handled elsewhere. If it isn't WONTFIX, if we would take a patch for this, then the bug needs to answer: - How should this support be implemented in the cert store? - What should the user experience look like? - What effect should remembered certificates have on the existing mechanisms we use to decide whether a certificate is trusted or not?
Summary: Should NSS/PSM use Key Continuity Management (particularly for web sites?) → Remember previously encountered certificates for a given host, alter NSS/PSM trust model for those certificates (KCM)
(In reply to comment #19) > Does this bug exist for any reason other than to invite advocacy? There can only be advocacy if there is disagreement to implement the feature. Are you suggesting that there is no disagreement? Excellent, let's get to work!
Based on Johnathan's and Nelson's request, I opened a newsgroup thread for discussion: Subject: Key Continuity Management msgid: 49666B70.1070406@beonex.com Web: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/42ff016035beb116?q=#8731d1e07b5038c5
Summary: Remember previously encountered certificates for a given host, alter NSS/PSM trust model for those certificates (KCM) → Key Continuity Management (KCM) - Remember previously encountered certificates for a given host, alter NSS/PSM trust model for those certificates
I don't think you can work on the technical detail until you have the policy resolved. If KCM is a bad idea from the start, then there is no point in having the technical discussion. (Any more than a bug asking support for ROT-13 as an encryption algorithm). bob
I would say the use of KCM is not exactly a policy decision but a security architecture decision. If lots of applications (Ff, Tb) decide they want it, then they may decide to "advocate" solutions down at the NSS/PSM level, but that's a ways away. I'm not sure I'd suggest that until there have been some clear lessons learnt from some experimentation. The right place for the discussion is where the architects of the products wish to have it, methinks. It should be in a place where we can record lots of opinions (including some noise and advocacy) ... and keep it all in a single thread. The topic keeps coming up, so future proponents and advocates need something to be pointed to. I think this is a fine place (to disagree with Ben & Nelson, nothing personal!) but maybe it should be separated to be "Firefox KCM" and "Thunderbird KCM" ?
Bugzilla is *not* a fine place for threaded, wide-ranging, noisy discussion. If comment 26 is right (it seems right to me) about the need for "a place where we can record lots of opinions (including some noise and advocacy) ... and keep it all in a single thread", then I suggest using the thread Ben started. It seems to me this bug is the cart, we need to put the horse(s) first. /be
This add-on may be implementing what is requested here... https://addons.mozilla.org/en-US/firefox/addon/6415 ... but it would still be nicer to have it built-in.
Bug 560454 describes a specific threat, which is very real: There are ready-made boxes sold to governments which do exactly that.
> Bug 560454 describes a specific threat, which is very real: There are > ready-made boxes sold to governments which do exactly that. Please, let's be accurate: There are ready made boxes that will do "trusted MITM" attacks by issuing certificates on the fly from a CA loaded into that hardware. The CA loaded is usually a corporate root CA. These boxes are sold for corporations to filter SSL traffic through their firewalls. I agree that these boxes are evil, and I believe they constitute a threat to any site that manages user's credentials. Client auth is a complete defence, for this (the boxes cannot fake the client's credentials, thus can't stand in the middle). I believe this can provide new empitis to using client auth in the industry. As to Governments getting intermediate certs issued from CA's in our trust domain, despite a paper claiming this as a possibility, we have seen no evidence of this in the wild. If we had such evidence, it would behoove us to publish it, as well as look at appropriate responses to any CA in our trust store that issued such a certificate. bob
> Governments getting intermediate certs issued from CA's in our trust > domain, ... we have seen no evidence of this in the wild. We have many governments (from many countries) directly as our root CAs: - Taiwan Government Root Certificate Authority (Taiwan) - Hongkong Post (China) - Staat der Nederlanden (Netherlands) - VeriSign (subsidary of US dept of commerce / NTIA ;-) ) - Something unreadable from Turkey As I said, these boxes are sold, very concretely, to governments, including the US.
See also bug 471798, "need UI to warn if SSL cert changed".
Assignee: kaie → nobody
All those who perpetuate the "self-signed = bad, signed-by-some-intermediary-CA-rooted-in-a-Mozilla-accredited-CA = good" mantra in one form or the other might want to have a close look at EFF's "SSLiverse": * http://www.eff.org/observatory * http://www.eff.org/files/DefconSSLiverse.pdf
"There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files. This book is about the latter." -- Bruce Schneier, "Applied Cryptography" Compare comment 32. (Sorry for the advocacy, just ran across this quote.)
We have no plans to implement this at this time.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Well, security warning about changing certificates would be really useful. No plans? In these days, when browsers "slowly" removing not trusted authorities? So generally when some CA issue certificate for my domains and someone does MITM and replace my certs with them, how will I get this information?
Presenting SSL/TLS/CA/Cert information to end users is very hard, most people do not understand then, and even checking CA continuity for the end user is hard, as sometimes sites do change CA. So this is basically something for advanced users... I used firefox add-on "Certificate patrol" (http://patrol.psyced.org/) and i think that "certificate watch" (https://certwatch.simos.info/) can also do CA continuity tracking... but be ready for some pop-ups. Now i use perspectives (https://addons.mozilla.org/en-US/firefox/addon/perspectives/ ), as it checks the received site cert against the external notary servers, a more silent and transparent way to verify the certs... bad sadly is somewhat slow, several of the notary servers and you have to train your self to check its status (also add more servers, like https://yanovich.net/notary.php to extend the few original servers)
No longer depends on: 399910
You need to log in before you can comment on or make changes to this bug.