> > I don't know how to say this any other way - but that's unbelievably > sloppy. That's like saying you'll let your customers email their credit > card numbers to you. You don't put anything that sensitive into an email > address, ever. Any time I get a password emailed to me I change it > immediately. > Besides this is passing the blame to the customers. And there is a big > difference of how informed each party was. Symantec knew about this > exploit, customers didn't. They knew to take extra precautions, customers > didn't have that knowledge.
Email validation is a *standard* method for issuing DV certificates used by *most* CAs. Hundreds of certificates a day are issued with this method. It is detailed in the CA/B Forum's Baseline Requirements which all trusted CAs are bound to. If you have an issue with that, well, it is off topic to this incident. > He says it on his facebook post: "for some third party vendors, depending > on the type of certificate, and how the certificate was issued, you could > also retrieve private keys." As you have quoted: "for some third party vendors." Symantec themselves had nothing to do with storing private keys. If a reseller chose to do this, the vulnerability lies with them. It would be inaccurate to say that a Symantec reseller storing private keys is the same thing as Symantec storing private keys. According to Tarah's response, Chris' report involved three different types of problems: legitimate problems with Symantec's API (which have been fixed a while ago), unfortunate but uncontrollable general security issues (such as the ability to control a user's account if you have access to their email), and security issues of a third party (resellers storing private keys). I believe the 30,000 number they talked about relates to the same security > issue that Chris Byrne identified. If it didn't then here's my question: > how many certificates were affected by the Chris Byrne issue? No, it does not. The issue Google has been dealing with in the blinkdev thread - which I will refer to as the "RA Incident" - involves companies which Symantec contracted with and had "independent authority to issue certificates under Symantec intermediates <https://wiki.mozilla.org/CA:Symantec_Issues>". This is separate from a reseller, which is purely a business/marketing relationship that does not grant the reseller any ability to issue certificates. The RA Incident is ENTIRELY separate from what Chris Byrne has reported. Ryan Sleevi (Google engineer) posted the proposal about how to handle the RA Incident and you can see it makes no mention of any API issues: https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ As far as I am aware, there have been no figures shared about the certificates affected by the Chris Byrne issue. On Fri, Mar 31, 2017 at 9:01 PM, Daniel Baxter via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Saturday, April 1, 2017 at 6:27:27 AM UTC+11, Jakob Bohm wrote: > > Oh, come on, if that's her job title, that's her job title, and at any > > CA, that is actually an important job that /someone/ should have. > > I meant the content of her reply, not her job title. > > > Unfortunately, when initially establishing encryption certificates, one > > generally has to start from some kind of unencrypted connection, such > > as an unencrypted phone call or an unencrypted e-mail, or an > > unencrypted paper mail. > > Not the private key though. And besides, it doesn't matter if your CSR and > Certificate are duplicated, they're not a secret only the private key is. > > > But a password or random secret string in a URL /is/ authentication. > > And in an e-mail, it is behind whatever authentication you (not > > Symantec) have set up for that e-mail (and Symantec obviously didn't > > know about the Yahoo undisclosed breach at the time). > > I don't know how to say this any other way - but that's unbelievably > sloppy. That's like saying you'll let your customers email their credit > card numbers to you. You don't put anything that sensitive into an email > address, ever. Any time I get a password emailed to me I change it > immediately. > > Besides this is passing the blame to the customers. And there is a big > difference of how informed each party was. Symantec knew about this > exploit, customers didn't. They knew to take extra precautions, customers > didn't have that knowledge. > > > They need to only assume that whatever e-mail account people provide > > for signup is secure enough for the people choosing what e-mail to > > provide /and only on the day or week where they provide that e-mail > > address/. > > So since December 2016 they banned all Yahoo! emails, right? > > > But was he, or did you simply exaggerate something in your blog? > > He says it on his facebook post: "for some third party vendors, depending > on the type of certificate, and how the certificate was issued, you could > also retrieve private keys." > > > The Google issue is *microscopic* except Google is using it as a lame > > excuse to threaten Symantec big time. > > I believe the 30,000 number they talked about relates to the same security > issue that Chris Byrne identified. If it didn't then here's my question: > how many certificates were affected by the Chris Byrne issue? > > On Saturday, April 1, 2017 at 9:11:00 AM UTC+11, tarah.s...@gmail.com > wrote: > > > > So sorry, but I don't know what you're referring to. Did you tweet me a > link to a blog post? Blame Jack if so; all of us are dealing with hugely > problematic threading today due to the Twitter @ changes. If you reply here > with what you are talking about, I can take a look, though unfortunately I > might not be able to get to it today. I always like hearing opposing > viewpoints. > > Sure, it's no secret: https://blog.aractus.com/the-symantec-ssl-shitstorm/ > > That page I'm pretty sure wasn't even indexed in google when I posted. > Even it it was, my viewership is only small. I was here reading these > threads, and gathering more information so that I can fix up all the errors > I've made - that's how we all learn, by making mistakes and fixing them. > Anyway, I only used primary sourced material (ie, the google groups > discussions, Chris's facebook post, and the Symantec website), I haven't > read anything on Twitter. > > Again, I obviously can't speak for others, but any confusion over the > facts here could have been easily avoided had Symantec made a full public > statement about the Chris Byrne vulnerability the moment that it no longer > posed a threat to customers. > > Where I will agree with you is that from the description, it would have > involved a fairly sophisticated attack to steal private keys from the > "incompetent resellers", and that they were equally culpable. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Vincent Lynch _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
