Re: StartCom & Qihoo Incidents
On 10/14/2016 01:00 PM, Gervase Markham wrote: K) StartCom impersonating mozilla.com. https://bugzilla.mozilla.org/show_bug.cgi?id=471702 StartCom's (former) CEO Eddy Nigg obtained a key and certificate for www.mozilla.com and placed it on an Internet-facing server. I do consider it a significant error of judgement for Eddy to have chosen www.mozilla.com, rather than a site owned and controlled by him or by a third party with whom he had an agreement, for his demonstration. Well, at time I didn't think that much - I noticed it when requesting a certificate for startcom.org in order to investigate a completely different issue and later got one for mozilla.org (note it wasn't .com). Initially I thought about some really high-profile name, but then I tried with mozilla.org since I assumed that A) Mozilla will forgive me and B) I was frequently involved here at that time. :-) Surprisingly it worked and I got my certificate for mozilla.org On the other hand, this happened 8 years ago. I'd be interested in your comments, Ryan, on whether you think it's appropriate for us to have some sort of informal "statute of limitations". That is to say, in earlier messages you were worried about favouring incumbents. But if there is no such statute, doesn't that disadvantage incumbents? No code is bug-free, and so a large CA with many products is going to have occasional troubles over the years. If they then have a larger issue, is it reasonable to go trawling back 10 years through the archives and pull out every problem there's ever been? This is a genuine question, not a rhetorical one. I believe there is also something called "reasonability " - I believe during my tenure StartCom tried to reduce risks first and foremost through its policies, honestly and earnest. And then unintentional mistakes and issues can happen Of course every CA wants to issue hundreds of thousands of certificates, but it usually doesn't start like this. I admit that some of the issues were due to growth pain, scalability or simply doesn't happen below a certain number of users/certificates. Any programmer working on larger scale projects and long enough in the profession can tell some stories about bugs that happen only every 50K or 50M time. I don't want to offer cheap excuses, but reality has it that things do happen and this is also part of that "reasonability". CAs must however have policies and procedures in order to evaluate issues that do happen, make the correct assessment and deliver a reasonable solution based thereof. This is the logic of a correctly functioning CA (or other businesses for that matter), this is what auditors verify and what software vendors should expect. There is no business, no software and no certificate authority without fault - realistically and reasonably. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom & Qihoo Incidents
On 10/12/2016 10:11 PM, Ryan Sleevi wrote: As Gerv suggested this was the official call for incidents with respect to StartCom, it seems appropriate to start a new thread. Ryan, it was probably easy to dig up any possible claimed or proven issue ever surrounding StartCom during its ~ 10 years of operation. But if this is your level of measurement for remaining in a root store, than you have probably some other and larger CAs that would require your immediate attention more urgently Incidents with StartCom: As most issues have been discussed and explained at that time, I'm not sure about it's usefulness to repeat the same arguments and explanations again. Most issues you are listing were mostly minor (but makes your list longer of course) and have been effectively and properly dealt with. K) StartCom impersonating mozilla.com. https://bugzilla.mozilla.org/show_bug.cgi?id=471702 StartCom's (former) CEO Eddy Nigg obtained a key and certificate for www.mozilla.com and placed it on an Internet-facing server. You make this appear as if StartCom used its capacity as a certificate authority to somehow abuse somebody or something, but for the wider audience: I was able to obtain a certificate for mozilla.org from Comodo without having the authority to validate said domain name - in fact I could have obtained also wild cards and many more certificates for any domain name would I have been willing to pay for it. I installed the certificate at a local server as a proof in the same fashion millions of web sites install theirs. The private key has never published to any third party and was eventually destroyed. Interesting that you are using it to shoot the messenger from back then and list this as an item against StartCom :-) I hope the above show that the odds are if the original StartCom systems are restored, we're likely to continue to have significant BR violations - a pattern StartCom has repeatedly demonstrated over several years. There is no plan to use software that doesn't comply to the various requirements and it has never been. I'm not claiming that there have been zero issues during the last ten years, but StartCom has had always clear policies and practices in place about how to deal with an issue reasonably according to its significance, seriousness and importance. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign: updated report and discussion
On 10/11/2016 11:57 AM, Gervase Markham wrote: There is also the case of StartEncrypt. While no known cert-to-wrong-person misissuance occurred because the researchers in question used domains they already controlled to prove their point, but there seemed to be multiple holes by which this might be possible. I haven't forgotten it and mentioned that Inigo has several tasks at hand: "/... he'll have to review also other areas and implement controls in case they were lacking or insufficient, something he's doing as we speak/" This includes obviously development cycles and other areas, even if no issues have been detected or reported. Of course, people can reasonably disagree on the seriousness of the issue (standalone, and by comparison with e.g. WoSign issue N), and it is true that StartCom took this codebase wholesale from WoSign, but it seems incomplete to leave this out entirely. It wasn't my intention to ignore it, but I understand that this issue has been quickly contained at that time. Eddy: does StartCom currently have any fully-automated certificate issuance mechanisms, or does every certificate request pass by human eyes before issuance? Generally speaking it's semi-automated with a flagging system that forces about 20% of all lower level certificates for a manual review and approval by the verification team. Of course EV and code signing certificates are issued only manually. The rest is issued automatically. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign: updated report and discussion
Hi Kathleen, On 10/10/2016 09:39 PM, Kathleen Wilson wrote: I would like to remind everyone that when making decisions about what to do about CA mis-issuance, it is expressly *not* a goal for me to mete out punishment. Rather, my primary goal is to help keep end-users safe, based on the information that is available. Allow me to add some of my thoughts into the discussion. I've read most of the comments and arguments made here so far and assume that most participants have the relevant information so that I don't have to repeat them again I was directly responsible for StartCom for many years and gained some experience in running a certificate authority, writing policies and implementations thereof. I've helped to draft important guidelines and requirements for CAs and in general learned about the mesh of software vendors, certificate authorities and (web) PKI. I'm probably one of the faces of this industry and would offer my two cents in this capacity hereby The problematic issue in relation to StartCom is obviously the _two backdated SHA1 certificates_ - however from the strictly technical point of view I don't think that the user-base of Mozilla in general and the relying parties in particular were much more at risk than relying on any other SHA1 certificate that was obtained legitimately before the 1st of January 2016. The risks were probably minimal since the certificate properties besides that were validated correctly. However, a completely different matter must be considered here - that of compliance to the requirements set forth by the relevant bodies and software vendors. Besides the _loss of trust_ in this particular case, non-compliance happens many times due to _insufficient controls_. Being it either that the requirements weren't correctly understood (not the case here), or insufficient controls to prevent such non-compliance and wrongful certificate issuance. The remediation and corrections StartCom proposed are significant in this respect - basically Mr. Richard Wang has been removed from his position and unfortunately for him is paying a high price for overstepping his authority. The parent company (WoSign) too has been released of all its responsibilities and a full separation has been set into motion. The choice of Inigo Barreira as the new CEO of StartCom is probably a good one and we all assume that he wouldn't approve the backdating of certificates judging from his long-time recordhowever one of the immediate tasks of Inigo will be to implement controls that will make such abuse impossible - not by him and not by anybody else. I believe this is the _core issue and remediation_ here, which was the failure in first place. (Obviously he'll have to review also other areas and implement controls in case they were lacking or insufficient, something he's doing as we speak). But by looking at StartCom's performance besides that, I believe that some of the voices and arguments haven't been reasonable during this discussion! Was there a CA certificate compromise? Has StartCom lost control of its issuance processes? Has StartCom in general failed to validate certificate properties correctly? Has StartCom lost its ability to abide and comply to the policies and requirements set forth? Has and does StartCom present an undue risk to the user-base of Mozilla (and relying parties in general)? I believe that none of the above applies which would warrant such dramatic steps on part of the software vendors and StartCom is generally operating correctly. The particular failure that did happen can be dealt with properly, firmly and professionally as proposed; _without knocking StartCom out of business_. I believe StartCom is still an important part of today's SSL landscape and it shouldn't be in anybody's interest to remove it as a viable alternative to current mix of the established certificate authorities - except if somebody is looking for revenge or other personal matters -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom: next steps
On 10/07/2016 12:38 PM, Gervase Markham wrote: I am a little surprised it hasn't appeared by now. We did not agree a specific deadline, but my impression was that it would appear in a few days, which I mentally interpreted as "by the end of the week". Today is Friday, so there is still time for my vague expectations to be met :-) I'm sure Edward, Tan and Inigo are working on it furiously. Perhaps they can give a status update and an estimated time of publication? Hi Gerv, I'm sorry for the somewhat late reply due to holidays/weekends and flight connections of the participants of the meeting. First thanks for hosting the meeting and I'm sorry that I personally couldn't attend. WoSign already provided its incident report which includes basically most information regarding the various issues and failures. There were parts of the proposed steps mentioned already, hereby I'm trying to summarize it. Next week we'll add sub sections and dates to it: 1) Legal Structure - Separation of StartCom and Wosign's legal structure - StartCom reports directly to Qihoo 360. 2) Management / Board - Mr. Tan is appointed Chairman of StartCom, Inigo Barreira appointed CEO/Director of StartCom. 3) Team / Operations - Tan and Inigo work to separate StartCom and Wosign verification, development and management teams. Basically any previously shared functions (where they existed) will be separated. 4) System / Software - Any shared infrastructure will be separated from WoSign, current code base will be reviewed by Qihoo 360 and audited internally. StartCom makes the systems available for an external security audit as necessary. 5) All certificates past, present and future will be logged with CT compliant log servers. 6) Public Documentation - StartCom will present its near-term plan and update as it progresses. Item 6 is currently the outlined steps above, plus most specifications, sub steps, specific dates in particular for items 3 and 4. I assume that steps and promises StartCom commits to will be audible and/or easy to be confirmed. I assume that Inigo will report to the mailing list sometimes directly too in order to update on the progress. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom audit reports
On 09/23/2016 05:53 AM, Peter Bowen wrote: Review of StartCom audit reports for the period 1 January 2015 to 31 December 2015 Good: - Uses AICPA standards - Uses current criteria versions Bad: - Only covers two roots, not subordinate CAs (true for all three reports: CA, BR, and EV) - Does not provide assurance that subordinate CA certificate requests are accurate, authenticated, and approved - Does not provide assurance that it meets the Network and Certificate System Security Requirements as set forth by the CA/Browser Forum Speaking only for StartCom here, as far as I know and as per auditing standards, all intermediate CAs are audited (no external intermediates existed). As to network security, I believe this is part of the Baseline Requirements audit. But if necessary I can ask our auditors and also WebTrust directly if there is really missing something. I assume that all is included, covered and implied, but should a mistake have happened in the statements made by the auditors I'm sure we can get a corrected statement or explanation. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
On 09/05/2016 10:54 AM, Gervase Markham wrote: Hi Eddy, On 04/09/16 09:51, Eddy Nigg wrote: I don't want to extend this discussion unnecessarily, but as a side note you don't know which agreements this employee has signed with StartCom and/or WoSign and hence you can't make a judgement on it either. Lets leave this to the professionals dealing with it. If he has signed an agreement with StartCom and/or WoSign which prevents him from pointing out, after leaving employment, facts which are in the public domain, then I suggest that those clauses in the agreement are an unconscionable[0] restriction on his freedoms and you should not be enforcing them. Again, I don't think we can and will solve this in public, however I believe it's the complete right of a company (and employer) to decide how and when it wants to make an official public announcement about its business (and being just in order to complete a currently ongoing transaction first). Not every employee is authorized to represent the company and inform third parties (at his/her convenient timing and consideration) even if he/she knows about it and/or some information has been placed into (partly) public domain as part of a business process. I hope my explanation makes it clear that this ex-employee was not authorized to provide any information about StartCom or WoSign. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Incidents involving the CA WoSign
On 09/04/2016 09:20 AM, Peter Gutmann wrote: Peter Bowen <pzbo...@gmail.com> writes: It was brought to my attention that there is another incident. This is great stuff, it's like watching a rerun of Diginotar .says the audience on the backbenches gleefully but no, what are you talking about?? Even though some nasty and undesired errors happened here, its in no comparison to what happened at Diginotar which basically lost control over the CA. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 09/02/2016 07:02 PM, Nick Lamb wrote: On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg wrote: Lets speak about relying parties - how does this bug affect you? As a relying party I am entitled to assume that there is no more than one certificate signed by a particular issuer with a certain serial number. If I have seen this certificate and verified by whatever means I choose that it's OK, then I can safely assume that any time I see a certificate in the future signed by that issuer with that same serial number it's the same one, and skip the verification process. Well, according to the CA policies and relying party terms, you should always check with the CRL or OCSP responders if a certificate is considered valid or not. So the verification process shouldn't be skipped beyond the advertised refresh time (in CRLs/OCSP). Of course if you do some sort of certificate pinning based on serial and issuer, than this wouldn't work. But I'm not aware of any common software that doesn't use the certificate's public key for pinning and relies just on a serial numbers. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
On 09/03/2016 11:02 PM, Percy wrote: I agree completely that we shouldn't imply fundamental guilt by association. However, WoSign threatened legal actions against Itzhak Daniel's disclosure compiled purely from public sources. I just want to make sure the disclosure was not buried after the content was taken down. I don't want to extend this discussion unnecessarily, but as a side note you don't know which agreements this employee has signed with StartCom and/or WoSign and hence you can't make a judgement on it either. Lets leave this to the professionals dealing with it. (Of course your copying and distributing of the content originally published by him can be also used against him, just some food for thought) As such, there can be many more things you don't really know regarding this or other business transactions. And probably this is the wrong forum for such matters in any case. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 09/02/2016 09:38 AM, Jakob Bohm wrote: 4. Violations that are purely technical but cannot actually endanger relying parties (such as issuing non-unique certificates to the correct entities, or issuing certificates with too early expiry dates). This would be the case with the StartCom serial number assignment bug. The way Eddy Nigg describes the issue, it appears there is some kind of low level race condition in the code or hardware that increments and uses the serial number counter deep inside the CA, perhaps in a heavily locked down HSM that prevents fixing the issue without generating a new CA key. You are pretty close If this is the case, and they correctly store the actually issued certificates with the wrong serial numbers, the main problem would be the inability to revoke one certificate without revoking the others, while a secondary problem could be relying parties rejecting the certificates if they actually see more than one of a set of conflicting ones within their local cache lifetime. Since both of those problems would be limited to the certificates not being trusted when the facts that should get them trusted are in place, there is no real danger. You nailed it - I just asked the question about how it affects relying parties in an other reply to the list, you answered already. StartCom is of cause one of those high speed DV CAs, that promise cheap DV issuance within minutes of the request being submitted. So preventing occasional non-dangerous (but obviously non-compliant) serial number collisions would require more than average skill by hardware, firmware and software engineers. True - and this was planned AND implemented. That said, they really, really should have set up an automated test script that scans issued certificates for the problem and raises an alarm so such certificates would be reissued (with distinct serial numbers) and revoked within a few days of each failure. True that we could have done what you suggested. I don't really recall why we didn't, though I think things got easier with CT today for similar issues. The fact is that it didn't had really an effect on the certificate holder or relying parties (except in case of a revocation in which case both certificates would have been revoked and probably issued again depending on the circumstances of the revocation). -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 09/01/2016 11:52 AM, Nick Lamb wrote: On Thursday, 1 September 2016 08:54:16 UTC+1, Eddy Nigg wrote: Not so, rather according to my assessment, the cost and everything it entailed (including other risks) to fix that particular issue outweighed the benefits for having it fixed within a time-frame shorter than that. It seems to me that was not your decision to make. The relying parties trust StartCom on the basis that it will do what it said it would do, not just whatever "in your assessment" offers most benefits to you. The only option that was permissible without seeking some exception was to cease issuance until the problem was repaired. First of all the issue can have been considered fixed due to machine test - evidence for some occurrences took month to resurface and at such low numbers that couldn't be reproduced (something almost required to fix a bug). I'm not sure if you or others here are programers, but knowing how things work and once we had evidence that there was still a very low occurrence, a plan was set up which included a different hardware and infrastructure. To StartCom, ceasing issuance feels like a really big risk, that is understood. But for the relying parties it's not. Lets speak about relying parties - how does this bug affect you? -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 09/01/2016 04:20 AM, Matt Palmer wrote: That sounds an awful lot like "we can't fix our own systems", which is a... terrifying thought. Not so, rather according to my assessment, the cost and everything it entailed (including other risks) to fix that particular issue outweighed the benefits for having it fixed within a time-frame shorter than that. "Some time" being about a year longer than you stated it would take in the bug. That's quite some time. If hardware changes and other infrastructural changes are involved than this time-frame can reasonable perhaps. CA infrastructures are usually not fast-moving ones according to my experience. This wasn't about changing a line or two in some software component. You were knowingly violating a MUST provision of RFC5280. From experience there have been many RFC violations, sometimes even knowingly and intentionally by software vendors (browsers), certificate authorities and even policy writers such as CAB Forum. Mozilla, Microsoft, Google and others are sometimes violating or not conforming to RFCs for this reason or the other. The implication and severity of such a violation matters probably. The audit letter included an attestation from Management that, during the time of the audit, management believed that the CA complied with the Baseline Requirements. True, we could demonstrate steps performed, plans produced, implementations performed etc. on this particular issue. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 08/31/2016 05:56 AM, Peter Bowen wrote: In reviewing the Certificate Transparency logs, I noticed the StartCom has issued multiple certificates with identical serial numbers and identical issuer names. https://crt.sh/?serial=14DCA8 (2014-12-07) https://crt.sh/?serial=04FF5D653668DB (2015-01-05) https://crt.sh/?serial=052D14BA553ED0 (2015-02-07) https://crt.sh/?serial=05B42A4FE11129 (2015-05-17) https://crt.sh/?serial=0615C666E8C56E (2015-08-05) https://crt.sh/?serial=0693A7FCC84DD3 (2015-11-10) Each of these serial numbers has two distinct certificates with no apparent relation between the subject entities. There were a couple of certificates which resulted in duplicate serials - this could happen under certain circumstances, a bug that has been fixed by now. We'll look into revoking and reissuing them. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartEncrypt considered harmful today
On 07/01/2016 05:54 PM, Patrick Figel wrote: Can you comment on how your backend checks would have prevented any misissuance? My understanding of the report is that this was not so much an issue with the client software, but rather an oversight in the protocol that allows Domain Validation checks that are not sufficient in assuring domain ownership, thus the issue was very much a backend issue. I assume there are reasonable controls in place to prevent misissuance for high-risk domains, but what about other domains? Would they have been affected by this? Hi Patrick, Depending on the flagging parameters and the attending certificate officer, the (some) certificate might or might have not been issued - I'm careful with this statement as suspicion can arise for this or the other reason, but it's not 100%. High-profile names would have been flagged and not issued though. I would also be curious about why the certificate has not been logged to CT, given StartCom's prior statements with regards to CT adoption. We are checking it, it might have been logged at the wrong place. I'll try to provide an answer on this too when possible. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartEncrypt considered harmful today
On 06/30/2016 06:30 PM, Rob Stradling wrote: https://www.computest.nl/blog/startencrypt-considered-harmful-today/ Eddy, is this report correct? Are you planning to post a public incident report? Hi Rob and all, There were indeed a couple of issues with the client software - known bugs have been fixed by our developers (hope there wont be anything more significant than that :-) ). So far less than three hundred certificates have been issued using this method, none should have been effectively issue wrongfully due to our backend checks. At the moment I don't believe that a public incident report is necessary, but should anything change in our current assessment we will obviously act accordingly. I instructed additional verifications and confirmations to assert that assessment. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org <xmpp:start...@startcom.org> Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Only accepting 2048 bit or better certificates
On 06/21/2014 07:15 PM, Kurt Roeckx wrote: But I would like to start enforcing the 2048 bit as soon as possible. Do we have some criteria for at which point we're willing to break compatibility? I'm in favor of enforcing it which will help reduce even mistakenly issued certificates with smaller keys to be detected quickly and there will be no incentive to use such keys for web sites (there are other use-cases for non-browsers and those should be still permitted I guess). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. http://www.startcom.org XMPP: start...@startcom.org xmpp:start...@startcom.org Blog: Join the Revolution! http://blog.startcom.org Twitter:Follow Me http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/25/2014 08:50 PM, Jan Lühr wrote: What's your argument here? Is crying foul Unjustified, because nobody cried foul the moment you published your policies? It's unjustified if as a subscriber you are not willing to accept the terms and conditions of that service, e.g. you want to accept the convenient part of it but not commit to your obligations. Please consider: Heartbleed-scale problems have hardly happened before. True - the closest would be probably the Debian weak keys. I'ven't considered any mass-key-compromise scenarios before I did - I learned from the Debian weak keys a lot. Personally, I am crying foul because I'm re-thinking your policies having heartbleed in mind. You can't really rethink our policies, this is something we might have to do at some point. You can either agree or disagree with them though. Personally, I vote no. StartSSL is not revoking certificates assumed to be compromised, if a subscriber doesn't pay. You are expecting to receive all benefits without taking responsibility for your part? Or lets put it like this: As you stated before, how likely is it that such an event like this one occurs? It might have never happened and in fact some 83% are not affected (world-wide), which means that they will happily keep obtaining certificates without ever paying a dime. Would you have used a different software, you could be easily one of those 83% too. Now, exactly because of this and other scenarios, where revocation of a certificate is necessary or is requested for any other reason by the subscriber and it's not due to a failure of the CA we decided to charge a fee in order to protect us from losses. Otherwise the current business model would probably not work...and I'm not even talking about easy abuse that's possible with the current model without raising a fee. - You say it is small / low by describing the circumstances under which it happens and causes an impact. Currently the facts show that StartCom's revocation numbers are not lower, in fact a bit above average. And here some more interesting facts: http://news.netcraft.com/archives/2014/04/25/heartbleed-why-arent-certificates-being-revoked.html -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. http://www.startcom.org XMPP: start...@startcom.org xmpp:start...@startcom.org Blog: Join the Revolution! http://blog.startcom.org Twitter:Follow Me http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/10/2014 07:05 PM, Eddy Nigg wrote: I agree - I've saw the tweets bug reports and this posting. I'll be glad to join the discussion and we intend to take a public stance as soon as things calm down a bit. Currently all hell is lose, but I promise to get back to you all in due time and will explain our position, policy and practices and also refute some of the claims that were made. In the meantime please be patient, thanks. Alright - things have calmed down luckily by now. As my first input to the discussion please read carefully my explanation, thoughts and comments I've written down in my blog at https://blog.startcom.org/?p=230 -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. http://www.startcom.org XMPP: start...@startcom.org xmpp:start...@startcom.org Blog: Join the Revolution! http://blog.startcom.org Twitter:Follow Me http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/23/2014 10:32 PM, Radu Hociung wrote: What will you do do avoid this? Check what's behind the (now meaningless) green lock? what if the site replaced its certificate with a new one, non-startcom ? You can still be MITM'd using the existing, valid cert, so you can't even be certain that you're safe. I do have a few questions to you! How can you know that a site using a certificate from ANY CA isn't or wasn't affected by the Heartbleed bug? Do you know how many certificates from CAs other than StartCom have NOT been revoked? And can you tell me which of the currently installed certificates no matter who the issuer is were issued after a revocation of a previous certificate? Once you can answer me these questions I have an interesting surprise for you Consider also that the presence of Startcom in this market is a barrier to entry to other, honest and potentially inexpensive CAs. No, it's not, otherwise StartCom would own 100% of the market share which it doesn't. The offerings of StartCom suite certain users and others not. How can they compete with the perceived free certificates that Startcom floods the SSL space with? They are free of charge no matter what - and under normal circumstances will not cost anything. Approximately 17% might be affected by this bug, another 87% are not. This means users are getting year after year a free service for 0.00 US$ from StartCom and keep getting it now and in the future, the rare exception which isn't even under our control are revocations. And if it wouldn't be necessary to raise a fee for that we wouldn't either. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. http://www.startcom.org XMPP: start...@startcom.org xmpp:start...@startcom.org Blog: Join the Revolution! http://blog.startcom.org Twitter:Follow Me http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 03/07/2014 07:10 AM, From spark0...@gmail.com: According to Mozilla's definition of independent party, KISA is independent organization from Sub-CAs(not employees nor director) The minute a CA signs a certificate of/for another CA, it's not independent at all. In fact a tight relationship exists between the two parties and a CA can't audit another CA. For this the BR sets forth a requirement for an independent audit by a (different) auditing firm than the CA signer/issuer, in order to avoid any conflict of interests. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 03/04/2014 09:38 PM, From Kathleen Wilson: My personal preference is to proceed with the process to approve/include the KISA root under the condition that Mozilla would constrain the CA hierarchy to *.kr. However, KISA does not want to constrain their CA hierarchy to *.kr. I have also suggested that KISA have each subCA apply for inclusion as separate trust anchors, but KISA does not want to take that approach either. I think the BR and Mozilla's own policy has set the proper requirements defined for any CA operating under another CA (root). This should apply here too which excludes the CA performing a (self) audit for the sub ordinate CAs for example. In respect to limiting issuance to a TLD, Mozilla might have to set a criteria for it first. Being a national (local) CA could be such a criteria. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert Request to Include Renewed Roots
On 01/29/2014 08:50 PM, From Jeremy Rowley: 1) These root certificates are used in many different systems, not just Mozilla. If Mozilla doesn't embed all of them, the ones not embedded will essentially be untrusted. The roots proposed are simply replacements for our existing root certificates, and our plan is to phase out the current DigiCert root certificates once there is sufficient ubiquity in the new roots. Jeremy, not that I overly care, but are you saying that all these roots plus the existing roots were accepted in the Microsoft roots program? I thought there is a hard limit of three roots these days and if correct and enforced by Microsoft your argument doesn't hold. I'd say that you probably should have not more than three roots, maybe each with a particular algo and hash. From those you can and should issue intermediate CA certificates according to the various purposes you outlined in your mail. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
On 12/12/2013 12:31 AM, From Kathleen Wilson: I understand that this is not fair to the CAs who have done a great job of transitioning off of 1024-bit certs. Right - potential customers knock at various doors in respect to such certificates and I believe to have given the right answers to them that it's not possible to obtain such certificates anymore when approached. Indeed if this isn't something applied equally it might be very difficult to enforce other requirements in the future if at the first opportunity there is yet another exception to the previous exception etc...if experience shows that it doesn't pay out to comply to requirements, than why care next time? -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/24/2013 08:01 PM, From Kathleen Wilson: For EV certs Firefox has always checked the CRL when the OCSP AIA URI was not provided. EV treatment would not be given if current revocation information was not obtained. If Firefox really uses the CRLDP, then I suggest to keep that option still open meaning if no stapled OCSP response, use the normal pointers and if that fails use CRL. Remove EV (and the secure UI indicators if you want from any other certificate) when certificate status can't be verified. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Why isn't this cert recognized by Mozilla as an EV cert?
On 04/19/2012 11:15 PM, From beltzner: On Thu, Apr 19, 2012 at 4:13 PM, Wan-Teh Changw...@google.com wrote: So I suspect that the bug is that for some reason Mozilla cannot finish loading that page. Couldn't that also be the result if there was mixed-content? Sorry, I replied to the policy list before seeing this message. Indeed this site has unsecured content at this page, the connection is considered insecure in this case. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev
On 05/18/2011 09:45 PM, From Adam Barth: We tried aggressively blocking active mixed content by default in the Chrome Dev channel, but too much broke. We're going to unblock it again and try to find some middle road. That's a shame and very regrettable. Together with IE9 you could have made a difference in order to pull over other browser vendors to do the same, which in turn would have put the pressure elsewhere (those that provide stuff to embed with their sites). IMO, mixed content breaks the security and concept entirely. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: NSS/PSM improvements - short term action plan
On 04/09/2011 01:52 AM, From Adam Barth: There's significant interest in this feature from chrome-security as well. There is however a very limited benefit and would only prevent a particular type of failure if at all. The enforcement for it would have to be baked into the client software and adherence by CAs would have to be required by policy. I don't see that happening at the moment, specially because the benefit is fairly small for the hassle. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: NSS/PSM improvements - short term action plan
On 04/09/2011 10:32 PM, From Adam Barth: Yes. Certificate (or CA) pinning in HSTS is an agreement between a web site and a browser. Excellent! Even though I assume that this still prevents only a particular failure and probably should never be a substitute or shifting of responsibilities by the CAs. But as long that this is voluntarily and optionally for those seeking/needing/wanting an added break, I think that's nice to have. Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. http://www.startcom.org XMPP: start...@startcom.org xmpp:start...@startcom.org Blog: Join the Revolution! http://blog.startcom.org Twitter:Follow Me http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Verizon and Etisalat
On 08/18/2010 06:27 AM, From Kurt Seifried: I have to say I'm a little concerned, I have now seen a good half dozen or so situations where CAs completely failed in some manner (technologically, procedurally, etc.). Yes, me too. And nothing has happened. However I don't think that's correct. In some cases some of the problems have been fixed with the specific CA that got caught Yes and finally a sane defined list exists for domain control validation via email as a requirement. I believe that the Mozilla CA policy still has to be updated though. Additionally three CAs were removed and omitted from the latest batch of root updates for NSS. That's not nothing - it's a strong sign about what to come and what possibly may happen to CAs until the issues are fixed. And rest be assured, most CAs come along here every while. I suspect there are still some CAs that allow non standard addresses) or the CAs signing certs not only for IP addresses but for 192.168.1.2 and the like (which is completely inexcusable). Agreed and unfortunately Mozilla hasn't apparently made any decision yet. Obviously Mozilla can't always act alone, but there are certain principals I expect that it should and will have to upheld and enforce. I have seen 0 widespread or concerted effort from Mozilla to get these problems corrected. It's my expectation that the responsible persons start to act. Apparently it's possible as Sid demonstrated with the email list for domain control validation. More has to be done. Are we ever going to see Mozilla/Firefox actually do anything (like reprimand CAs publicly, remove bad CAs, ship revocation certificates for known bad sub CAs, or?). Well, how about finally defining and notifying about those issues before any other actions can be performed? I think this step must come before anything else. The certificate represents a Certificate Authority It would help if the interface maybe displayed a warning or the Organization name or something instead of just a blank I suggest to open a bug report for this against the PSM module. And I expect this to be easily solved. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Alerts on TLS Renegotiation
[ Please follow up to mozilla.dev.tech.crypto ] After some discussion at bug 554594 I'm following up here - the bug was unfortunately misused by me a little for the initial discussion. At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the following is proposed: security.ssl.require_safe_negotiation If set to true, a Mozilla client will reject *all* connection attempts to servers that are still using the old SSL/TLS protocol and which might be vulnerable to the attack. I believe this to be a mistake for various reasons, but first and foremost because an attack on a server without compromise of the client data as well, is basically useless. When a attacker induces renegotiation at the server, the attacker must have client credentials in order to act as if he were the original client. Without those credentials, the attacker would be treated as any other unauthenticated source. When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. I propose that Firefox should support the RFC 5746 extension exclusively, but NOT block or warn on accessing servers which don't support the extension. Any renegotiation attempt to the client will be ignored and no data is leaked. The advantage for this approach would be earlier support of RFC 5746 which would facilitate safe renegotiation with servers that support it, but still allows to support servers which don't support it. SSLv2 was disabled in Firefox only a short while ago, despite the fact that newer protocols were available for most of the last 14 years. I expect that it will take years upon years until 90% of all SSL enabled servers will support RFC 5746, not speaking about 99% or higher. Refusing to speak to servers that don't support RFC 5746 - even if the sites probably never need renegotiation - will have an undesired effect, either by breaking SSL entirely or forcing the user to accept unsafe renegotiation, which will leave the user vulnerable once again. It also must be noted that 99% or more of all SSL enabled web sites will never need renegotiation to work. A server which disabled renegotiation is at least as secure as a server supporting the new extension. Those that need it will probably patch their servers sooner or later and are not a concern IMO. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
On 02/09/2010 11:50 PM, David E. Ross: On 2/6/2010 7:04 AM, Eddy Nigg wrote: Isn't it about time that extensions and applications get signed with verified code signing certificates? Adblock Plus is doing for a while now I think, perhaps other should too? Because this isn't really comforting: http://www.theregister.co.uk/2010/02/05/malicious_firefox_extensions/ I just now noticed that this discussion was not cross-posted to mozilla.dev.extensions. Should not input from extension developers be considered? I'm now cross-posting this reply to mozilla.dev.extensions with follow-ups back to the newsgroups where this originally appeared: mozilla.dev.security and mozilla.dev.security.policy. And here just another reason to sign (addon) code: http://blog.ivanristic.com/2010/02/firefox-extension-installation-process-vulnerable-to-mitm-attack-.html Apparently this is going to be fixed, the next issue will come up for sure... -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
Last I checked there definitively were some code signing certificates basically issued under the terms of If the credit card check comes back OK, issue it. It's a little while ago thought. But really. It's *hard* to do better than that, better than Send us by fax our doctored ID so that we check if you pass the bar of having minimal photoshop skills. No CA has been admitted to NSS during the last 2+ years based on such a policy and have the code signing bit turned on. Your assumption above is wrong, but if you have any knowledge please share it with us :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
On 02/08/2010 09:28 PM, Lucas Adamski: In this case perhaps - in another case you perhaps will stay with the damage and never hear from the developer. The point is even a well legitimate intentioned developer with a code signing cert could ship malware by accident. Right - and I believe that this isn't the problem code signing is intended to solve. However it does protect from tempering as Steven pointed out in the other list. If you aren't trying to make a trust decision based upon the publisher then code signing buys you very little. What it does create is a huge burden on developers that requires them in many countries to be incorporated or at least have a business license, and provide a stack of paper documents to that effect. Today you can get code signing certificates as individuals too. Sometimes that's even better than some Ilse of Man limited liability company hold by one guy and setup through online registration. Yes, but is it feasible to review every add-on? Maybe it's not such a burden - and what about modifications of existing add-ons? Are they reviewed too? It is a big burden, I wouldn't try to sugar coat it. However code signing doesn't relieve that burden in any way IMHO, they solve orthogonal problems. You are right. But perhaps it might be of help to know that this developer is the same one as last time and he signed his code. Knowing that there is a real person (or organization) behind the code might be of help too. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
On 02/07/2010 09:11 PM, Daniel Veditz: The unreviewed addons should go on a completely separate site and not show up in AMO search results, just as Firefox experimental nightly builds aren't available from the product pages on mozilla.com. Makes sense. An analogy I've used before: if you went to your favorite bakery and they were offering experimental muffins you might expect them to taste bad. You would not expect them to be laced with heroin because the shop is giving shelf space to anything dropped off at the back door by who knows who. experimental does not cover it. Another question is, how thorough is any review Mozilla performs? And with such a review and offering to download the extensions from one of the official Mozilla web sites, Mozilla effectively takes on responsibility and a certain liability. Perhaps a valid question is, if Mozilla wants/should do that. And why not off-load at least some of that burden to proper identity and/or organization validation? I would feel more comfortable if I knew that the developer could be tracked to a legal identity in case of intentional misuse. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
On 02/06/2010 08:30 PM, Lucas Adamski: I don't think it would have made a tremendous difference here. One of them was likely infected accidentally (only one version of the addon contained malware and the developer is actively communicating with us). In this case perhaps - in another case you perhaps will stay with the damage and never hear from the developer. Code signing doesn't prevent malicious code from being inserted into an addon. Yes, it makes it much harder for hobbyist developers to create addons but doesn't stop the bad guys from getting their hands on *some* code signing cert, either by stealing one or via a shell company in some foreign country. Errr...I hope not, otherwise what's the point of code signing certificates anyway. The real problem IMHO is that we allow unreviewed addons to be downloaded directly from AMO. Yes, but is it feasible to review every add-on? Maybe it's not such a burden - and what about modifications of existing add-ons? Are they reviewed too? -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
On 02/06/2010 08:42 PM, Michael Lefevre: On 06/02/2010 15:04, Eddy Nigg wrote: Isn't it about time that extensions and applications get signed with verified code signing certificates? Adblock Plus is doing for a while now I think, perhaps other should too? I don't know if more details are available than have been published so far, but I don't see how code signing would have helped. Unless I'm missing something code signing just confirms that the code comes from whoever signed it. Correct. How does a certificate prevent someone signing malicious code? No, it doesn't. But I guess you would think twice to sign (malicious) code with your name - any code for that matter. And it obviously doesn't prevent accidents and mistakes, but a certain care would be added by signing the code and probably prevent intentional cases. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox Add-ons
On 02/06/2010 10:58 PM, Jean-Marc Desperrier: On 06/02/2010 19:47, Eddy Nigg wrote: But I guess you would think twice to sign (malicious) code with your name - any code for that matter. How hard is it to sign it with a cert you bought with a stolen credit card number, using the name from the card ? A 50$ code signing certificate just brings you 50$ worth of security ... Scrap it.no CA was here admitted under these conditions for having the code signing bit turned on. I'm not saying that at some point in PKI history this wasn't done. It's not done today and fee free to publicly name the CA which does that. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Safety of extensions (DefCon presentation)
On 11/27/2009 12:39 PM, Gervase Markham: Similarly, there will be Jetpacks which work with your password store and those which don't. How do you deal with that? Just let all Jetpacks read the password store? Or have a permissions model? If you have one, what's to stop users just clicking Yes? Regarding the above specific example I believe it IS about code and not author. Access to the password store must happen in the same manner as Firefox implements it, e.g. poke for the master password every time this happens. The only solution to this problem, IMO, is to authenticate authors, not code. If you know who the author is, to a sufficient level that there's some chance of a policeman feeling his collar if he turns out to have written code which steals all your passwords, then there's an incentive for good behaviour. (This is how EV SSL certs work.) Of course, this works against anyone can author an add-on and put it on the web and have people use it... As such, this is what code signing certificates really provide and obviously I'd support that ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Another Protocol Bites The Dust
On 11/22/2009 03:10 PM, Jan Schejbal: Was anything done to circumvent this issue in Firefox? There are a few bugs open which attempt to deal with it. However the real solution will have to come from those that write the standards - they are working on it too. It must be however understood that it's mostly a server side issue and not client side (e.g. the browser). -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: A new false issued certificate by Comdo?
On 11/05/2009 07:33 PM, Ian G: Now you're getting it. It is not acceptable to simply achieve consensus and go out and burn witches coz we all like that. What's wrong with achieving consensus? Others fight for years to achieve that. Here's a suggestion from Satan. Add to clause 7: * certificates issued for internal usage must not be issued over domain names that use (insert proper langauge) TLDs registed by IANA. A separate subroot should be used for this, and the naming should be made so as to be obviously not confusing with any TLD. It's been in the problematic practices for quite some time, it's a candidate for the policy (or by proxy if it will be in the Basic SSL Guidelines). Your contributions would be perceived very differently if you would do as above. Simply say, that you think that we need to add to the policy... -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: A new false issued certificate by Comdo?
On 11/05/2009 08:20 PM, Florian Weimer: Okay, then Mozilla has got a significant problem because some CAs issue certificates for domains not delegated from the ICANN root. These CA roots should not be on Mozilla's root CA list. Correct. We are working on that by and through various means. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: A new false issued certificate by Comdo?
On 11/06/2009 01:42 AM, Dave Miller: Actually, looks like it is getting fixed. I just got this from Giganews support: 8 I agree, it was a false positive. The SSL cert looked enough like mime-encoded data to trip the filter. I've asked our programmers to look into tightening the filter to prevent this in the future. 8 Excellent! Thanks a lot for your effort! -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: A new false issued certificate by Comdo?
On 11/04/2009 09:31 PM, Florian Weimer: Does the CPS really say that? Where? If you don't mind, the Mozilla CA Policy requires under section 7: /for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request *has registered the domain(s) referenced in the certificate /or/ has been authorized by the domain registrant to act on the registrant's behalf*;/ Here is the link to the policy: http://www.mozilla.org/projects/security/certs/policy/ -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: A new false issued certificate by Comdo?
On 11/04/2009 11:13 PM, Dave Miller: Giganews says the original message got nailed as a binary post because of the included base64-encoded SSL certificate. Specially on these news groups this can happen from time to time. Is this something which can be fixed? -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: A new false issued certificate by Comdo?
On 11/04/2009 11:32 PM, Collin Jackson: I've found several certificate authorities that issue certificates for internal domains, including Comodo, VeriSign, and completessl.com. Adam Barth and I filed a bug on this issue in 2007. These certificates are easy to acquire, but I don't see how they're less secure than HTTP, so we've been advocating that browsers show a broken lock: https://bugzilla.mozilla.org/show_bug.cgi?id=401317 Hi Collin, The point with this certificate is, that this is a real, valid TLD. Second, the problematic practices already has this listed: https://wiki.mozilla.org/CA:Problematic_Practices#Certificates_referencing_hostnames_or_private_IP_addresses This item has been also taken to the CAB Forum and is discussed and hopefully included with the Basic SSL Guidelines which are in the making. Host-names and internal IP addresses provide *NO PROTECTION* whatsoever and is pure snake oil. CAs which issue such certificates deceive their customers and relying parties. In this particular issue, the above doesn't apply since this was issued to a non-existing domain name of a real TLD. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: security.OCSP.require in Firefox
On 10/13/2009 06:23 PM, Johnathan Nightingale: As for ipsCA, I find myself agreeing with Eddy's point: that the null bytes are a regrettable validation error that we should work with ipsCA to ensure they fix; but NXDOMAIN on an OCSP server that appears in issued certs is a bigger problem. I'm talking with Frank and Kathleen about options there. I think contacting the CA and understanding their situation is certain to be part of it. I think suspension of their trust bits is a possible outcome, but it's premature to talk about that before giving ipsCA a full chance to explain things. We break 6k cert holders if we do that, which I'll support if we don't have better options, but I don't see that we're there yet. Do others really feel like we've exhausted other options or that attempts to communicate with the CA are fruitless? I'd like to make two practical suggestions: A) Follow up with CRLDP finally at Firefox and implement a fail-over mechanism in case OCSP is down. For example StartCom has multiple CRLDP's at different locations for such cases. That's also important for us in case of a disaster (and recovery). Obviously it's of little help in case the software ignores it. Also obviously this doesn't allow for the current situation, it's primarily for unfortunate cases which can happen for a short time. This leads me to the second suggestion... B) File a bug for tracking ipsCA's conduct including the \0 bug and its resolution, request follow-up with the next audit which covers the period July-October 2009 (e.g. audit of the year 2009). Perform a review discussion as we do for including a CA as soon as the audit report is available. This should be processed at a higher priority than regular inclusion requests. #B is important because we are already month after the alleged bug happened, plenty of time to get the act together. I think this warrants some actions, a review and renewed confirmation of compliance might be a good thing to do in this case. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: OCSP responder key/certificate thoughts
On 10/13/2009 11:26 PM, Kyle Hamilton: I'm trying to figure out how much of the OCSP slowness and server underpowering is due to the sizes of the keys used, or limitations of the HSMs (and drivers) that these systems are using. Kyle, it's a myth, there are CAs having very responsive OCSP responders out thereVerisign claims one billion responses per day, I know that StartCom pushes out Gigabytes of responses per day and Comodo probably a couple more. It works and OCSP is meant to be fast, not slow. Being a tool to provide ONLINE and instant information as compared to CRLs with their lag. Having said that, CRLs depending on its size probably requires more resources than an OCSP responder. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: security.OCSP.require in Firefox
On 10/12/2009 12:13 PM, Rob Stradling: Comodo's OCSP Responder infrastructure handles many hundreds of OCSP requests per second. We are confident that our current servers could easily handle several times as much traffic, and we can easily add more servers when we need to increase the capacity still further. I think StartCom is in a similar situation. As increase in demand doesn't happen usually over night, correct assessments should guaranty proper functioning and adequate allocation of the resources. Obviously it's a far cry compared to a non-working, non-accessible and non-existing advertised OCSP URI. VeriSign claim to handle over one billion OCSP requests per day. If their servers are woefully underpowered, surely we'd have heard about it by now!? Perhaps the time has come for the browsers to force all of the other CAs to take their OCSP responsibility seriously, by requiring OCSP by default. Amen! That CA clearly fell short of this requirement. I don't think this CA issues EV certificates. Which is perhaps we one can draw a difference also regarding regular certificates as well. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: security.OCSP.require in Firefox
On 10/12/2009 04:11 PM, Rob Stradling: On Monday 12 October 2009 14:46:28 Eddy Nigg wrote: snip That CA clearly fell short of this requirement. I don't think this CA issues EV certificates. Boris and I were referring to the GlobalSign EV cert for AMO. Oh, I meant ipsCA. GlobalSign at least has some OCSP responder capability, right? It's not something which can't be correct...some more knowledge and horsepower can help with that. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: security.OCSP.require in Firefox
On 10/12/2009 05:19 PM, Daniel Veditz: The surprise is that it is occasionally possible. I wouldn't characterize it as easy or it wouldn't be such a big deal each time someone finds a way to do it. If you know of a bad CA please let us know so we can investigate and remove them from the product if necessary. It must be understood that some issues can happen, nobody knows that better than our dear developers of the Mozilla software. I think nobody taunts that CA for their null bug, things like that can happen. It's however total negligence on part of that CA to advertise OCSP in the certificates and not having any means to live up to that promise. Revocation is one of the last defenses CAs have and that's what it's here for. It's also a critical part of any WebTrust audit. This is where the big failure is and I think it requires further investigation. Besides that, I think despite some wrangling and shuffling, OCSP will be a requirement for any CA pretty soon, the unified standard requirement will make it easier for browser vendors to hard fail. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 03/04/2009 03:36 PM, Boris Zbarsky: Florian Weimer wrote: Most users are not subject to MITM attacks This may or may not be true given the prevalence of wireless networks out there... we've had a number of reports of in-the-wild MITM attacks by wireless network operators. Yes, many routers and WiFi products are configured by default to allow such attacks. I can confirm more complaints arriving also at the CA I work. Yes, most of these are trying to phish sites that are normally SSL, so we should be making it very easy to tell when a site is not SSL or doesn't have the expected hostname over SSL. Making non-SSL sites look more like SSL ones even by similarly highlighting the hostname is asking for trouble. Actually this is correct too. How can we indicated to a user that this site really should be secured? When do we expect SSL? On submit or on password fields in a form (as the starting page should be really secured too, not only the POST target)? Could there be indicators which makes the user aware that this is not an SSL secured site (since regular http doesn't throw neither a warning nor any other annoyance)? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 03/04/2009 04:18 PM, Jean-Marc Desperrier: Eddy Nigg wrote: [...] When do we expect SSL? On submit or on password fields in a form[...] IF page contains form AND form contains password field THEN flash insecure form warning Could be done. But there would better be a cross browser agreement on this. And coupled with a way to offer (low/no)-cost SSL to everybody. The later exists already for a long time (and you most likely know about it): www.startssl.com -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 03/04/2009 04:28 PM, Johnathan Nightingale: no website can spoof the EV appearance of the site identity button and, with the ssl_domain_display pref set to non-zero, (and appropriate care given to IDN issues), they can't for regular SSL either. Right, and I'm extremely glad that we are going this route. I also suggest to look on ways to signal to the user when we really expect a secured site (see Jean-Marc's message). It's extremely annoying to confirm every form submission when unsecured (it's my current setting) - if we could indicate only on password fields or other suspicious combination's (as phishers would most likely start avoiding the password tag altogether), it would be a useful indicator. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 03/04/2009 04:48 PM, Johnathan Nightingale: This kind of thing? https://addons.mozilla.org/en-US/firefox/addon/8128 It looks nice! I think it should also turn red if the starting page is unsecured, not only the landing page, but technically this would not be correct. However I'd fee uncomfortable to click on a form without prior knowing what to expect on submit (which CA or an exception). Specially for the EV sites it would be useless to know about it only after hitting submit. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 03/03/2009 04:30 PM, Jean-Marc Desperrier: But, and as the link Eddy just reported shows, the attack is far from being only for SSL. I think we should reconsider the options available to make the domain name more visible for http connexions. What about a white version of the hostname display for http sites ? YEAH! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 03/03/2009 05:51 PM, Boris Zbarsky: Jean-Marc Desperrier wrote: But, and as the link Eddy just reported shows, the attack is far from being only for SSL. I think we should reconsider the options available to make the domain name more visible for http connexions. What about a white version of the hostname display for http sites ? Wait. Why does the domain matter at all for non-SSL connections? It's not like we have any guarantees against MITM here... If we train users to watch out for positive SSL indicators and warn before submitting any information I think this should not be necessary. However I could imagine a re-vamped UI where the actual domain name is more prominent and the real URL less important for the average user. Something like this: ++-+ || +-+ |SSL | DOMAIN.COM | URL| || +-+ ++-+ The URL part might be only optional or hide and reappear on mouse-over. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
Subject was [Fwd: Facebook message - Received Messages Quickly] I've received it a few minutes ago. The URL doesn't us SSL, but it shows exactly what I posted in this thread not long ago...see forwarded message below: Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org/ Jabber: h...@startcom.org xmpp:h...@startcom.org Phone: +1.213.341.0390 Original Message Subject:Facebook message - Received Messages Quickly Date: Tue, 3 Mar 2009 00:23:25 + From: Facebook Message Center messa...@facebook.com To: certmas...@startcom.org Personal Message To You From your friends at facebook video server: Subject: Review - My family invite you out for lunch, don't hesitate! Read Description for a link to part 1 Original Video added by group member. You will see a link to Open Your Personal Message Manager. Selecting this link will take you to the log in page where you can browse new messages. Proceed to open full message text: http://login.facebook.permissions.videomessageid-q9k6d8abp.sessionnewid83.com/home.htm?/CEBMainServlet/LOGIN=v1yzhoqvrtc8gmf Sincerely, Maura Kent. Facebook 2009 Message Center. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Work-around for Moxie Marlinspike's Blackhat attack
On 02/27/2009 12:15 PM, Jean-Marc Desperrier: - Click to modify the network.IDN.blacklist_chars preference - Click inside the preference content and paste the character from you clipboard. Do not overwrite any of the characters already present ! Very useful. Besides that the original site couldn't be found either. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 02/26/2009 01:49 PM, Jean-Marc Desperrier: Just one thing : The use of a wildcard certificate was a misleading red herring in the implementation of the attack. Yes, I've been saying it all along. What's truly broken is that the current i18n attack protection relies on the checking done by the registrar/IDN, and that the registrar/IDN can only check the second-level domain name component. Dhuuu :-) Once they have obtained their domain name, attacker can freely use the third-level domain name component to implement any i18n attack they want even if no wildcard certificate is authorized. Correct in case the CA doesn't do any additional checking. IMO we should require it. This is not to say that wildcard certificates are not bad, evil, anything Wild cards are not evil and certainly not bad. Wild cards are terrific and a real time saver at least. However it requires a certain responsibility and I'd like to see better verification procedures by CAs. with regard to the attack. So it needs to be discussed on the security group, not crypto. It should be discussed in the new m.d.s.policy group IMO. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 02/23/2009 02:35 PM, Jean-Marc Desperrier: - I don't expect there will be any effort to try to stop CA from issuing dangerous wildcard certificates, since it won't solve the problem at large. This isn't the cure of the problem, wild cards are very useful! The problem is the validation requirement for wild cards. I think and believe that considering current business practices and fees charged for wild cards it is reasonable to require at least identity validation - similar to the same requirement for code signing. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 02/20/2009 05:55 PM, Jean-Marc Desperrier: Get a domain-validated SSL wildcard cert for *.ijjk.cn Yes, it's surprising how some of such attacks seem obvious *after* they have been done, but it takes so long to realize it can be done. Not exactly. I found it striking because we've been discussing it (look for Comodo inclusion request of approximately April last year), however my concerns were not addressed really (besides adding it to the problematic practices which had no effect on the CA in question anyway). The md5 collision between a normal and a *CA* certificate was similar for me, how the fuck did we not think earlier, when it was already obvious someone would soon create a collision between two real md5 certs, that they just had to do that to make the attack really effective. Right, even though I still consider it to be an effort usually not done by the cheap phishers. This being said : Is there already a bug open for this ? The only thing that stops me opening it myself is that it might already exist but be security restricted. For which one, MD5 or DV wild cards? For MD5 there is a bug, for DV wild cards not. PS : I think this discussion should be on mozilla.dev.security since it's about a security vulnerability, not crypto and not security.policy. Does everyone share my opinion ? (I'm setting the follow-up there) Incidentally it should be held on the new mailing list we've got security+policy issues (mozilla.dev.security.policy), not on security I think. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: definition of compromised
On 02/05/2009 04:09 PM, Ian G: OK, I see that. I find a definition of compromise as interesting. I did observe that argument over somewhere else when one protagonist said compromised means we can't show it isn't revealed, and someone else said compromised means we can show me it is revealed There is another option which is suspected key compromise. It makes it pretty clear... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: New Trojan for Firefox
[EMAIL PROTECTED]: Hi All! Unfortunately I have to inform you about new trojan developed for Firefox. It can be found at http://rapidshare.com/files/127049095/InstallationFF3Ultimate.exe.html (WARNING! Contains malicious code!!!) The trojan is published in Internet as New Ultimate upgrade to Firefox 3 adding new features. After starting this trojan collects all passwords infromation stored in FF and it's add-ons and then sends it bia e-mail to [EMAIL PROTECTED] and possibly via ftp as well. I have sent this trojan to AVG, Avast, Kaspersky, DrWEB, Avira, NOD, BitDefender, F-Secure, McAfee Virus Labs, at the present moment DrWeb lab added it in virus bases. Be carefull with unknown content in Internet! Hope Development Team will change something in FF 3 to resist to such trojans and to improve security. A blacklist of known add-ons would be helpful. Or perhaps require code signing of the add-ons... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Boris Zbarsky: Could maybe try to brute-force the old key until they come up with a forged certificate that an SSL library accepts? No, not really. It requires the possession of the certificate with the weak key signed by a CA. The whole point is that all the weak keys come from a limited keyspace, right? That's correct. This allows to find the ~100,000 possible keys per key size the right one. Who said anything about Mozilla knowing? The idea here would be to have the browser detect it and refuse to go to the site or something; no need to communicate anything to Mozilla. Oh, that would technically not be possible I guess. Searching for such keys dynamically could take hours per key, hence previously created keys are used. They would need to be hosted somewhere and compared to. That's why Mozilla would know about which public key was used (the least). The premise (and a not unreasonable one) is that such a list can be generated if needed. I expect that Mozilla will not come up with the resources for it. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Gervase Markham: Eddy Nigg (StartCom Ltd.) wrote: Oh, that would technically not be possible I guess. Searching for such keys dynamically could take hours per key, hence previously created keys are used. They would need to be hosted somewhere and compared to. That's why Mozilla would know about which public key was used (the least). As https://bugzilla.mozilla.org/show_bug.cgi?id=435082 explains, we would have a locally-stored blacklist. Locally stored where exactly? Do you have an idea how big such a list which would cover just the most commonly used key sizes would be? Doesn't sound feasible to me, hence I thought you were talking about some kind of lookup service. What makes you expect that? Such a list of weak keys already exists, anyway. http://metasploit.com/users/hdm/tools/debian-openssl/ Yes I know obviously. That's exactly why I think it's not in the cards. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Gervase Markham: Eddy Nigg (StartCom Ltd.) wrote: Locally stored where exactly? Do you have an idea how big such a list which would cover just the most commonly used key sizes would be? Doesn't sound feasible to me, hence I thought you were talking about some kind of lookup service. Read, the bug, Eddy! :-) There are size estimates in it. If you think they are wrong, post better figures, with your working. I've read the bug previously, which news should I find there? Some suggestions were somewhat optimistic I think, but don't have the time to prove it otherwise. But if we are at it this bug already than I'd recommend re-reading the comments from Nelson. Additionally, getting the list from Netcraft sounds to me most appealing if you want to do anything useful within reasonable time. The question is, if they'd give it to you... Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Hi Gerv, [Off-topic] For one I must notice the incredible inconvenience in working with Bugzilla and this mailing list. It happens many times that the same issue is discussed and tracked at different bugs in parallel. I'm a CC bug 434128 and just got aware of bug 435082. Can you tell me the best way how to KNOW about such bugs which are related and might interest me? I can't spend my time searching all day long and on a daily basis for new bugs. I guess there is a formula or something...? [On-topic] Here is how I evaluate the situation. Debian users are generally more aware and more informed about problems such as these in relation to other server products (which includes obviously all brands). This situation doesn't apply always on shared hosting. StartCom offers two ways of creating server certificates, one way is to create ones own private key and submit a CSR, at the other way the Certificates Wizard creates it on behalf of the client. The majority of CSR submissions are for IIS servers with a small minority being for Apache users. The rest creates the keys at StartCom. Those keys aren't subject of this or similar bugs. Out of the Apache users which create their own CSR (and hence private key), Debian users are again a minority, at the most 10%. Judging from the revocation requests we received, at least one third of those requested revocations. There is about one third which didn't succeeded in installing the certificate or for other reasons haven't made use of the certificate (for example realizing the need for a dedicated IP address etc). Therefore we have about another one third which might be still using a weak key. This boils down for very few still affected sites, probably less then 1.66 %. Since all certificates issued at StartCom are valid for one year only, the risk assessment didn't warrant for a full scan of all public keys considering the effort which must put into such an effort. I expect the situation to be similar at most CAs. See also inline comments. Gervase Markham: Firefox 2 does not have OCSP turned on by default. Both browsers support CRLs, but do not have the capability to download CRLs from URLs listed in certificates. This is a known shortcoming of FF2 and inherits higher risks then weak keys. That's because if a certificate is revoked because of a weak key it was most likely requested by the subscriber himself and he wouldn't continue use of the weak key anyway. Hence this would make only sense if CAs would revoke such certificate unilaterally. However, because CAs are not actively contacting their customers, many weak keys will still be being used, and we'd have no way to tell if there was an MITM going on in that case. That's correct. Lists of all the weak keys exist - we could create a database of the first 8 bytes or so of the hash of each and get NSS to check it when it sees a key. This would involve a code change to NSS and a security update. We'd probably want to download the list of weak keys rather than ship it with the update. NSS would then return an error to the application if a weak key was found, and the connection would abort.[3] - Modify NSS/Firefox to detect weak sites I would cite privacy concerns with such a scenario. If we can get a fairly complete list of vulnerable sites How do you intend to find them? We could use our contacts with CAs to try and convince them to change their position on customer contact. - Publish a CA hall of shame And what if a CA refuses to comment or provide this information? - Turn on OCSP in the next Firefox 2 security release This might help in the short term, with the same limitations as listed under Do Nothing for the Firefox 3 update. But Firefox 2's OCSP support is not as complete; it doesn't do caching, and it hard-fails. So we might melt the OCSP servers, and that would severely degrade the user experience because no-one could make SSL connections. Yes, that's not a good option really. - Ship a Firefox 2 update with some built-in CRLs Again, see above that this makes only sense if an affected site owner would refuse to replace the certificate because of somebody detected a weak key. I haven't encountered such a situation yet and doesn't make much sense. Suggestions? Even if it doesn't sound so good, do nothing is the right thing to do I think. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Debian Weak Key Problem
Boris Zbarsky: But the MITM attacker could use it to impersonate the site, which is the whole point. Yes, in case the attacker managed to get a copy of the previously used and signed key. Not, in case the subscriber managed to change his cert before. - Modify NSS/Firefox to detect weak sites I would cite privacy concerns with such a scenario. Like what? I wouldn't like Mozilla to know which sites I'm visiting (including non-publicand, eheeem all the others ;-) ) How do you intend to find them? web-crawlers are not exactly rocket science. Nope, but needs quite some resources in order to receive some valuable results within reasonable time. So the real question is: given an SSL handshake, how does one tell whether the site is vulnerable? I believe there are ways to detect this, based on other mails I've seen going through. Yes, certainly, but even this might require quite some CPU cycles. And what if a CA refuses to comment or provide this information? Provide what information? Whatever they decided to do in respect of this threat. If there is a list of vulnerable sites, there is a corresponding list of CAs, since the site certificate says who the CA is. Correct, but it's a big if for now. Again, see above that this makes only sense if an affected site owner would refuse to replace the certificate because of somebody detected a weak key. Again, I don't think that's correct. Well, actually the Debian folks are rather security conscious...in relation to that they are also the ones preferring Icewiesel and Cacert because it ain't free enough, with purified openssl for the topping ;-) That's the perspective of the CAs (including yourself), sure. We know that already. I had no clue what other CAs decided in that respect and I offered our estimates and decisions on this subject. That's not something coordinated. I'm open to suggestions as always. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: [Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]
I just wonder why the h*** Google anti-phishing tool still allows me to go to http://comerica.connect.tmconnectweb.login.cgi.msg5984.time32491989.webbizcompany.c1b9r62whf314lx53xq.secureserv.onlineupdatemirror66272.comerica.certificateupdate.cxv32.com/logon.htm Should they have blocked the cxv32.com domain already all over the place? Tested with FF3 and FF2... -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: [Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]
Eddy Nigg (StartCom Ltd.): I just wonder why the h*** Google anti-phishing tool still allows me to go to http://comerica.connect.tmconnectweb.login.cgi.msg5984.time32491989.webbizcompany.c1b9r62whf314lx53xq.secureserv.onlineupdatemirror66272.comerica.certificateupdate.cxv32.com/logon.htm Should they have blocked the cxv32.com domain already all over the place? Tested with FF3 and FF2... Oh, and just by the way...now that we are at it...How easy it would have been for cxv32.com to get a wild card certificate from some of the CAs in NSS, making the phishing attack even more convincing. The theory that we have anti-phishing tools simply doesn't hold the water, an argument which was used multiple times against any strengthening of the Mozilla policy. A sub domain name like the one from above most likely would never have been issued, not even by the CAs which issue domain validated wild cards, at least this sub domain name would have raised enough attention if the CA has also some personnel there... -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: How to get a free certificate
Jose Luis: As mentioned in http://www.mozilla.org/projects/security/components/signed-scripts.html Javascript must be signed with certificates when trying to enable priviledges. How do I get a free certificate for this. Hi Jose, As far as I know there are none. It might be that GoDaddy still gives out code signing certs for open source projects for free (so I haven't seen for along time about it, they might have discontinued it). Besides that, it's highly unpractical to sign javascripts and html pages (as all of them must be signed and placed into the jar) for most sites, since todays requirements and sites are mostly not static, but dynamically assembled on the server side. In my opinion, the security concept of the Mozilla browser(s) is not really usable... :-( -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Hi Gerv, Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: Or I could simply push the Backup button of the certificate viewer? Except that in this very specific case, the copyright of the different CA certificates are perhaps that of the CAs themselves. However distribution of the CA root is many times part of the CP/CPS of the various CAs and most of the time encouraged (The relying party should be able to verify the signer and CRLs etc)? I'm afraid I don't understand this question, if it is a question. It's not a question, it's a statement ;-) The obligations of the relying parties are often defined in the CP/CPS, which requires the RP to perform various actions, like checking the validity of the certificates, its status (CRL) etc. The RP must have the CA root to perform these actions...therefore I assume that publishing and usage of CA roots are not only a privilege but a requirement. Actually, apparently I was wrong about that. certdata.txt is compiled. I know, but an extraction of the certificates from that file and loading the result of this extractions at run time makes a difference I think. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Hi Gerv, Gervase Markham wrote: The copyright status of the data does not change as a result of you obtaining it from us as opposed to obtaining it directly from the CA. Or I could simply push the Backup button of the certificate viewer? Except that in this very specific case, the copyright of the different CA certificates are perhaps that of the CAs themselves. However distribution of the CA root is many times part of the CP/CPS of the various CAs and most of the time encouraged (The relying party should be able to verify the signer and CRLs etc)? If you or your lawyer are concerned that the data may be tainted by being passed through Mozilla CVS, then you should re-visit each CA and download their root certificate from them directly. No, this isn't my concern. What's the problem with being bound to the tri-licence anyway? Choose the MPL, and then the licensing conditions don't affect any of the rest of your code. certdata.txt is a self-contained file. Right, the problem is, that some projects use different licenses then one of the three, making it under certain circumstances incompatible. However since the content or extraction of the certdata.txt file can be loaded at run-time as opposed at compile time, this problem could be solved that way easily. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Frank Hecker wrote: Indeed, although there are in fact CAs that attempt to get you to sign up to some sort of agreement before downloading their certs. (I can't remember at the moment exactly what they apparently were trying to accomplish by doing this.) Perhaps it was this one? http://www.verisign.com/repository/roots/pca_certificate.html -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
I very much appreciate your thoughts and advices! As I'm trying to help another open source project, which uses a different license than the ones Mozilla offers, I'm not going to pursue this matter much further, except giving them the same advices you gave me. Thanks a lot to you all! Frank Hecker wrote: Eddy Nigg (StartCom Ltd.) wrote: So is the assumption correct, that if I or anybody else extracts the CA certificates from certdata.txt and uses the result of it, isn't bound to any licensing constraints, similar as the content of a web page which the browser displays isn't part of the software itself? Eddy, if you want a definitive answer on this you really need to consult a lawyer. All that Gerv, Nelson, I, or anyone else can give you is our personal opinion, which to be honest with you is worth exactly zero should you ever get into a legal dispute. If you're interested in pursuing this further, I'd be glad to correspond with you via email to give you and your lawyer my personal opinions on the situation. Frank -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Reassessment of sub-ordinated CA certificates
During the last few month many issues concerning sub-ordinated CA certificates of CAs, considered for inclusion and CAs already included in NSS, have come up at this forum. Today exists a situation where the Mozilla CA policy doesn't provide enough guiding and definition, because the policy was defined originally with assumptions not holding the water for todays realities (freely quoting Frank here). I have the feeling that everything related to sub-ordinated CA certificates has reached dangerous levels and makes it almost impossible to clearly know if the Mozilla CA policy is still protecting the user of the various Mozilla products. There are and were various situations and setups of different CAs from: - governmental institutions issuing sub CA certificates to authorized CAs, - sub CAs shipped via Internet download by the issuing CA, - CAs which are chained to such an extend, that it's hard to believe that the CA which has its root in Mozilla, has any control over the issuing entity, - sub CAs without any clear policies in place, - Auditing of said CAs simply non-existent and more... Additionally, in a short time, various CAs will be considered for upgrading to EV status, including at least one CA with more than _124_ sub ordinated CA certificates, of which all of them are supposed to receive this status. This is such a wide spread phenomena which has outgrown our current policy to such an extend, that _I'm requesting hereby and now to have thorough review of this situation and reassessment_ of the Mozilla CA policy concerning everything related to sub-ordinated CAs. Please note that I'm not making any suggestions and arguments right now about what a sound policy should be, rather I believe that it requires an extensive assessment of the current situation and related discussion in order to define the best definitions. But there is going to be an unbelievable, explosive situation also in relation to EV upgrades which perhaps nobody of us has foreseen, a situation which goes completely against the spirit and objectives of EV itself - the major reason why Mozilla has supported this effort in first place! In connection of this request, I'd also like to have cross-signing between CA roots defined in the Mozilla CA policy, since cross-signing might touch a similar field, which could at some point land us in a similar situation of loosing control. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Thanks for your answer! Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: Since sometimes there are some licensing concerns with the certdata.txt file, I wanted to know exactly what one is allowed to do. If for example by merely extracting the CA certificates with a tool like http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl still requires the resulting CA bundle to be bound to the tri-license of Mozilla? Or can I simply extract all CA certificates from the browser by exporting them? I think the correct position is that the certdata.txt file is data used by Mozilla, rather than part of the browser itself. It's a grey area. So is the assumption correct, that if I or anybody else extracts the CA certificates from certdata.txt and uses the result of it, isn't bound to any licensing constraints, similar as the content of a web page which the browser displays isn't part of the software itself? The copyright in the certificates technically rests with the CAs, but it would be a very strange CA which forbade you from shipping their certificate in your product. I'm not sure what the legal position would be there. At this stage I mostly care about the Mozilla licenses and need a clear answer, if a third party can make use of an extract of the certdata.txt. Personally I would believe this to be the case, but I want to have that confirmed in some way in order to let other products make use of it without being bound to the tri-license of Mozilla. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Extract of CA certificates
Many times applications ship a CA certificates bundle with the product. Many times they are derived or extracted from the certdata.txt [1] file or simply exported from the browser. Since sometimes there are some licensing concerns with the certdata.txt file, I wanted to know exactly what one is allowed to do. If for example by merely extracting the CA certificates with a tool like http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl still requires the resulting CA bundle to be bound to the tri-license of Mozilla? Or can I simply extract all CA certificates from the browser by exporting them? Obviously the CA certificates themselves aren't property of Mozilla, but of the CAs, I wonder if the certdata.txt and/or and extraction from it changes anything. Does Mozilla in one of the cases still retain the copyrights? Can a waver be granted for this specific file? I simply don't know the answer, but try to help another project solve an issue with this, which affects many other applications. Thanks! [1] http://lxr.mozilla.org/seamonkey/source/security/nss/lib/ckfw/builtins/certdata.txt -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Mozilla isn't trusting its own certificates
Boris Zbarsky wrote: Tony Mechelynck wrote: If I try to add it, I can't, because SeaMonkey asks me for my LDAP username and password, and AFAIK I don't have any. Right. Only MoCo employees and contractors do. Note: If this remora-reskin URL is really some restricted site accessible only to a select few people Looks like it is, yes. It's not a security restriction, though, just an internal server kind of restriction. And yes, posting internal server stuff in bugs is bad. Strongly reminds me of the Netscape days. :( Nevertheless you (Mozilla) might consider securing such stuff with certs from http://www.startssl.com/ , even so wild cards aren't free usually, we could arrange that. CN = Mozilla Root CA OU = Mozilla Corporation Root Certificate Services Reminds me of some other CA using the Root word in their certificates ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
CA policy and EV
This post is about bug reports 383183 and 398944 and the relation of EV certificate support in the UI (and to a lesser extend in the NSS library) and the Mozilla CA policy (http://www.mozilla.org/projects/security/certs/policy/). Currently the Mozilla CA policy doesn't define EV's minimum requirements, acceptable criterion or trust bits. In fact the policy currently supports only three types of certificates: * SSL-enabled servers, * digitally-signed and/or encrypted email, /or/ * digitally-signed executable code objects; The policy doesn't define _any_ distinction between certificates as such beyond the types mentioned above. Neither does the policy define the criteria if, when and how a certificate should be treated differently (as suggested for EV certificates) in the UI. Neither does the policy define minimum requirements for EV (section 7). Neither does the policy define the criteria for CA operations for EV (section 8). Section 14 of the policy doesn't support EV. Currently ANY/NO certification authority with a root certificate in the NSS CA in the Authorities DB might be eligible to issue EV certificates - or not - according to this policy. EV support should not be enabled anywhere in Mozilla products until a binding policy governing EV certificate support is defined and/or the Mozilla CA policy is modified in that respect. In relation to bug 398944 the policy requires CAs to submit a request themselves (section 5 and following) and decisions are taken through a public process (section 2). More than that I was told that the CAB forum refused or is unable to provide a list of so called EV issuing CAs. I suggest to close bug 398944 because the bug is simply not relevant nor doable from a practical point of view in addition of not being compliant with the Mozilla CA policy. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Updating Mozilla CA certificate policy to address EV certificates
Frank, thanks for addressing this issue! Frank Hecker wrote: As noted in the bug, I think an EV-enabled root CA cert is simply a special case of root CA certs in general, so we don't need a whole new separate policy. At the same time I don't want to revise every section of the existing policy, and if possible I'd like to avoid changes that necessitate renumbering and reorganizing the current sections of the policy. I'm therefore leaning toward having an EV addendum to the policy, and putting all the EV-related stuff there. Then we could simply modify section 6 (We require ...) to add an additional paragraph pointing to the addendum. This would result in a version 1.1 of the overall Mozilla CA cert policy. I also think an extension might be the better thing to do. There might be more changes in the future (initiated perhaps by the CAB forum) which would require more edits, additions and changes. This would leave the current CA policy mostly as is now and in the future. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox 2.0.x: tracking unsuspecting users using TLS client certificates
Arshad Noor wrote: My understanding of the TLS protocol is that the browser only sends the certificates signed by CAs that the server trusts; are you saying that the protocol allows for asking ANY certificate from the browser cert-store, regardless of who signed it? Yes, one can configure a web server to accept ANY certificate for client auth. -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Firefox 2.0.x: tracking unsuspecting users using TLS client certificates
Arshad Noor wrote: They would know the CA that issued the particular client certificate and include it in it's Request/Not require client auth message. Actually funny that I never thought myself about such an option. But a competing CA could harvest the email addresses, which are usually present in client certs, of the competition and spam them for their services...good thought ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: nsinstall: Command not found
Thanks for the tip! I didn't knew that... Nelson B wrote: Eddy Nigg (StartCom Ltd.) wrote: Does anyone know what the issue might be when trying to build from trunk? After checkout and building browser or mail static I'm getting: gmake[6]: ../../../config/./nsinstall: Command not found See http://lxr.mozilla.org/seamonkey/find?string=nsinstall.c There seem to be 5 versions of this program in the source repository. I don't know which one of them you need. (I use the one in coreconf for NSS) -- Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV and mixed content
Gervase Markham wrote: I was giving the example of e.g. Google AdWords, where content on your site is served from a 3rd-party site. So not all of the site can be served by the same certificate. Parts will be your certificate, and parts will be Google's. OK...understand...Your example above raises another few questions: 1.) Are Google AdWords secured by SSL to start with? 2.) Should secured pages include such content as third party adverts, third party analytics and other stuff which might track movement and content to a third party? Personally I think this would be a basic breach of the initial purpose of privacy and encrypting content. I'd rather not supply my personal details to (secured) site which has all kinds of third party scripts included... To all of my knowledge Google Analytics and AdWords aren't secured by SSL and inclusion of it would downgrade regular SSL connections (broken lock) anyway. So perhaps the initial question of this thread is really important and I suggest to require same certificate (or at least same level) per site. It makes sense in my opinion... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV and mixed content
Justin Dolske wrote: That doesn't seem all too different from a vanilla-SSL site having an XSS hole. Mhhh...if the site contains unencrypted content, then the browser notices it. If the parts are served by a different site (and certificate) there is no notice. However the issue here is about EV or non-EV (if there will be any distinction), which would make a difference. The same might be true if we'd make a distinctions between other different levels of verification methods. I'm not sure how that could be explained to a user in a meaningful way, either. I'd also be wary about building the impression that content served under an EV cert is somehow more trustworthy, Hehe...we try to avoid the trustworthy word in connection with EV (and certs) ;-) Also, a more practical concern would be that if existing an existing SSL site is already linking to SSL content under a different certificate, then upgrading to an EV cert would break that. That might just be education issue for purchasers of EV certs, though. From the site operator perspective I don't see any reason why a site shouldn't be served by the same certificate (or same level). If certificates are going to be mixed, then I think it should be downgraded to regular SSL, very similar to having the broken lock in the address bar. Like this site owners take care of correct installations. Similar, if you have a valid certificate and mix content from a site with a self signed certificate, the browser complains. Guess something like that should happen here as well (i.e. downgrade). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV and mixed content
Gervase Markham wrote: Right. But allowing this makes it possible for the identity presented to not be the identity of the owner of the content. Correct! That might actually lead to the idea that we should require that all the content comes from the same company (O field). But that would be fairly extreme. Oh no! There can be multiple certs issued by the same/different CAs and different levels with exactly the same organization name. That's not a good idea in my opinion, even if the different certificates indeed would belong to the same owner - we'd like to know if something on the same site is served by a different level then claimed originally. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV and mixed content
Lets suppose a web hosting company acquires an EV cert and provides for its clients some nifty re-write rule to let appear the site as EV verified, but the actual content is served in a iframe - from the clients regular SSL secured site. Which answer would you propose to your question below? Obviously this is only important if a distinctions is made between EV and others... ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 Gervase Markham wrote: As I'm not sure of the way the proposed implementation for EV indication works, I don't quite know who to address this question to. I'm hoping the right person is reading :-) At the moment, if a web page has some http and some https elements, Firefox (rightly) complains. You only get a lock, and a lack of warnings, if all of the page elements were served over https. Will whatever NSS or PSM flag is set to say this page has an EV certificate only be set if _all_ page elements are served from a server with such a certificate? Apparently, at the moment, IE displays the green bar if the top-level page is EV, and the rest is normal SSL. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Gervase Markham wrote: It's a fair question. I agree that communication about the plans could be improved. I'll think about how best to do that. After some hard thinking by myself I'd suggest the mailing list and bugzilla as commonly used and established communication paths... :-D -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CAB Forum meeting report
Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: Is there a way to have them commit to that in some way or form? And what if they'll just say: Well, we looked at it and it's not possible after you already voted in favor? I think it's rather unlikely that they would say that, given that we (i.e. Frank) have done our own analysis of equivalence and they are pretty similar. This work will take some time, and we don't think it's correct to hold up the approval of version 1.0 over this issue. I understand that it will take some time and effort, and I didn't expect it to be part of the Guidelines right now. Some sort of formal or informal commitment, to which Mozilla could refer in future might be fine. I think, that the statement from the previous mail - *to separate the WebTrust EV audit criteria out, so that other auditors could audit against them* - would pretty much reflect and be in line with the nature of Mozilla as an organization and the Mozilla CA policy, which was specifically created by Frank and the community to allow that type of openness. Gerv, maybe you want to update the page at http://wiki.mozilla.org/User:Johnath/EVDraft13ReviewComments in that respect? Because it says currently: /The representatives from WebTrust and the audit firms also said that they were going to do an equivalence analysis between WebTrust and ETSI to see whether one could do an WebTrust EV Audit on top of an ETSI audit./ This is certainly not the same, if you compare both statements. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Gervase Markham wrote: Like everything, it's a trade-off - keeping revoked certificates in CRLs has a cost (download time and bandwidth) Sorry, I forgot to mention that a revoked certificate is worth about 30 bytes in a CRL. Just to get about the proportions -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Gervase Markham wrote: If revoked certificates have to be listed even when expired, that means that expired certificates have to be revoked if the private key is compromised. Yes, I would suppose that. Or a private key has to be destroyed correctly in first place. So, the certificate holder has to continue to keep the key secure even after expiry. Absolutely! First of all a private key can be reused many times over for new certificate requests. Actually you can use the same private key for hundreds of certificates (not common practice but still possible). If a private key is compromised after a certain certificate expired, than this key could be still misused...Or lets try it the other way around: Please publish the private key of the web site mozilla.com or microsoft.com after the certificate expires next time...will you please? Revocation of a certificate is not something which should be taken lightly - it certainly isn't equivalent to expiration. No-one is saying it is. But it is also pretty unlikely that a certificate would be revoked close to its expiration date. And what if it does happen? If a certificate is issued incorrectly, for example, these sort of things tend to be discovered rather quickly (like when the phisher sets up his site). And what if not? They will get smarter too perhaps, so phishers aren't interested in this..but some real crime would... Can you give a plausible and specific scenario where keeping certs in CRLs significantly past their expiration date would prevent some evil activity? Sure! 1.) Supposed the certificate was issued to a party not eligible for this type of certificates (i.e. a reason for revocation whatever the cause), the owner of the certificate can continue to use the certificate in question (after it expired). All a visitor will see is, that the certificate expired. Do you know how many computer savvy users continue to trust that certificate, not talking about the standard user who doesn't have a clue? The computer and Internet savvy will say: Oh well...the certificate just expired a few month ago...that's fine, I can still trust itafter all it was issued by XYZ and even an EV certificate... 2.) Supposed the private key was stolen from the owner (maybe by some disgruntled admin of the company or some criminal working at a hosting company perhaps)...Supposed this was recognized correctly, dutifully reported and the certificates was revoked. But as soon as it expires, it can be used againall what would happen is a warning message that it expired...which isn't really the same! The fact that connections to expired certificates are allowed by most if not all browser vendors contributes to this problem, if this certificate is removed from the CRL...than it's just an expired certificate which was once valid, compared to a certificate which is actually revoked. You're never satisfied, are you, Eddy? sigh What happened at the meeting was a big step forward towards allowing non-Webtrust auditors to do EV readiness audits. Well, I was also reading your CAB Forum meeting report and it's indeed a step into the right direction...But still, I think the principal question about the character of this organization just remains. Currently only webtrust accredited auditors can perform the EV audit if I understood correctly...(Correct me if I'm wrong). I can understand, that webtrust and its accredited auditors want to protect their investment, but our agenda is a different one and obviously I don't have to be satisfied with it. But what really surprises me is, that why such principal and important decisions about the type and nature of the proposed forum weren't made at its founding? Why weren't openness (in respect to participation, audits, etc) one of the key conditions for Mozilla? Crawling now back and trying to open it up is obviously much harder and I congratulate you for every success you achieve. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Please allow me to comment on a few responses... Gervase Markham wrote: Following discussion on the CABForum email list, a new draft, a two-day face-to-face meeting in San Francisco. Taken from http://wiki.mozilla.org/User:Johnath/EVDraft13ReviewComments It would be *nice*?? if revocations were never dropped /After discussion on the CA/Browser Forum mailing list, it was agreed that no change was necessary here. This requirement would place unwarranted burdens on CAs and certificate holders. The RFC states that revoked certs must appear at least on the first regularly-scheduled CRL update after the expiry date./ This is one of most lame things I ever heard (sorry for the language)...but let me explain this: / This requirement would place *unwarranted burdens* on CAs and certificate holders./ About which burden are they talking about? *Burden?* Supposed that EV certificates are issued only after a rigorous verification procedure, such certificates shouldn't be *never, ever* issued in first place, if there might be the slightest chance for a fraud or reason for future revocation. Full Stop! Can anybody explain to me, why an EV certificate should be a candidate for revocation ever? And if this would ever happen, this would be a very grave situation and such a certificate should never be dropped from the CRL/OCSP. And if they expect this to be an *unwarranted burden*, than perhaps I should ask about the dimensions of the expected revocations...which doesn't sound good at all! The only valid reason for revocation might be, that the user has lost or corrupted the private key or the private key is suspected to be compromised. In this case, the situation is similar grave and the CA must protect its client properly by revoking the certificate and *keep it revoked*. Also here I suggest, that the CA takes measures and provides proper support and training to the client in order to prevent this from happening in the first place. Additionally there is no burden whatsoever on the certificate holder as suggested in the response for having a revoked certificate listed in the CRL forever...or please enlighten me about which burden they are talking about. /The RFC states that revoked certs must appear.../ The RFC states...??? Really? I don't believe it! Well...the various RFCs state or don't state many thingsIf they want to go with the RFCs, so why bother creating guidelines which are supposed to improve things? The RFC don't require many things, still the proposed guidelines do exactly that...Common! This can't be serious _ Conclusion:_ Revocation of a certificate is not something which should be taken lightly - it certainly isn't equivalent to expiration. If this isn't going to be improved, then I suggest to make urgent changes to the code, in order to not allow connection to web sites with expired certificates anymore. Very unfriendly for the certificate holder and visitors so...Except that, obviously CRL checking should be ON by default anyway! Concerning audits: /...//that they were going to do an equivalence analysis between WebTrust and ETSI to see whether one could do an WebTrust EV Audit *on top* of an ETSI audit//.../ WOW! What an improvement! This almost knocked me out of my chair... Why the insistence of the Webtrust monopole? How about *opening up the guidelines and requirements for auditors without strings attached*, in order to enable potential auditors worldwide to perform third party audits? Why should this organization and its auditors hold CAs hostage and enjoy a monopole status? What about Europe, Asia, Africa, South America, Australia? Is only North-Americas Webtrust and its auditors capable and enlightened enough to do that properly? Or is it perhaps poorly about financial interests? _Conclusion:_ Mozilla should request the publishing of the guidelines for auditors and define requirements for auditors *without* any lock-in or requirements of membership to any organization. Potential auditors should be able to perform third party audits of CAs to the letter worldwide. Otherwise I suggest, that Mozilla as an open, global and community orientated organization refrains from voting in favor of the EV guidelines! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Mele wrote: The microsoft.ipsos.com is on rackspace.com which is another Microsoft partner. Firefox should not bork at this Microsoft partner site. The certs are at the site and IE has no problem getting them. Well...First, this kind of domain name is unfortunate and one can't blame the user for not getting used to all kinds of microsoft.something.com URLs... Second, Firefox barks at any web site, which doesn't have the certificate installed correctly. This has nothing to do with Microsoft partners per se... It is one of the weak spots in Fx and I'm tired of the problems. It's currently not a weak spot of Firefox...but I asked Nelson for the RFC which suggests that one /can/ fetch intermediate CA certificates the way IE does. If there is such a standard which suggests it as an option, than I think Mozilla should implement it You just blamed the server at the Ipsos site. Correct, the installation is not complete at that site! Maybe the blame is on a misconfigured server Yes, it is! It is not configured and installed correctly! This *is* the problem... If you install a web page wrongfully on your web server and the page doesn't render, who do you have to blame? The browser? Of course not...so in this case, this is a problem of the server admin as well... but finger pointing doesn't get the problem solved. You did not offer one constructive idea of how to fix this sort of problem that Fx has, but IE doesn't, other than complain to the webmaster or better just go use IE. I'd rather suggest *not* to visit that site and *not* participate in any survey until the problem is fixed! Obviously this site doesn't really give you a good feeling...judging from the URL, certificate installation etcI wouldn't provide any data...But perhaps this is what it's all about? Maybe they don't want non-microsoft - non-IE users to participate? ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Nelson Bolyard wrote: We're working on it. Now up to 60,000 lines of new code for it, and still growing. This feature is actually necessary in bridge CA (a.k.a. Cross certified CA infrastructures, which are now beginning to emerge, mostly in Asia. Cool! So I guess this issue gets addressed now anyway... Earlier, Eddy wrote: At our CA, we have a robot checking for missing ICA certificatesand send an appropriate message to the subscriber... And by the subscriber, Eddy means the web site administrator who acquired the cert for his server. Eddy, that's brilliant. It's a service that adds tremendous value for your subscribers and all their users/customers. I wish more CAs did that. Thank you for the flowers :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Melelina wrote: Also, why am I unable to edit the cert issued to http://www.microsoft.ipsos.com/ which I took from IE and put in the Fx Cert Manager? I want to trust this cert but when I use edit and click the trust button upon closing the Certificate Manager my edit is reversed and the do not trust button is chosen. How good that this certificate isn't trusted...which CA issues such a certificatewww.microsoft.ipsos.com? I guess that the signer is a fake Verisign certificate -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Gervase Markham wrote: IE will also have a similar problem, but only if it has never encountered a correctly-configured web server (i.e. it caches intermediate certs). So IE in new installs of Windows will also have the problem. This is not correct! IE fetches the intermediate CA if it finds a CA issuer extension within the subscriber certificate, which isn't really by any RFC, but nevertheless very useful! Many server installations are missing the intermediate CA files and IE gets around this problem in this way...Something to consider for Mozilla Firefox? At our CA, we have a robot checking for missing ICA certificatesand send an appropriate message to the subscriber... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
I can create a cert which claims to be a VeriSign Class 3 Secure Server CA and sign my webserver's cert with it. If you then visit my website, you'll get exactly the same error as you see at the ipsos.com site. Which however means, that your certificate installation isn't complete and should add the intermediate CA certificate to your server...Which server software are you using? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
I'm replying now to my own mail, as I misunderstood the statement from you...Of course this is not the correct answer to what you said Eddy Nigg (StartCom Ltd.) wrote: I can create a cert which claims to be a VeriSign Class 3 Secure Server CA and sign my webserver's cert with it. If you then visit my website, you'll get exactly the same error as you see at the ipsos.com site. Which however means, that your certificate installation isn't complete and should add the intermediate CA certificate to your server...Which server software are you using? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
