Re: Full Disclosure!
Eddy Nigg wrote: So IMO you get points for prompt disclosure and fixes, but in the end you messed up just like Comodo and CertStar did. Nonono :-) I see the main differences as followed and I believe the main differences are policy wise (and allow me to comment on this since you made the comparison). Eddy: I don't think Frank is saying that you made the _same_ mistakes as CertStar (out-sourcing validation etc. etc.), but that you made _a_mistake_, just like they did. He then goes on to make the point that making a mistake is not the end of the world. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Eddy Nigg wrote: On 01/03/2009 05:38 AM, Eddy Nigg: Before anybody else does, I prefer from posting it myself :-) http://blog.phishme.com/2009/01/nobody-is-perfect/ http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html For the interested, StartCom is currently checking if I can release our internal critical event report of this event to the public (there might be some internal information which should not be disclosed). The report is available from here: https://blog.startcom.org/?p=161 (I'm continuing going back through old threads, including reading the messages in this one I hadn't previously read. My apologies for being somewhat abbreviated in my comments, and for not responding to every point raised; I thought it was more important that I get my thoughts out there and close out these issues, rather than wait for time I won't have to do longer posts.) My overall comments: 1. I appreciate your being proactive in posting about the StartCom problems that were discovered and getting them fixed in a timely manner. I wish more CAs would be more forthcoming about things like this. 2. I understand that what happened in the case of StartCom was not exactly the same as what happened in the case of Comodo/CertStar. However it's part of web security basics to assume that whatever a client sends to a server is untrusted and must be (re)verified on the server side to forestall potential attacks (e.g., SQL injection, etc.) So IMO you get points for prompt disclosure and fixes, but in the end you messed up just like Comodo and CertStar did. 3. To paraphrase what Nelson (?) wrote, bugs happen. I don't think the PKI/CA system is so fragile that it necessarily comes tumbling down whenever a CA or RA makes a mistake. (If it really is that fragile then we have bigger problems than those we're discussing here.) From a policy point of view I think our interest is having CAs acknowledge problems and fix them in a timely manner, both in terms of revoking certs when needed and also in terms of addressing any underlying root causes. 4. In line with the previous point, I am not planning to recommend removal of StartCom's root over this incident, both because the issue been addressed by StartCom and also because it appears to be an isolated incident that does not indicate any larger problem of incompetence or maliciousness. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/05/2009 06:44 PM, Paul Hoffman: At 6:08 PM +0200 1/5/09, Eddy Nigg wrote: Therefor we can't lump just all failures together and as you correctly stated, there is no clear line between one and the other. This is what I was saying. What you said was As I see it, our case indeed was a bug, the Comodo case was negligence. That seems like you were making a pretty clear line. Are you now denying that you said it, or denying that there is a clear line between bugs and negligence? There may be a clear line between bugs and negligence, it doesn't have to be one however. A bug can be just a bug, but a bug also can be the result due to negligence...Concerning the former I already answered. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
At 6:08 PM +0200 1/5/09, Eddy Nigg wrote: Therefor we can't lump just all failures together and as you correctly stated, there is no clear line between one and the other. This is what I was saying. What you said was As I see it, our case indeed was a bug, the Comodo case was negligence. That seems like you were making a pretty clear line. Are you now denying that you said it, or denying that there is a clear line between bugs and negligence? At 2:56 PM + 1/5/09, Gervase Markham wrote: I am just saying that you cannot make such a division so quickly and easily. Sure he can: he does it all the time. :-) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/05/2009 04:56 PM, Gervase Markham: I am not saying the two incidents were the same - I think every incident has to be assessed individually. I am just saying that you cannot make such a division so quickly and easily. Not quickly and easily - agree on that. And every incident needs to assessed on its own merits, that's what I said too. Nelson suggested that both were just flaws and it sounded like it can be put to rest now. No excuses on having a flaw and StartCom treated the incident as a critical event which required full reporting on the events and its resolution. It was certainly not taken lightly even though the event itself was handled excellent (IMO) and the systems proved themselves to a great extend. However I'm very certain that flaws do happen here and elsewhere, just look at the critical bugs Firefox has every here and now, despite great QA and thousands of eyes looking at the code and testing. It matters what is done with it and how to prevent it if possible. Reporting, alertness and correct response is crucial too for such events. Now, this issue is quite different to that of Comodo, since StartCom has no stipulation for RAs. As a matter of fact I'm proposing to Comodo to perform domain and email validations by themselves, with being fully aware that flaws can happen even at their systems. The issue I'm seeing with Comodo is policy and implementation wise - besides the poor performance (or was it negligence?) of the certstar reseller. In that, both CAs differ greatly in many ways including the events themselves, reporting and their resolution. Therefor we can't lump just all failures together and as you correctly stated, there is no clear line between one and the other. This is what I was saying. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Eddy Nigg wrote: As I see it, our case indeed was a bug, the Comodo case was negligence. There is no clear line between one and the other. You are saying the Comodo case was negligence because the bug was so obvious that they should have spotted it. But the obviousness of bugs is a gradated scale. If the flaw in the Startcom system might have been found by employing an experienced web app white hat hacker, does that make it negligence for you not to have done so? I am not saying the two incidents were the same - I think every incident has to be assessed individually. I am just saying that you cannot make such a division so quickly and easily. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to split this list (was: Re: Full Disclosure!)
On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman phoff...@proper.com wrote: I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The topics for that list would include: - All new trust anchors being added to the Mozilla trust anchor pile - Proposals for changes to the Mozilla trust anchor policy - Complaints about particular participants in the current trust anchor pile - Discussion of the UI aspects of the PKI in various Mozilla software The first three topics are appropriate for the proposed new mailing list. (I would use root CAs instead of trust anchors in the mailing list's name because trust anchors sounds a little too technical.) The fourth topic is not related to trust anchor policy. So I'd propose that it stay in this mailing list even though it is not strictly speaking related to crypto either. I'm reading this mailing list using a mail program that supports threaded discussions, so all the discussions about root CAs don't prevent me from answering the real crypto questions. I don't need the proposed new mailing list, but I don't object to it either. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to split this list (was: Re: Full Disclosure!)
At 1:35 PM -0800 1/5/09, Wan-Teh Chang wrote: On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman phoff...@proper.com wrote: I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The topics for that list would include: - All new trust anchors being added to the Mozilla trust anchor pile - Proposals for changes to the Mozilla trust anchor policy - Complaints about particular participants in the current trust anchor pile - Discussion of the UI aspects of the PKI in various Mozilla software The first three topics are appropriate for the proposed new mailing list. (I would use root CAs instead of trust anchors in the mailing list's name because trust anchors sounds a little too technical.) I beg to differ here. There has been a lot of discussion of allowing people to add self-signed certs that are not CAs to their list of trusted CAs. Those would be roots, but they would not be CAs. They are, in fact, trust anchors. The fourth topic is not related to trust anchor policy. Somewhat true, but they are a direct outgrowth of it. Note that I said the UI aspects of the PKI, not the UI aspects of security. So I'd propose that it stay in this mailing list even though it is not strictly speaking related to crypto either. It is far less related to crypto than it is to trust anchor policy. I'm reading this mailing list using a mail program that supports threaded discussions, so all the discussions about root CAs don't prevent me from answering the real crypto questions. I don't need the proposed new mailing list, but I don't object to it either. You are missing the parts where there are actual technical questions or assertions in the middle of threads that started as trust anchor rants. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Proposal to split this list (was: Re: Full Disclosure!)
At 12:11 AM +0100 1/4/09, Jan Schejbal wrote: Why is this relevant to this mailing list? Because there was a security failure in one of the Firefox trusted CAs allowing anyone to get fake certificates. This event and the reaction of the CA are important to determine if the CA is (still) trustworthy. It's the same as the Commodo thing. Just with a way better reaction and without the dodgy background of dozens of resellers doing (or, in at least one case, not doing) the Domain Verification. Sorry, but I don't see that listed as a topic for discussion on the mailing list's information page https://lists.mozilla.org/listinfo/dev-tech-crypto. I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The topics for that list would include: - All new trust anchors being added to the Mozilla trust anchor pile - Proposals for changes to the Mozilla trust anchor policy - Complaints about particular participants in the current trust anchor pile - Discussion of the UI aspects of the PKI in various Mozilla software Topics that would still be germane for dev-tech-crypto would include - Questions on how to add or remove trust anchors from various Mozilla software (without any discussion of why someone wants to do it) - Discussion of how to implement alternate UI schemes for PKI (that is, what hooks are available in NSS for detecting positive and negative results) All of Eddy's recent threads (being slimed by a Comodo reseller, finding a reseller that doesn't do domain validation, advertising that he had a domain validation bug but fixed it) would all be appropriate on the new list. The current list is way too unfocused. People asking actual tech questions get drowned out by threads that have literally nothing to do with crypto but everything to do with policy. Thoughts? --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 3/1/09 04:38, Eddy Nigg wrote: Before anybody else does, I prefer from posting it myself :-) http://blog.phishme.com/2009/01/nobody-is-perfect/ http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html For the interested, StartCom is currently checking if I can release our internal critical event report of this event to the public (there might be some internal information which should not be disclosed). Leaving aside the details of this disclosed exploit demo ... and with a nod to the benefit to the community of such a disclosure ... it is useful to examine the MOTIVE for doing this. What incentive exists for a CA in disclosing an apparent weakness? * In the open source world, we would say, the code is there for us to share and improve the code, and the weaknesses are, as a consequence of the model, revealed. In the open source world, we grasp this nettle and turn it into an advantage. * But in the closed source world, other dynamics work. A seller of proprietary product will suppress any report of weakness, as this will cause the buying public to become suspicious, and buy some other supplier's product. We've seen both sides over the last 2-3 weeks. So I guess there are two questions: 1. do we want to live in the world of open disclosure, or the world of pretty facades? 2. if the former, how do we create the incentives such that all prefer to disclose up front? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/03/2009 04:43 PM, Ian G: What incentive exists for a CA in disclosing an apparent weakness? Quite frankly, none. We've seen both sides over the last 2-3 weeks. Not entirely correct...but... So I guess there are two questions: 1. do we want to live in the world of open disclosure, or the world of pretty facades? 2. if the former, how do we create the incentives such that all prefer to disclose up front? ...I wouldn't be willing to disclose each and every detail of code, preventive measures, controls and procedures and possible events. But since there was not much to hide anymore from our incident and the cat is out of the bag anyway and since the event has been dealt with correctly IMO and the vulnerability neutralized, there was no problem providing now some details about it. Better than have rumors and people guessing... However depending on the severity, reporting and disclosing is not a privilege. But I'm not sure if it can be enforced. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 1/3/2009 6:43 AM, Ian G wrote: On 3/1/09 04:38, Eddy Nigg wrote: Before anybody else does, I prefer from posting it myself :-) http://blog.phishme.com/2009/01/nobody-is-perfect/ http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html For the interested, StartCom is currently checking if I can release our internal critical event report of this event to the public (there might be some internal information which should not be disclosed). Leaving aside the details of this disclosed exploit demo ... and with a nod to the benefit to the community of such a disclosure ... it is useful to examine the MOTIVE for doing this. What incentive exists for a CA in disclosing an apparent weakness? * In the open source world, we would say, the code is there for us to share and improve the code, and the weaknesses are, as a consequence of the model, revealed. In the open source world, we grasp this nettle and turn it into an advantage. * But in the closed source world, other dynamics work. A seller of proprietary product will suppress any report of weakness, as this will cause the buying public to become suspicious, and buy some other supplier's product. We've seen both sides over the last 2-3 weeks. So I guess there are two questions: 1. do we want to live in the world of open disclosure, or the world of pretty facades? 2. if the former, how do we create the incentives such that all prefer to disclose up front? To a large extent, I addressed this issue from the standpoint of an outsider discovering a problem more than three years ago in my http://www.rossde.com/editorials/edtl_shootmsngr.html. See also my http://www.rossde.com/editorials/CalOaksBank.html (two years ago) for a comparison of going public versus staying private when an outsider discovers such a problem. -- David E. Ross http://www.rossde.com/ Q: What's a President Bush cocktail? A: Business on the rocks. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Why is this relevant to this mailing list? --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 03.01.2009 07:18, Eddy Nigg wrote: The validations wizard allows for a selection of a few possible email addresses considered for administrative purpose or as listed in the whois records of the domain name. The flaw was, that insufficient verification of the response at the server side was performed, allowing him to validate the domain by using a different email address than the validations wizard actually provided. Ah, I see. (no information follows, just opinion) Yes, that is (just?) a bug. It does mean that a developer didn't think correctly - it's a general rule in security to validate all input, distrust all other parties, and this was not done here. I'd check similar code near there, and the other code of that developer, but IIRC you wrote that you did that at least to some degree and rectified other potential problems. I was already scared that you let the user's browser do the domain validation, and let the browser report yes, the verification passed, or something like that. Yes, that would have been incredibily stupid, but given what we learned recently about some other CAs... This bug is not too far from that, but at least not that obviously stupid, it can really have been just an oversight of the developer in question, and his reviewer. Ben ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Paul Hoffman wrote: Why is this relevant to this mailing list? Doesn't it go along with the other are CA's trustworthy? threads? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Eddy Nigg wrote, On 2009-01-02 22:18: The attack was performed by using said tool above or by using a modified version of the browser. By hooking this tool between the server and browser, the tool allows to change the values coming to and from the browser. I hate to say it, but it's possible for the browser user to change those values without either (a) modifying the browser or (b) using some proxy tool. So let me ask: Did Mike Zusman confirm that he was using such a tool? Or is that merely an assumption? With it, he was able to change some values send during the post response to that of his liking. The validations wizard allows for a selection of a few possible email addresses considered for administrative purpose or as listed in the whois records of the domain name. The flaw was, that insufficient verification of the response at the server side was performed, allowing him to validate the domain by using a different email address than the validations wizard actually provided. The value of the selection was changed during transit after performing the selection at the browser. But that server input verification flaw is fixed now, right? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/03/2009 09:03 PM, Nelson B Bolyard: I hate to say it, but it's possible for the browser user to change those values without either (a) modifying the browser or (b) using some proxy tool. I don't know another way, but I'm glad to learn how. So let me ask: Did Mike Zusman confirm that he was using such a tool? Yes But that server input verification flaw is fixed now, right? Correct, as also stated in the event report. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 03.01.2009 20:01, Eddy Nigg wrote: the other layers of defense Please don't call the blacklist a real layer of defense. If he didn't try to get a cert for paypal.com, it would have worked. All layers failed. Please be honest enough to yourself to admit that, so that you can try to find new layers or checks. the attacker was banned from the StartCom network FWIW, I think it's a bit overreaction to immediately revoke *all* his certs. The staff has reacted incredible fast and awareness high as well. Yes, that surprised me, too. Even during the day, it was fairly fast. But it in the middle of the night (midnight and later), right? The times were local time (Israel) or UTC? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 03.01.2009 20:03, Eddy Nigg wrote: On 01/03/2009 09:03 PM, Nelson B Bolyard: I hate to say it, but it's possible for the browser user to change those values without either (a) modifying the browser or (b) using some proxy tool. I don't know another way, but I'm glad to learn how. You can pretent to be a browser and do it by hand. We regularly do that when we alter Google query URLs. Modifying a POST is a bit harder, but not much different conceptually. I'm sure you use cookies and stuff, but that's not hard either (see wget etc., I can even do it in telnet). If you use JS to verify that it's a browser, that's kind of silly and locks some users out. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/03/2009 10:03 PM, Ben Bucksch: On 03.01.2009 20:01, Eddy Nigg wrote: the other layers of defense Please don't call the blacklist a real layer of defense. If he didn't try to get a cert for paypal.com, it would have worked. All layers failed. Please be honest enough to yourself to admit that, so that you can try to find new layers or checks. How can you say that? First of all it was a certificate for verisign and not paypal, even though he could have tried it too (and failed). Neither it's a black-list per se, but a quite intelligent flagging and review system. It's one of the layers of defense... ...if you remember the phishing attempt made on some small American financial institute with a cert from GeoTrust. Our flagging system was greatly improved as a direct result from what we learned from that event. That is, not only defense from a bug, but also from attempts similar to the one just mentioned. It includes of course high-profile targets but not only. The only alternative would be manual verification of each and every certificate, which in my opinion isn't very efficient for domain validation. But for comparison, where was the layer of defense at the other recent event? A black-list could have prevented that, don't you think? FWIW, I think it's a bit overreaction to immediately revoke *all* his certs. Well, those were exactly two. It was the correct response. The staff has reacted incredible fast and awareness high as well. Yes, that surprised me, too. Even during the day, it was fairly fast. But it in the middle of the night (midnight and later), right? The times were local time (Israel) or UTC? Yes, local time. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Eddy Nigg wrote, On 2009-01-02 22:18: [...] The flaw was, that insufficient verification of the response at the server side was performed, allowing him to validate the domain by using a different email address than the validations wizard actually provided. [...] Additionally all steps of the subscribers are always logged (yes, every click of it) and we have records about every validation and about which email address was used for it, failed attempts etc. With those records could we re-validate all certificates very quickly. Do your records include the email addresses that were actually used by your servers in the course of validation? Can you search those records to see if any other certs were ever issued after using an email address that was a different email address than the validations wizard actually provided ? I think a check of that magnitude is an appropriate response to this event. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/03/2009 11:33 PM, Nelson B Bolyard: Additionally all steps of the subscribers are always logged (yes, every click of it) and we have records about every validation and about which email address was used for it, failed attempts etc. With those records could we re-validate all certificates very quickly. Do your records include the email addresses that were actually used by your servers in the course of validation? Yes. That was also the reason why we could pinpoint the attempt as fraudulent within almost seconds...as such, we wouldn't prevent Verisign from getting a cert from us and/or test our systems if the request is legitimate. Can you search those records to see if any other certs were ever issued after using an email address that was a different email address than the validations wizard actually provided ? Yes. I think a check of that magnitude is an appropriate response to this event. This is exactly what we did. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Eddy Nigg wrote, On 2009-01-03 11:03: On 01/03/2009 09:03 PM, Nelson B Bolyard: I hate to say it, but it's possible for the browser user to change those values without either (a) modifying the browser or (b) using some proxy tool. I don't know another way, but I'm glad to learn how. It's pretty easy to alter a downloaded form by saving the page containing that form to a local file (File-Save Page as), then edit the file, then use a file:// URL to visit the edited file and continue the session with the edited form. There are countermeasures and counter-counter measures to this sort of thing. There are still other ways to achieve this. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/03/2009 11:54 PM, Nelson B Bolyard: Eddy Nigg wrote, On 2009-01-03 11:03: On 01/03/2009 09:03 PM, Nelson B Bolyard: I hate to say it, but it's possible for the browser user to change those values without either (a) modifying the browser or (b) using some proxy tool. I don't know another way, but I'm glad to learn how. It's pretty easy to alter a downloaded form by saving the page containing that form to a local file (File-Save Page as), then edit the file, then use a file:// URL to visit the edited file and continue the session with the edited form. There are countermeasures and counter-counter measures to this sort of thing. There are still other ways to achieve this. Oh well, that wouldn't work to start with... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Eddy Nigg wrote, On 2009-01-03 13:38: On 01/03/2009 11:33 PM, Nelson B Bolyard: Additionally all steps of the subscribers are always logged (yes, every click of it) and we have records about every validation and about which email address was used for it, failed attempts etc. With those records could we re-validate all certificates very quickly. Do your records include the email addresses that were actually used by your servers in the course of validation? Yes. That was also the reason why we could pinpoint the attempt as fraudulent within almost seconds...as such, we wouldn't prevent Verisign from getting a cert from us and/or test our systems if the request is legitimate. Can you search those records to see if any other certs were ever issued after using an email address that was a different email address than the validations wizard actually provided ? Yes. I think a check of that magnitude is an appropriate response to this event. This is exactly what we did. That's good to read, Eddy. I had not understood that from your previous messages on this subject. Thank you for clearing that up for me. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Eddy Nigg wrote, On 2009-01-03 14:25: On 01/03/2009 11:54 PM, Nelson B Bolyard: Eddy Nigg wrote, On 2009-01-03 11:03: On 01/03/2009 09:03 PM, Nelson B Bolyard: I hate to say it, but it's possible for the browser user to change those values without either (a) modifying the browser or (b) using some proxy tool. I don't know another way, but I'm glad to learn how. It's pretty easy to alter a downloaded form by saving the page containing that form to a local file (File-Save Page as), then edit the file, then use a file:// URL to visit the edited file and continue the session with the edited form. There are countermeasures and counter-counter measures to this sort of thing. There are still other ways to achieve this. Oh well, that wouldn't work to start with... Because ? If you check the referrer URL, that can be faked, too. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/03/2009 11:59 PM, Nelson B Bolyard: As I understand it, Eddy, the situation with CertStar was a bug which caused the code to simply fail to invoke the facilities that do the DV validation (or verification, or whatever the right term is for that). If that were correct, just a walk-through without further testing would have revealed that. That's not even called debugging, that's a check one does to see if the program works at all. Additionally, I'm not even blaming certstar for this, the failure is clearly that of Comodo. Would they have taken out one certificate from them, they would have found that something important is missing. The input, which was the DNS name that should have been validated, wasn't checked. As I understand it based on messages I have read, the facilities existed to do the check, but a small bug kept them from being invoked, a small bug that was (reportedly) easily and quickly fixed. Both assumptions are in my opinion incorrect, as for days later on somebody from Mozilla could still see the renew pages. I've made a screen shot of that one too. In StartCom's case, likewise, an important input was not checked. It was the email address to be used, rather than the DNS name, that wasn't checked. Not entirely correct, but similar. But either way, the result was that a check was not performed, and consequently, a cert was issued for a domain name that was not properly under the control of the party to whom it was issued. Thus, these two events appear to me to be failings of a comparable magnitude. Yes. But with all due respect the result of both events is quite different. It's true that exploiting one of these required a little more work on the part of the attacker than the other. One required nothing more than that the attacker type in the DNS name he did not control, while the other required that the attacker alter the form to make it include an email address that had not been present as received from the CA/RA, but both are well within the scope of things that most serious attackers can readily do, as recent events have shown. It required to proxy the all responses from and to the server. A simple form as you suggest wouldn't work. Both of these bugs might have been, but were not, detected until a researcher/attacker found them and reported them. Wrong! We (the system actually did) detected and took active actions within less then ten minutes. Theirs came after more then three hours and only after posting to this list. I think that there is a clear difference, both in the protection of preventing the higher value certificate which wasn't issued (same would have been true for many other high-profile sites including Mozilla) and in the overall response immediately thereafter. I have no evidence that either failing was intentional. They were just bugs. As I see it, our case indeed was a bug, the Comodo case was negligence. One was perhaps less obvious than the other, but both had consequences that were of potentially of similar magnitude, IMO. I think the constellation and policies are inherently different between Comodo and StartCom. It's not by chance that StartCom doesn't have a stipulation for RAs. Many other policy decisions and implementations are entirely different (intentional). May I quote Mike Zusman: But, there are at least two types of CAs. One type treats SSL certificates as a cash cow, pushing signed certificates out the door, and counting the money. The second type is like StartCom. This second type understands that trust comes before money and that trusted CAs are a critical piece of Internet infrastructure. If you don't see the difference between both events I can't help you (and I'm not talking about the money stuff he mentioned). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
Why is this relevant to this mailing list? Because there was a security failure in one of the Firefox trusted CAs allowing anyone to get fake certificates. This event and the reaction of the CA are important to determine if the CA is (still) trustworthy. It's the same as the Commodo thing. Just with a way better reaction and without the dodgy background of dozens of resellers doing (or, in at least one case, not doing) the Domain Verification. Greetings Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention FROM NG in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers... ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/03/2009 05:38 AM, Eddy Nigg: Before anybody else does, I prefer from posting it myself :-) http://blog.phishme.com/2009/01/nobody-is-perfect/ http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html For the interested, StartCom is currently checking if I can release our internal critical event report of this event to the public (there might be some internal information which should not be disclosed). The report is available from here: https://blog.startcom.org/?p=161 -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 03.01.2009 04:59, Eddy Nigg wrote: The report is available from here: https://blog.startcom.org/?p=161 That's surely interesting, but the report does not contain any details of interest. It only says The attack ... involved proxying ,intercepting all communication from and to the browser and eventually modification of the browser response to the server. A tool like http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project was used for the attack. That's all it says about the problem. Which tells me nothing, other than that the *user*s browser might have been involved in some critical verification steps. Other info; Only low-assurance Class 1 certificates were involved. He passed all your tests and you only noticed, because he tried to get a cert for verisign/paypal.com, which are on your blacklist. While that's a good idea, it obviously wouldn't have prevented registration of other targets. So, what really happened and why? How is the browser any relevant in the verification steps? Ben ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Full Disclosure!
On 01/03/2009 07:31 AM, Ben Bucksch: On 03.01.2009 04:59, Eddy Nigg wrote: The report is available from here: https://blog.startcom.org/?p=161 That's surely interesting, but the report does not contain any details of interest. It only says The attack ... involved proxying ,intercepting all communication from and to the browser and eventually modification of the browser response to the server. A tool like http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project was used for the attack. That's all it says about the problem. Which tells me nothing, other than that the *user*s browser might have been involved in some critical verification steps. Other info; Only low-assurance Class 1 certificates were involved. He passed all your tests and you only noticed, because he tried to get a cert for verisign/paypal.com, which are on your blacklist. While that's a good idea, it obviously wouldn't have prevented registration of other targets. So, what really happened and why? How is the browser any relevant in the verification steps? I can give some more information on this. This attack is perhaps trivial for a hacker, it's maybe not overly obvious. In this respect, we actually have more protections in place and attacks are anticipated to DNS and mail servers, but also otherwise to the web interfaces. That's because as I also said previously, bugs do happen as many developers here can confirm. The attack was foiled by the assumption that it must have some value for the attacker and that attackers usually make at some point a mistake. This is not the first time attempts to circumvent our various procedures happened, it's however the first time somebody actually succeeded to some degree. Another word before disclosing some more. You and also Mike Zusman asked in his article what would have happened to smaller targets. Rightly, unknown sites are not equally protected as high-profile targets. However, StartCom has a responsible policy in place which disallows wild cards and multiple domains in the Class 1 settings, prevents other possible misleading issuance such as paypa1.com or micr0soft.com just to mention a few, financial institutions must provide identity documents and most important, certificates are valid for one year only - no matter which validation level the subscriber enjoys. Manual verifications are also performed on an ongoing basis. With this we try to counter some misuse as well. The attack was performed by using said tool above or by using a modified version of the browser. By hooking this tool between the server and browser, the tool allows to change the values coming to and from the browser. With it, he was able to change some values send during the post response to that of his liking. The validations wizard allows for a selection of a few possible email addresses considered for administrative purpose or as listed in the whois records of the domain name. The flaw was, that insufficient verification of the response at the server side was performed, allowing him to validate the domain by using a different email address than the validations wizard actually provided. The value of the selection was changed during transit after performing the selection at the browser. Hope that clarifies the details which aren't outlined in the report. Additionally all steps of the subscribers are always logged (yes, every click of it) and we have records about every validation and about which email address was used for it, failed attempts etc. With those records could we re-validate all certificates very quickly. The only ones which failed were those of domains which retired. Expired certificates were not tested. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Full-disclosure] Firefox 2.0.x: tracking unsuspecting users using TLS client certificates
... I realised that you can do something with Firefox 2.0.x that you could not do with Firefox 1.5.x: track an unsuspecting user using TLS client certificates. this is not new. in a way it has been in the apache documentation for years. it simple, and it's very bad: a) firefox does not ask the user which certificate to deliver if not set up to do so. b) firefox does not offer a checkbox to remember the choice the user made. the irritating dialogue will appear up to two times for each webpage and not stay activated for long. (konqueror in comparison does remember the user's choice for each domain/site. k. doesn't send out certficates without being told to.) c) in the apache documentation you can read about a simple setupwhich asks for and accepts ANY certificate that the browser delivers - which leaves the choice to the browser and makes it deliver one _silently_ if present. (IIRC the choice is usually made by comparing certain fields in the certificate, e.g. company, common name etc. the certficate that matches best will be sent. though the server certificate's CN must be * or match the domain to be accepted, FF does not require any information from the client certificate to match the domain it is sent to.) you want to make use of that? very simple: 1) all information from the client certificate can of course be read by the server, e.g. in a CGI. 2) though you could achieve this easily (contrary to statements on the list my FF never required client certificates to be signed by a known CA - why should it?), you do not have to make users actually install a certificate. would be too obvoius anyway, and... ...users who are part of a company network or any other organization which uses certificate authentication will already have one. they are very concerned about security, so they are probably more interesting targets anyway. 3) for tracking purposes just remember the fingerprint of ANY delivered client certificate. combine it with any other information information you get from the now perfectly identified client, like IP-address, information filled into forms, etc. 4a) simple tracking of a certficate holder might be nice for secret services and adserver owners, but as companies like to have their own CA or at least write the company name into the certificates, competitors can see easily who's clicking. 4b) if you are a spammer the valid e-mail-address stored in the certificate might be of some value. 4c) the common name field is great information for phishers and all kinds of evildoers who are now empowered to create individualized mails with this information. n. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
