Re: OCSP bypass in recent demo/exploit
Looking at the http://www.win.tue.nl/hashclash/rogue-ca/ attack specifically... The Equifax Secure Global eBusiness CA-1 self-signed Root Certificate trust anchor does *not* contain the Authority Info Access extension or CRL Distribution Points extension. The Rogue CA Certificate does *not* contain the Authority Info Access extension or CRL Distribution Points extension. (The legitimate certificate that has the same signature as the Rogue CA Certificate does contain the CRL Distribution Points extension, but that's irrelevant). So, with zero potentially suitable CRL/OCSP URLs available, this surely means that that Rogue CA Certificate is essentially *unrevokable* by normal means, and that any certificates issued by the Rogue CA Certificate are essentially *unrevokable* by anyone other than the attacker. The CA (RapidSSL) could have thwarted the attack by using a stronger hash algorithm, or by generating random certificate serial numbers instead of guessable sequential ones. I think it's sensible to expect this attack on MD5 to be repeated by other attackers, and to expect a similar attack on SHA-1 in the future. Therefore, we should consider putting in place some safeguards now. Some ideas: Perhaps the Mozilla CA Certificate Policy could mandate that all CAs must (after a certain date) generate long, randomized certificate serial numbers? Perhaps the NSS code could reject (after a certain date) certificates with short serial numbers, on the assumption that they are sequential and therefore potentially guessable? (Perhaps future updates to RFC5280 and the CABForum EV Guidelines could recommend or require long, randomized certificate serial numbers as well?) On Tuesday 06 January 2009 01:31:55 Paul Hoffman wrote: At 4:01 PM -0800 1/5/09, Nelson B Bolyard wrote: Paul Hoffman wrote, On 2009-01-05 08:54: At 3:09 PM +0100 1/5/09, Ian G wrote: [...] Hence, once we rogue-players have created a certificate like this, the CA cannot revoke it using its own control mechanisms. [...] I am not convinced the article is correct. If it is correct, it is a serious but easily-fixed bug in IE. That is, if a trust anchor contains a AIA that points to an OCSP responder, and the rogue sub-CA has an AIA that points to a different OCSP responder, the validation process should should check the OCSP of the trust anchor. I'm surprised that you wrote that, for several reasons. Let me explain some of them. For brevity, I will use the following terms: child - the cert whose revocation we want to check parent - the cert for the CA that issued the child cert sibling - another cert issued by the same parent CA grandparent - the cert for the issuer of the parent cert. Everything I write below about OCSP is also true for CRLs, IINM. 1) It's not generally true that you can use the OCSP URL in the parent cert to check the OCSP status of a child cert. This is because it is not generally the case that the issuer of the child is also the issuer of the parent (that is, that parent == grandparent, parent is a root). 2) It's also not generally true that you can use the OCSP URL in a sibling to check the OCSP status of a child. This is because the parent may have multiple OCSP responders and may use different responders for different certs that it issues. Indeed, the parent could put a unique OCSP URL into every cert it issues. 3) A corollary of (2): Even when parent == grandparent, and hence parent is also a sibling, it's not generally true that you can use the OCSP URL from the parent to check the OCSP status of a child. All of that is true (and is true for CRLs, I believe), but it is not what I was speaking to. The recent MD5 attack creates a rogue sub-CA, that is a new child of one of your trust anchors. The Microsoft article made it sound (to me, at least) that if the rogue sub-CA (the child) has a AIA, then IE will not look in the parent's AIA to determine the status of the child. If that's true, it is broken. Each level of the family can have its own AIA that applies to all of its children, not just to end entities. 4) Trust anchors are not necessarily roots. Of course. I'm not seeing where that is relevant here, but I could be missing something. 5) Most roots don't have AIA cert extensions. Only 8 out of the 125 roots in nssckbi have them. Now *that* is sad. I was hoping for closer to 50%. It does not make my argument wrong, just pretty moot. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford
Re: PositiveSSL is not valid for browsers
On 5/1/09 22:16, Nelson B Bolyard wrote: Ian G wrote, On 2009-01-05 11:28: We know as a more or less accepted fact that the design of secure browsing was for Credit Cards, I believe that you've accepted that as fact. But PR and marketing is not design. It was designed for MUCH more than mere credit cards. So, perhaps one group of people said one thing, another said another thing. First question is, what's our reference here? What standard, designed for whom? Can we pick one and stick to it? The original question was, can we set up different price points and/or security models for certs: IV, OV, DV, AV, EV, etc. As we can't even agree on who these things are designed to protect, and as they were never asked, it seems that there can be no objection to variations in them? (Protecting everyone from everything is a non-starter.) and the benefit there is solely for CC vendors, not consumers, because the consumers are already covered by the $50 liability limit. They never had any real concern whatsoever that anyone was reading their cc numbers.) Only in the USA is that even close to true. Well, to some extent, only the USA market was important in the early design of the *commerce* parts of the web. Also, IIRC, it was true in Australia and Britain. In Europe it wasn't such a big issue because credit cards weren't that important. (Even today, they aren't as important, as direct debit is far more important, which has a different liability arrangement, and wasn't relevant for the original market. One could argue they are now relevant today, but that would just add gasoline to the fire.) And even in the USA, the damage caused by a stolen credit card is far broader than whatever monetary value the thief got with the stolen number. That's the point. It was to the benefit of others than consumers. Or if it was to the benefity of the consumers, what was it that was on offer? Refund of the $50? But that's somewhat moot because CCs are NOT and never were the sole reason for the design of SSL. (Did you read what I previously wrote about SSL vs SET?) OK, and that somewhat backs up my point. We are talking about consumers here. Consumers were told what they needed it for. They needed it for credit cards, right? That's what they were told, way back when. Now they are being told the need EV for online commerce. The point being that the user is and was never consulted in this conversation. Which is why there is no feedback from the market. Which is why we can do anything we like, and then create the user message. Or? E.g., these messages from a couple of well known security commentators: http://news.cnet.com/8301-1009_3-10129693-83.html == In an interview on Tuesday morning, cryptography expert Bruce Schneier praised the research but downplayed the real-world consequences of the findings. SSL protects data in transit but the problem isn't eavesdropping on the transmission. Someone can steal the credit card on some server somewhere. The real risk is data in storage. SSL protects against the wrong problem, he said. This is good work, great cryptography. I love the research, but this doesn't matter a whit, Schneier added. There are half a dozen ways to forge certificates and nobody checks them anyway. Paul Kocher, president of Cryptography Research and an architect of the SSL 3.0 protocol, said the exploit highlights the need for a new universal hash function that everyone is comfortable with. The paper is not a surprise, but at the same time it's the crispest demonstration for why it's necessary to remove this broken algorithm everywhere it is being used, he said, before adding there are bigger things to worry about, like browser bugs and operating security bugs. === iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PositiveSSL is not valid for browsers
On 6/1/09 05:39, Kyle Hamilton wrote: ... since the policies of Mozilla's root program maintain the requirements imposed by ANSI X9 *for financial certification authorities*. Er, they do? Where is that? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: OCSP bypass in recent demo/exploit
Is there any way I can suck back the last two messages I sent on this thread and pretend they never happened? sigh I guess not. Please ignore my assertions about what the AIA extension does: I was completely wrong. As we were making the AIA extension in the PKIX WG, we discussed multiple proposals, and I quite frankly forgot which one won. The AIA extension, using id-ad-ocsp, tells where to find the OCSP responder that will tell you about *this* certificate, not the certificates issued by this CA (if it the extension is in a CA certificate). We never did standardize an extension that says if you see this in a CA cert and you want to know where to find my OSCP server, it is over *here*. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On Dec 25 2008, 12:36 am, Kyle Hamilton aerow...@gmail.com wrote: To be honest, Mozilla doesn't distribute keytool with Firefox, which means that I have to try to go into the (unbatchable) interface this is false. the ui is built as xul with js bindings to c++ objects which use idl to expose methods. the js *script* which controls the user interface itself is essentially batching orders. you're free to batch this as much as you please. remove the flags one. by. one. by. one. and then select the next certificate and remove those trust flags, and the next, and the next, and the next... ...for all hundred or so certs that Firefox includes. i've done this something like half a dozen times using a nokia n800 (or was it a nokia 770) with the built in certificate manager. Which is worse by far than the one mozilla ships. You almost have my sympathy. Except for a few details: 1. i've been working w/ the nokia ui people + engineers to improve their mess (i thought I had succeeded in burying their ui, but it seems rumors of its demise were greatly exagerated). 2. i've been working to improve the mozilla ui (by writing patches) what have you done? And then, once I DO manage to do that, then with the new and improved user interface updates, I then have to click at least six times to try to figure out what's going on, and then when I do find a site that's protected by an unknown CA certificate (OR that I've removed the trust bits on), again, i've filed bugs and am working to improve this. what have you done? I have to do the following: 1) Click 'add an exception' 2) click 'get certificate' (why I should have to do this is beyond me, since firefox obviously already has the certificate downloaded since it told me 'sec_error_untrusted_issuer', which it couldn't have known without the certificate in its possession ANYWAY) i believe this is partly to force users (not you, real normal people) to think before they blindly add issuers. There's a public bug evidencing that normal users might actually add trust to every site they encounter (because they're on an evil hot spot which is spoofing everything). You're a (professed) expert, our target audience is the average person (described above), they experience for that person must be safe and slow. thinking is good. blindly clicking through is bad. if you're an expert, you can script pieces of this (heck, there's a pref to speed up the steps you're describing). 3) click 'view' 4) get the name of the Issuer 5) hope to all the gods that there's enough information in the chain to figure out what root it's supposed to be going to if there isn't, then you shouldn't be trusting it. heck. if there isn't, go try to find a phone number and get the web server operator to fix their server. -- and yes, i've done this, iirc it was last month, i got sun to fix one of their servers. 6) close the window 7) go into Preferences 8) click Advanced 9) click Encryption 10) click 'View Certificates' 11) Scroll through the list, with each click giving me approximately 0.6 useful results (given the preponderance of 'section headings by root owner', which by the way doesn't work at all with the Addtrust AB stuff since those are Comodo roots) i've written a patch to improve this ui (with an eye to making the n800 user experience better). 12) find the appropriate root and re-enable it for identification of websites this seems useless. w/ my patch you could search by any criteria. 13) refresh the page. How 'bout this, Nelson (and I invite Frank and the entire security UI team to do this, as well): YOU do it. Create a new profile and manually remove the trust on every CA. Then, browse around, and see which CAs are actually used by you in your day-to-day browsing, reenabling them manually (since you're trying to emulate not having keytool around). been there, done this. Furthermore, even when keytool IS available, it's entirely likely that its name conflicts with Java's keytool. (especially on Mac OSX.) it's called certutil. This is completely unworkable, and discourages users that want to from taking their security into their own hands. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
On Dec 31 2008, 12:28 am, Kyle Hamilton aerow...@gmail.com wrote: (note: unknown_issuer without talking at all about who the issuer claims to be you're missing a critical point: the issuer is something about which we know nothing. someone could claim issuer: GOD or issuer: POTUS or issuer: VeriSign. Without verifying the issuer, we can't and should neither attest to nor show it. And sadly, that's why it isn't shown. Now, we could perhaps show a fingerprint (minus the fact that MD5 is at risk), but I tried searching for some fingerprints and haven't gotten good hits. http://eklhad.net/linux/app/ssl-certs turns up for MD5 fingerprint searches, but nothing shows up for the sha1 fingerprint i checked. - the nss certutil code appears to be able to print sha1s too -- and being able to download a certificate and then accept it it's true we don't do particularly well with chains, however i've rarely seen a useful misconfigured server with a partial chain and a missing root. if someone provides me with such a service, i'll see about trying to improve the user experience -- note that i'd prefer to start with an instance of a real broken server, since otherwise it's fairly pointless, however i could do the work from an example. without having to see who it's issued by -- is a WTF WAS THE SECURITY TEAM THINK--WAIT, WAS THE SECURITY TEAM THINKING?? situation. they were thinking about it more than you were. calmer heads with more thought prevailed. and what's important is that when our users get angry or panic, we don't want them accidentally doing something they'll regret later. (hopefully you regret shouting in a public forum. personally i tend to regret each time i post anywhere.) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CABForum place in the world
On 2-Jan-09, at 2:00 AM, Ian G wrote: On 2/1/09 03:44, Kyle Hamilton wrote: If he's a security and user interface expert, why is the security UI so appallingly *bad*? Not answering for gerv, but I would say: he is the human shield, against all influences, inside and outside! He's only one guy, and he has the entire battle field to deal with. Every time he moves to the left, the right mobs him. Every time he moves to the right, the left undermines him. The result is bad, but it isn't his fault, it's the fault of the situation he is in. However, at least we have a result! Before he was there, the only thing we had was random experimentation (like Gerv's much missed yellow bar) and corporate denial of the issue. Hey Ian, I appreciate the understanding of the situation, but I'm not quite ready to call the job impossible just yet, despite the array of forces being very much as you describe them. I doubt it will surprise you to know that Kyle isn't the first person to throw such stones. What is comparatively rarer is helpful, balanced suggestions for moving forward. In the meantime though, it's worth remembering that Firefox 3.1, when it comes out, will have private browsing mode, better clear private data support, SSL errors that interrupt user workflow explicitly instead of being ignored away, anti-malware and anti-phishing protection, fewer You are submitting a search to Google useless dialog boxes, an identity indicator that actually calls out the names of CAs issuing certs, and a much better mixed mode detection story than we had a little while ago, among others. We are always short-staffed on this stuff though, so it's great to see people like Kyle eager to help. So Jon goes to CAB Forum with a mandate to speak for the end-users, without any input from Mozilla, the browser vendor? Obviously I'm there representing a browser, but Mozilla's interests tend to align with end users most of the time. We don't, for instance, have a profit motive creating potential conflicts of interest. To give you a somewhat recent example, we were strong proponents of mandatory OCSP support by 2010 because we think it's better for the health of the net to have high-availability revocation information available for high-assurance certs, despite the arguments from some quarters that it would be too costly to support on high- traffic sites. Johnathan --- Johnathan Nightingale Human Shield john...@mozilla.com ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Eddy Nigg wrote: On 12/27/2008 12:44 AM, Subrata Mazumdar: A related question: Is it possible to configure the NSS Soft-Token associated with the internal slot like smart-card based token so that the private key key cannot be exported out of the token? If not, would it be useful feature to support? Even in the token case, this is only true if the key was generated in the token. If 'key recovery' is turned on, NSS generates the key in softoken and writes it to the token (after wrapping it with the escrow key). So it turns out even with crmf, escrow does not happen quietly. If the CA requests a key be escrowed, the user is notified: http://mxr.mozilla.org/firefox/source/security/manager/ssl/src/nsCrypto.cpp#1905 bob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: OCSP bypass in recent demo/exploit
Paul,
Paul Hoffman wrote:
It seems to me also that a self-signed certificate marked as a trust anchor,
ie. a root, probably shouldn't have an AIA extension.
Wait. No kind of certificate is marked as a trust anchor. I assume you probably me
root as in a self-signed cert with the CA bit turned on.
I meant marked as a trust anchor in the NSS certificate database.
At least it wouldn't make much sense for it to point to any OCSP responder,
since the root cannot revoke itself - there is no one above the root to revoke
it.
Correct, but don't forget that the AIA has two uses. It is quite reasonable for
a root to have an AIA extension with id-ad-caIssuers.
I am aware of that, but I was thinking about it in the context of OCSP only.
Perhaps these are not really roots .
Tell that to VeriSign. Here is the dump of the extensions take from their cert
taken from the Firefox root pile:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
F1:5A:89:93:55:47:4B:BA:51:F5:4E:E0:CB:16:55:F4:D7:CC:38:67
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.6
CPS: https://www.verisign.com/rpa
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication,
Netscape Server Gated Crypto, Microsoft Server Gated Crypto
X509v3 Authority Key Identifier:
keyid:4E:43:C8:1D:76:EF:37:53:7A:4F:F2:58:6F:94:F3:38:E2:D5:BD:DF
Authority Information Access:
OCSP - URI:http://EVIntl-ocsp.verisign.com
CA Issuers - URI:http://EVIntl-aia.verisign.com/EVIntl2006.cer
1.3.6.1.5.5.7.1.12:
0_.].[0Y0W0U..image/gif0!0.0...+..k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
What was the subject and issuer for that certificate ? Was it self-issued ?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PositiveSSL is not valid for browsers
Ian G wrote: SSL protects data in transit but the problem isn't eavesdropping on the transmission. Someone can steal the credit card on some server somewhere. The real risk is data in storage. SSL protects against the wrong problem, he said. That's like saying No, no, mugging isn't a problem--the real money is in bank heists. You can't ignore one problem or the other. The paper is not a surprise, but at the same time it's the crispest demonstration for why it's necessary to remove this broken algorithm everywhere it is being used, he said, before adding there are bigger things to worry about, like browser bugs and operating security bugs. Absolutely. Let's plan to phase out support for MD5 and move on to bigger issues. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
