Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation
Daniel Veditz wrote: user_pref(capability.policy.default.Crypto.generateCRMFRequest, noAccess); That may work now, but capability control for individual DOM properties is gone in Firefox 3.1 betas for performance reasons. Dan, it's not a DOM property but a method of the Crypto object instead which gets blocked in this case - so your comment probably doesn't apply. I checked this configuration with both Firefox 3.1 (Beta) and trunk, where it worked as expected (throws an exception saying Permission denied for [...] to call method Crypto.generateCRMFRequest). Kaspar ___ 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 3/1/09 03:17, Nelson B Bolyard wrote: Ian G wrote, On 2009-01-02 01:28 PST: Lots of very small stores try to do the right thing and set up self-signed certs with their cousin or friend doing the website. They get their cousin or friend to set up a web site for them, because they don't know anything about web sites except that they must have one. Their cousin/friend tells them Your choices are to either pay $1000 per year for a certificate or else let me make you a certificate for free. He does not tell them you also have choices to get certs that will work in all browsers for less than $50/year, perhaps because he himself does not know that. Sure, there are thousands of stories. Once I did a very informal scan of credit card and FORM in google, and through some scratch calculations that something like 5% of merchants took credit card numbers through HTTP (unreliable, anecdotal number). Millions of stories :) Then they discover that nobody can use the site, the admin wants more money, [...] so they back off and use HTTP instead of HTTPS. Yes, I agree, that does happen. But the answer is not to use self-signed certs. It is to use cost effective CA issued certs. Unfortunately not. If that is the answer then we wouldn't permit self-signed certs at all. Old debate... We permit self-signed certs and we have forgotten to add convenient management of certs (KCM). But neither of us will win the debate today! Please be aware that this website is not fully protected with third party claims by Certification Authorities. You may not be talking to who you think you are talking to, be careful to check in other ways. The problem with that is that the average user has NO IDEA WHATEVER of any way to verify who he is talking to than to look at the CONTENT of the site, and see if it looks like the content he expects from the real site. So, he does that, and thinks that he has been careful, just as the suggested warning advises him, and he gets phished. It is probably an accepted fact that the user doesn't understand this OR ANY OTHER WORDS or any other actions that are required. The choice is between: a) including the user b) hiding it from the user Choose a or b. (And, consult your legal counsel about your choice.) Whatever you do, don't choose both. Right now, Mozilla is at both :) It includes the user sometimes (expects her to check the HTTPS display) but not other times (expects her not to do anything else). The choice between a and b probably rests on whether you want light security or strong security. If strong security, it has to be a., as from the discipline of security learnings, we know that the user is the end of an end-to-end security system. (c.f., Kerckhoffs 6th, Shamir's 3rd.) (Cunning thinkers of security will notice that Skype is clearly at b, and SSH is at a.) There are some (few) users who have become aware of the advice that they must check that the certificate belongs to the intended party, but they still have no concept of a MITM attack, so they look at the subject name in the self-signed cert, and see that it bears the name of the company they expect it to name, and they conclude that they have verified that the cert is correct and proper, and they get phished. Right. And some people who get phished by chrome replacements. And some people who get phished from a cert that is from bank-security.com or similar. And some people who get phished through CA issued certs. And some people get phished from XSS attacks. And some people get taken through malware. And some people get taken from nigerian 401 scams. And... The problem is one of economic balance in the face of false negatives and false positives, not of absolutes and static models. Either way, the people who get phished, after thinking that they've taken due care, conclude that there is no effective security on the internet. OK. That would be in accord with the security conclusions of any security team that worked through the full analysis in the late 90s when online banking was starting up [1]. The market over-rode their recommendations ... both at the micro level of each bank and the sector level of countries versus countries. So we would all be in agreement at that point. But they should conclude that there is no effective security on the internet WHEN YOU OVERRIDE the security precautions that were put there to protect them. We do not help them by further watering down the security warnings. Eyes off the microscope! The problem is a wider ecosystem or systemic problem in that the model only protects when the user checks the security precautions that are in place, on and perfectly in place. As the system has both OFF and ON modes, and as the system's ON mode is complicated to show, there is an obvious bypass attack. The result is that the ON community are working on making the ON button new, brighter and better, the attackers are
Re: CABForum place in the world
Good question! On 3/1/09 06:43, Kyle Hamilton wrote: The only thing that we can do is make sure that the user has as much (relevant) information as possible. So what is the relevant info? My list of relevant info: the name of the CA [1] the name that the CA signs the previous acceptance status of the cert (e.g., number of visits == petnames). the absence of the above (e.g., we are in OFF mode) My list of irrelevant info: the cert details the warnings the clicks the status of the connection (e.g., padlock) All these are too complex for users. Others are encouraged to comment :) We can use our own experiences to identify what information is most relevant. We can even ask CPAs and attorneys (hello, Mozilla general counsel) what information is relevant, after providing them the list of information that is compiled. And we can ask users to help figure out how the information should be presented. Sure! This is a research programme that Mozilla could fund, and likely the security people would be happy to undertake. I would propose the following groups: * the security UI people * the legal / class action people * the finance people ... What we can do -- and all we can do -- is provide relevant information that the user can use to make her own decision. What we can't do is protect the user from the consequences of his own stupidity. Arguably, we shouldn't even try. This question turns on whether you want light grade security or high grade security. If you want high grade security, you should follow the learnings of the security world. That means: * all threats must be validated, not imagined * no absolutes exist * we need a steady stream of failures to inform us * the user must be part of the system * the system must be very simple * we are part of the system iang [1] Disclosure + reminder: this position of the CA's name substantially predates my current work with CAs. ___ 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
Fully open operation (was: Full Disclosure!)
On 03.01.2009 16:48, Eddy Nigg wrote: ...I wouldn't be willing to disclose each and every detail of code, preventive measures, controls and procedures and possible events. Well, I think this might be a good idea, though. I could even go so far as to demand that all operations of the CA, including all processes in all detail, and the actual day-to-day operations, need to be open to everybody, both over the Internet and in real life. Anybody can just walk in the CA's office and watch anybody there working. All is entirely open to anybody. Only the private keys of the CA and the rest rooms are kept hidden. I think that would improve operation quite a lot. The processes would need to be water-proof and correct, just like a cryptographic algorithm needs to withstand public scrutiny. (And most actually do have weaknesses at first which are rooted out by the public review. This, as experience shows, outweighs the advantage that attackers get by knowing the algorithm. The algo just needs to be strong enough. I think you can create strong CA processes, too.) Also, the day to day operations could be observed, too, by anybody, whether they match the declared processes, and to see whether the declared processes still show holes in practice, e.g. lacking diligence when verifying signatures. (A regular and unannounced audit - of *all* parts of the processes, no matter if RA or not - by a third party would also be mandatory.) The problems we see are in no small part because CAs decalre their operations to be their private little business. Well, it's not, it's our responsibility. The browser gives the CAs special status, the CAs only exist because browsers invent this whole concept, so we say how a CA has to operate. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unbelievable!
* Eddy Nigg: just because CAs start to play games with each other. This is not about security proper. You're trying to pull us into a PR attack on one of your competitors, thereby willingly reducing confidence in ecommerce. (I'm exaggerating a bit, of course.) Exactly the opposite is true. If at all, I'm trying to encourage responsible competition on *equal* footing without compromising the security of the relying parties. It needs just *one* CA to devalue the collective work of browser vendors, certification authorities and cryptography specialist. Only one! Unfortunately some CAs take their responsibilities less serious than others - which in turn gives them a competitive advantage. I can understand that point of view. But what you seem to be asking is that browser vendors take the role of judges, regulating CA behavior. Shouldn't that be better left to the court system, keeping Mozilla out of the loop? What advantage does Mozilla gain by acting as a judge on day-to-day operations of CAs? It might make sense to demand additional elements in the CPS for future root additions, and re-audit existing roots. CAs (should) have controls in place to prevent that from happening. Could you explain what you're doing in this area? (A no is perfectly acceptable because nothing you can do is totally secure, so keeping the mechanisms secret actually buys you something.) Anyway, one thing that comes to my mind is domain control verification over multiple communication channels, perhaps by injecting multiple email messages at different points of the Internet, to make at least sure that any hijacking is rather close to the subject. But I don't think you have to answer to multiple mail challenges for DV certificates. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=460374 There might be a legitimate business reason to do this form of interception (doing this to get free AV is quite common, I suppose). But I agree it's interesting. ___ 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 03.01.2009 15:54, Florian Weimer wrote: The EV process does not verify ... that it is the legal entity which controls the domain name mentioned in the Common Name field. Are you saying that Fluff, Inc. could get a cert for mozilla.org, assuming Fluff, Inc reveal its legal identity? ___ 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
* Ben Bucksch: On 03.01.2009 15:54, Florian Weimer wrote: The EV process does not verify ... that it is the legal entity which controls the domain name mentioned in the Common Name field. Are you saying that Fluff, Inc. could get a cert for mozilla.org, assuming Fluff, Inc reveal its legal identity? Yes, that's the essence. s/Fluff/Mozilla Corporation/ and s/mozilla.org/addons.mozilla.org/, and you've got a real example (I don't think addons.mozilla.org is an asset of Mozilla Corporation). If necessary, I can provide a better one (I don't want to burn it at this stage if I can avoid it, though 8-). ___ 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: Unbelievable!
Gervase Markham wrote, On 2008-12-27 05:07: Hi John, You raise some important questions, but it's worth having clarity on a few matters of fact. John Nagle wrote: 1.AddTrust, a company which apparently no longer exists, has an approved root CA certificate. This in itself is troublesome. This is extremely common. Certificates change hands. One must admit that there is more than a little irony at play when the system that claims to offer sign assurances, binding keys to identity, and which (in the case of EV) claims to offer an identity that is strong enough that a relying party could take the party thus identified to court, fails to similarly identify the party making the signed assertion. ___ 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: Unbelievable!
On 01/03/2009 06:41 PM, Florian Weimer: I can understand that point of view. But what you seem to be asking is that browser vendors take the role of judges, regulating CA behavior. Shouldn't that be better left to the court system, keeping Mozilla out of the loop? What advantage does Mozilla gain by acting as a judge on day-to-day operations of CAs? The same criteria should be applied to all CAs. With less definition there is also more of room to undercut in every respect. Definitions and agreed upon standards are nothing for the courts really, they need to be defined first. CAs (should) have controls in place to prevent that from happening. Could you explain what you're doing in this area? (A no is perfectly acceptable because nothing you can do is totally secure, so keeping the mechanisms secret actually buys you something.) Yes, I think I don't want to elaborate on that really. But CAs usually have more experience and know-how to set up preventive measures than an RA. -- 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: Fully open operation
On 01/03/2009 06:32 PM, Ben Bucksch: Well, I think this might be a good idea, though. I could even go so far as to demand that all operations of the CA, including all processes in all detail, and the actual day-to-day operations, need to be open to everybody, both over the Internet and in real life. Anybody can just walk in the CA's office and watch anybody there working. All is entirely open to anybody. Only the private keys of the CA and the rest rooms are kept hidden. Haha :-) Actually exactly the opposite is true...NOBODY can walk into the CAs offices without proper identification, permission and an obvious need to do so. But aren't auditors the eye of the public performing and recording those operations? I mean, it's rather boring to watch some CA employee starring at a screen and it wouldn't provide much insight either. Neither is anybody allowed to view the details either (privacy), so... I think that would improve operation quite a lot. The processes would need to be water-proof and correct, just like a cryptographic algorithm needs to withstand public scrutiny. (And most actually do have weaknesses at first which are rooted out by the public review. This, as experience shows, outweighs the advantage that attackers get by knowing the algorithm. The algo just needs to be strong enough. I think you can create strong CA processes, too.) I certainly agree with the later. (A regular and unannounced audit - of *all* parts of the processes, no matter if RA or not - by a third party would also be mandatory.) Yes, this could be interesting indeed. -- 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: PositiveSSL is not valid for browsers
On 03.01.2009 18:09, Florian Weimer wrote: Are you saying that Fluff, Inc. could get a cert for mozilla.org, assuming Fluff, Inc reveal its legal identity? Yes, that's the essence. Well, that's a hole large enough that you can drive a trunk through. I'm sure it's pretty easy to set up shell companies etc.. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CAs and external entities (resellers, outsourcing)
On 31.12.2008 19:57, Frank Hecker wrote: Kyle Hamilton wrote: Ummm... has an enterprise PKI ever been included in Mozilla? Sorry, I wasn't being clear here. I'm not referring to enterprises that have their own root CAs. I was referring to schemes where enterprises work through CAs like VeriSign to issue certificates to their own employees, servers, etc. IIRC in a number of these schemes the CA is responsible for actually issuing the certificates but the validation is done by the enterprise. (For example, the CA might provide a web-based interface by which authorized representatives of the enterprise can submit previously-validated CSRs to the CA, and get back certificates in return.) In these cases the enterprises are essentially acting as RAs. I think this scenario is different, assuming it's implemented properly: The company would only be able to approve web server certs for their domain, i.e. it's like a wildcard cert. More importantly, they'd verify S/MIME email certs, but again only within their domain. I would consider this to be secure. ___ 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: CABForum place in the world
Ian G wrote: On Thu, Jan 1, 2009 at 1:29 PM, Gervase Markhamg...@mozilla.org wrote: Ian G wrote: My personal view of Mozilla is this: the ecosystem is developer-led. But the ecosystem isn't our representative on the CAB Forum. Our current representative is Johnathan Nightingale, our Human Shield and security and user experience expert. So Jon goes to CAB Forum with a mandate to speak for the end-users, without any input from Mozilla, the browser vendor? That's not what I said - where did you get that idea? Johnathan reads this forum, and I'm sure he takes on board all the input he receives. Gerv ___ 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
Eddy Nigg wrote: For example? Anything out of this list: https://www.startssl.com/?app=30#requirements You want us to make a IV certificate which can be issued to businesses without verifiable physical existence and business presence? You mean that want a price point in between DV and EV? :-) Yeah also. And why not? For many EV is an overkill, But it's not for their benefit they are getting that level of vetting, it's for the benefit of their customers. Let's put it another way: how do we explain the difference between EV and this new level to consumers? You can do transactions up to $X if there's an EV cert, but only $X / 10 if it's a NewV cert? Who's going to pay attention to that? Proper identity validation takes time, and so costs money. The only way to make it cheaper is to do less validation. And the less validation you do, the easier it is to get dodgy certs issued. If it's possible to reduce the amount of validation without running that risk, let's change the EV standard. If you think the current CAs are overcharging, get certified for EV yourself and charge less. Gerv ___ 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: Hmm. Then I misunderstand completely. Are we talking about Mozilla delivering updates to Mozilla users, or are we talking about general code-signing certificates for the ecosystem of plugin developers? My understanding was the former. If it's the latter, this entire discussion (or at least, the bit of it I've been in) has been at cross-purposes. Gerv ___ 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
Florian Weimer wrote: Organizations not on this list can usually get an EV certificate through a corporate sponsor. The EV process does not verify that the party to which the certificate is issued is the actual end user, or that it is the legal entity which controls the domain name mentioned in the Common Name field. That's simply incorrect. EV Guidelines version 1.1, sections 3.a.2.C, 6.a.2, 13.a.2 and, primarily, section 18 all refer to the requirement to check that the applicant is the registered holder of the domain name. http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf Gerv ___ 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: PositiveSSL is not valid for browsers
* Gervase Markham: Florian Weimer wrote: Organizations not on this list can usually get an EV certificate through a corporate sponsor. The EV process does not verify that the party to which the certificate is issued is the actual end user, or that it is the legal entity which controls the domain name mentioned in the Common Name field. That's simply incorrect. EV Guidelines version 1.1, sections 3.a.2.C, 6.a.2, 13.a.2 and, primarily, section 18 all refer to the requirement to check that the applicant is the registered holder of the domain name. http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf Section 18 does not require that the domain holder is aware of the application. This is a loophole, but a necessary one, because WHOIS service is not globally available. (I was not referring to this loophole, though; my point is that it's possible to game the EV process so that parties nominally not able to get EV certificates can get them.) Section 18 also treats DNS as a two-level hierarchy (TLDs and domain names), which is an oversimplification, but I'm not sure how likely this will cause any problems. But is it really true that Mozilla Corporation has exclusive control over the mozilla.org domain, as implied by the addons.mozilla.org EV certificate? The web sites indicates that it (the site) belongs to the Mozilla Foundation, and that mozilla.com is Mozilla Corporation's domain. ___ 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
* Ben Bucksch: On 03.01.2009 18:09, Florian Weimer wrote: Are you saying that Fluff, Inc. could get a cert for mozilla.org, assuming Fluff, Inc reveal its legal identity? Yes, that's the essence. Well, that's a hole large enough that you can drive a trunk through. It's suggested that some domain validation is involved as well. But certain organizations face quite a few difficulties accepting mail at certain addresses or putting literally random stuff on their web site, so I'm not surprised that those requirements have been relaxed. (And matching WHOIS can't be made mandatory because there might not be any WHOIS to match, or WHOIS data which contains usable contact information in the context of the application.) There are simply no official records linking the Mozilla Foundation to mozilla.org (if it actually owns the domain, which isn't 100% clear to me). This means that it's never possible to link the legal side (where you've got registers of companies, notaries public, and whatnot) to the DNS side (where there's little to no regulation, depending on the TLD). On top of that, it's generally very hard to prevent attacks which involve non-existent entities (like obtaining database locks on records which don't exist). I don't think the EV guidelines completely deal with this issue, and rightly so. However, EV certificates are sometimes marketed as if they guarantee that the entity is trustworthy (and is not trying to trick you into some phishing scam, for instance, or make poor investment choices). I'm sure it's pretty easy to set up shell companies etc.. Here's a German article on a related type of fraud that actually occurs: http://www.spiegel.de/spiegel/0,1518,druck-598487,00.html Apparently, failed real companies are routinely sold to fake shell companies, bypassing normal bankruptcy laws. Along the way, the willingness of certain notaries certify almost everything is exploited. 8-( However, my main point is that under the EV process, corporations can sponsor EV certificates for organizations which can't get them directly. We'll see if addons.mozilla.org is considered sufficient proof of that claim. ___ 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
Pre- and Post- controls
On 3/1/09 17:41, Florian Weimer wrote: I can understand that point of view. But what you seem to be asking is that browser vendors take the role of judges, regulating CA behavior. Shouldn't that be better left to the court system, keeping Mozilla out of the loop? What advantage does Mozilla gain by acting as a judge on day-to-day operations of CAs? I think this is an extremely important point. Security and other objective systems work on certain very basic assumptions. One of which is (a) we put in place policies and practices. Cool, we all agree with that. Another very basic assumption is (b) the policies and practices are not perfect, and will fail, from time to time, in place to place. (Now, I recognise that this is new to some, but it is a fundamental part of the makeup.) What happens when it fails? If nothing happens then a savvy operator realises that, all those procedures and policies and whathaveyou are worthless. Or at least, can be ignored. Mint certs, cash in. Now, in theory society has an answer for this: punishment for those who fail to follow our rules. If the punishment, or control is designed well, we have a balance of pre- and post- event controls, and a feedback loop that takes events and feeds info back into policies and practices. What is at issue here is that we don't have good post-event controls. When something fails, we do not know what to do. We have on the table, right now, three examples of failure. They are all radically different, at various levels, and an objective analysis of the results will throw up lots and lots of contrasting suggestions, and lots and lots of unfair comparisons. On the punishment side, about all we have is drop the root! which I earlier described as a blunt weapon. Are we being sensible when we now have to drop the root for the three CAs who have reported problems? So what to do? Should Mozilla become the judge in the post-event phase? Do we leave this job to the courts? Should we group together on this list and pass final judgement? Should we all vote? Demand changes? Should we implement California rules -- 3 strikes and the root is killed? We need something. With nothing, we have no feedback. With no feedback, any objective system drifts to subjectivity. It is I think the case that for the entirety of the Internet PKI system, no participant has ever been punished; how far into insecurity are we? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fully open operation
It was written: But aren't auditors the eye of the public performing and recording those operations? That's one theory. Here is another: Who is the client of the auditor? The auditor has a duty to the client that (arguably) outweighs the duty to anyone else. You might not agree to the above characterisation. But, try this test: can you draw a line from the auditor to the public? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
