Re: Discovering unlogged certificates in internet-wide scans
On 03/31/2018 06:14 PM, Tim Smith via dev-security-policy wrote: > Hi MDSP, > > I went looking for corpuses of certificates that may not have been > previously logged to CT and found some in the Rapid7 "More SSL" dataset, > which captures certificates from their scans of non-HTTPS ports for > TLS-speaking services. > Pretty interesting read, and always happy to see more information go into CT. One thing I couldn't divine from your data was how did you look for non-HTTPS services? Did you port scan and do service discovery, or did you simply knock on well known ports that either are SSL by default or support a STARTTLS equivalent? If so, which well known ports were knocked on? > I wrote up some findings at > http://blog.tim-smith.us/2018/03/moressl-spelunking/. > > A few highlights include: > - of the ~10 million certificates in the corpus, about 20% had valid > signatures and chained to roots included in the Mozilla trust store > - about 50,000 of the 2 million trusted certificates had not previously > been logged > - about half of the novel certificates were unexpired > When you say roots included to Mozilla trust store, how was this used exactly? I see you used X509Validator, but did you just throw all the NSS PEMs or did you remove the ones that are technically constrained? (i.e., CNNIC is distrusted for new certificates, but is in the root store for existing certificates before technical restrictions were applied) This could influence the number of valid or invalid certificates you saw. I'd also be interested in see or graph that shows how many certificates chain up to a given root. I do wonder if there would be value in a tool that basically takes a x509 certificate in, and then runs it through NSS to determine validity applying all technical constraints upon the way. I might have to fiddle with NSS to see how hard it is to get at that functionality. > There were interesting examples of unexpired, non-compliant, trusted > certificates chaining to issuers including GoDaddy, NetLock, Logius, and > Entrust. (I have not taken any action to inform issuers of these findings, > other than this message and by publishing the certificates to CT logs.) > Given all these certificates are new to CT, I'm guessing none of them have come up before on MDSP. Thanks for your effort, Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Discovering unlogged certificates in internet-wide scans
On 03/31/2018 09:53 PM, Tim Smith wrote: > On Sat, Mar 31, 2018 at 6:28 PM, Michael Casadevall via > dev-security-policy wrote: > Thanks for taking a look. My understanding of Rapid7's methodology [1, > 2] is that they knock on well-known ports. The services they emit data > for are pop3/s (110, 995), nntps (563), mqtt (8833), ftps (990), > smtp/s (25, 465, 587), and imap/s (143, 990). > > I consumed their published data set and didn't perform any scanning myself. > Ah, I misread, I thought you had done the scanning directly. Still, it was good to take a look at this, and I'm looking through Rapid7's docs on how to play with the data set myself. >> When you say roots included to Mozilla trust store, how was this used >> exactly? I see you used X509Validator, but did you just throw all the >> NSS PEMs or did you remove the ones that are technically constrained? > > I used the certifi distribution [3], which is aware of "included but > distrusted" [4]. The certificates were "validated" naively without > considering e.g. path length or name constraints; certificates failing > those constraints would certainly be interesting but hopefully rare. > Hrm, I might have a weekend project here. I've always been curious to what extent technical constraints actually affected things. I may need to download their data set and play with it somewhat. >> I'd also be interested in see or graph that shows how many >> certificates chain up to a given root. > > Sure; would you like to see that because it would help sanity-check > the data, or because it might reveal differences vs. certificates used > for HTTPS, or some other reason? > Partially for non-HTTPS usage, but I also wanted to see the cross-section of how much "diversity" there was in how much of the internet chains of a specific root certificate. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Fond Farewell to Gerv Markham
While I didn't know Gerv personally, I always respected his insight and knowledge I've gotten from years lurking on this list. He will be missed :/ Michael On 07/29/2018 12:23 PM, Kathleen Wilson via dev-security-policy wrote: Dear Fellow Mozillians, It is with deep sorrow that we share the news that our friend and colleague, Gerv Markham, passed away on July 27, 2018. Along with the many others whom he worked alongside over his time at Mozilla, we will remember Gerv as caring, honest, inquisitive, opinionated, energetic, and a lot of fun to work with! He enjoyed and looked forward to meeting with people in person, and loved diving into the details. He was often the first to pick up the phone to talk to people to get to the core of a situation. He was also quick to be helpful, going out of his way to provide assistance where needed. He would identify things that were in need of repair, meet with the owners to find out if they needed help, and dive right in to do the work. Previously from Gerv: “It's been eighteen years since I first entered the world of Mozilla, on a program of constructing reduced layout test cases for early Gecko builds in order to earn a dino plushie (I got two!). Both I and the project have come a long way since then, but an ever-present companion has been my cancer, with which I was diagnosed in 2001.” Eighteen years is a remarkable length of time to fight against incurable illness, and we are proud for the fighting Gerv managed to do throughout those years to advance Mozilla's mission. Over the years of Gerv’s tenure with Mozilla, he worked on public policy, certificate authority (CA) root program, community governance, MPL, licensing, usability, security, and Bugzilla. He attended every CA/Browser Forum face-to-face meeting that he could, and the CA/Browser Forum extended the attached commendation to him. It has been an honor to work with Gerv, and it is with very fond memories that we say goodbye to our wonderful friend and colleague, Gerv Markham. Fond Farewell, Kathleen Wilson, Wayne Thayer, JC Jones, and Chris Riley (among many more) PS: Here is the text from the CA/Browser Forum Commendation that is mentioned above. ~~ The CA/Browser Forum and its members gratefully extend to Gervase Markham their heartfelt commendation and appreciation For his extraordinary leadership and skill as a founding member of the Forum in 2005 and as a Mozilla representative and a leading Forum participant from 2005–2018, and For his superb work in promoting higher standards for Certification Authorities, and For his ceaseless efforts to improve security for users on the internet, and For sharing his deep knowledge of TLS and PKI with his fellow Forum members, and For his constant innovation and improvement to the Mozilla processes applicable to CAs around the world, and For his skills during Forum meetings and teleconferences so that all could participate on an equal basis and members’ time was well spent, and For his ability to bridge differences of opinion among members to reach solutions that could be supported by all, and For his tact and diplomacy in helping Certification Authorities and Browsers meet their mutual goals, and For his patience, wit, sincerity, honesty, pleasant demeanor, and everlasting good cheer, and For his superior guidance, advice, and management style. -- For these and many other accomplishments we hereby affirm our deep appreciation, commendation, and congratulations to Gerv, and sincerely extend our best wishes to him and his family. -- Dated this 22nd day of March, 2018. ADOPTED UNANIMOUSLY BY THE MEMBERS OF THE CA / BROWSER FORUM ~~ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DEFCON Talk - Lost and Found Certificates
On 08/19/2018 12:56 PM, Eric Mill via dev-security-policy wrote: > On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> It seems that my response to this presentation has brought out the crowd >> of people who are constantly looking to reduce the usefulness of >> certificates to anyone but the largest mega-corporations. >> >> To summarize my problem with this: >> >> - While some large IT operations (and a minority of small ones) run >>fully automated setups that can trivially handle replacing >>certificates many times per year, many other certificate holders treat >>certificate replacement as a rare event that involves a lot of manual >>labor. Shortening the maximum duration of certificates down to Let's >>encrypt levels will be a massive burden in terms of wasted man-hours >>accumulated over millions (billions?) of organizations having to do 4 >>times a year what they used to do every two or five years. >> > > The trend is away from manual replacement, not towards it -- and that's > true for individual people, for large enterprises, and for smaller > companies in between. For individuals and smaller enterprises, this > manifests mostly in the increasing outsourcing of certificate management to > third parties (e.g. SquareSpace, CloudFlare, AWS Certificate Manager, > etc.). > In my limited experience, this trend is *because* of Let's Encrypt getting them to do it four times a year. A lot of my freelance work has been automated certificate rollovers due to cost, and usually some fiddling every X months when a domain fails to validate and the certificate fails to issue. For a lot of places, the time spent having someone automating it offsets the annual cost of having to fork up for a certificate (or getting management to approve an expense) It should be also noted that I've seen quite a few organizations decide the cost of automation is too difficult or the systems using the certificates are too fragile and rather pay for longer lasting certificates. > For larger enterprises, the same outsourcing is also present and is > mitigating manual rotation burdens, but some are also investing in their > own systems for automation inside their environments. I've seen several > spring up in enterprise environments I'm close to in the last few years in > order to handle the increasing pressure to secure connections by default > even when the certificate volume is high. >> Reducing certificate lifetimes to 13 months, in addition to addressing the> real security issue identified by the Lost and Found Certificates > presentation, is likely to further these trends, which would be a positive > development both for user security and enterprise agility. > > - While infinitely wealthy organizations can afford getting separate >>certificates for each DNS name, and while lowest-security (DV) >>certificates are now available for zero dollars in the US, SANs remain >>significant in case of high security validation (OV, EV) that costs >>real money and effort, both to pay the CA and to provide evidence of >>human and organizational genuineness, such as showing government IDs, >>obtaining certified copies of registration statements, answering >>validation phone calls to CEOs at strange hours etc. > SANs are also important in DV certificates unless we're talking about wildcards. Lets Encrypt certificates use the first domain as the CN, and then all the subdomains as SANs. Given that wildcard certificates can be undesirable, there are more than a few valid reasons to have SANs, even in cases where everything is within one domain. My largest problem with long lived certificates is that expiration is essentially the only effective mechanism of removing old certificates from circulation. Revocation at best is iffy, and down right broken depending on who you ask between Chrome's CRLSets, OCSP Soft Fail, etc. If we could fix revocation so it could work effectively, longer lived certificates would be less of a risk factor. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
I appreciate the ground work Fabio put into this thus far, and want to see further discussion on it. I think the safest way to quantity and frame the discussion is asking if a CA (or subCA) has a vested interest in surveillance, other business interest, or government ties which would put a CA to be more likely to abuse the trust, or has a history of business practices related to surveillance or practices against the public interest in regards to WebPKI. I recognize the points Scott brought up, but trust is always a subjective thing. As previously pointed out, Mozilla has always retained the ability to choose what to include or disallow based on community input, and this entire thread shows there is a lot of community input here. The problem with auditing in general is its only going to catch information that is logged and archived in a corporation. It's an assurance step but in and of itself is not enough to establish trust; it not uncommon for misissues and other issues to be noted by the community from information in the wild Michael On 7/10/19 3:59 AM, fabio.pietrosanti--- via dev-security-policy wrote: > I understand the Nadim points, there's a lot of subjective biased "popular > judgement". > > While from a security standpoint perspective "better safe than sorry" is a > good statement, from a rights and fairness perspective that's a very bad. > > So further conversation is needed. > > Following DarkMatter removal i would love to bring to the attention of > Mozilla the removal of a list of Companies that does as a main business other > stuff, but also does offensive security and surveillance with public > "credible evidences" . > > I've analysed Intermediate CA list where DarkMatter is here > https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCerts . > > In this list is possible to find the following company operating against > "people's safety" and there's "credible evidences" they are doing so: > > > * Saudi Telecom Company > > This company is publicly known to ask to surveil and intercept people as per > "credible evidences" on: > https://moxie.org/blog/saudi-surveillance/ > https://citizenlab.ca/2014/06/backdoor-hacking-teams-tradecraft-android-implant/ > > > * German Rohde & Schwarz > > This company do produce, install and support surveillance systems for > intelligence agencies in Regimes such as Turkmenistan: > https://www.rferl.org/a/german-tech-firm-s-turkmen-ties-trigger-surveillance-concerns/29759911.html > > They sell solutions to intelligence agencies such as IMSI Catchers and > massive internet surveillance tools: > https://www.rohde-schwarz.com/en/solutions/aerospace-defense-security/overview/aerospace-defense-overview_229832.html > > > * US "Computer Sciences Corporation" > > The CSC is a US Intelligence and Defense Contractors that does CNE (Computer > Network Exploitation) like the WikiLeaks ICWatch show out > > Read the profile of a former employee of CSC, doing CNE like Snowden was > doing: > https://icwatch.wikileaks.org/docs/rLynnette-Jackson932c7871cb1e83f3%3Fsp=0ComputerSciencesCorporationCyberSecurityAnalystSystemsEngineerRemoteSystemAdministrator2008-09-01icwatch_indeed > > Additionally from their wikipedia they acknowledge working for US Intel: > https://en.wikipedia.org/wiki/Computer_Sciences_Corporation > > CSC provided services to the United States Department of Defense,[23] law > enforcement and intelligence agencies (FBI,[24] CIA, Homeland Security[23]), > aeronautics and aerospace agencies (NASA). In 2012, U.S. federal contracts > accounted for 36% of CSC total revenue.[25] > > > * Australia's Attorney-General's Department > > The Australia's Attorney-General's Department is a government agencies that > wants to permit the Australian Security Intelligence Organisation (ASIO) to > hack IT systems belonging to non-involved, non-targeted parties. > > It operate against people safety and there's credible evidence of their > behaviour in supporting ASIO to hack people, so they are very likely to abuse > their intermediate CA: > http://www.h-online.com/security/news/item/Australian-secret-services-to-get-licence-to-hack-1784139.html > > > * US "National Geospatial-Intelligence Agency" https://www.nga.mil > > The NGA is a US Military Intelligence Agency, equivalent to NSA, but > operating on space GEOINT and SIGINT in serving intelligence and defense US > agencies. > > NGA is the Space partner of NSA: > https://www.nsa.gov/news-features/press-room/Article/1635467/joint-document-highlights-nga-and-nsa-collaboration/ > > I think that no-one would object to shutdown an NSA operated Intermediate CA, > i am wondering if Mozilla would consider this removal. > > > Said that, given the approach that has been following with DarkMatter about > "credible evidence" and "people safety" principles, i would strongly argue > that Mozilla should take action against the subject previously documented. > > I will open a thr
Re: Symantec: Update
On 05/11/2017 09:53 AM, Jonathan Rudenberg via dev-security-policy wrote: > >> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy >> wrote: >> >> I would appreciate people's comments on the details of the current draft. > > I don’t think that this proposal goes far enough. First post on the list but long time lurker, but I feel the need to weigh in here that I think Jonathah's proposal is much closer to what has to happen. Reading through Gervase's document, I'd like to add the following to this in addition to the existing notes in PKI operations: - EV certificate roots loose their trust bits effective immediately (I don't think this can be done via OneCRL so it would be via the next release) - Any root stores (new or old) operated by Symantec shall require all certificates to be posted to a CT log. - Within three months, require all certificates issued from Symantec to have SCT embedded in the end point certificate, and mandate this from the beginning for any root certificates. - NSS shall only accept certificates with the embedded SCT record in the certificate. Certificate transparency was the only way we began to get a real look at how bad some of these issues are, and I feel that if we're going to actually continue with Symatec as a CA, then we're going to make absolutely sure we know how certificates are being utilized. Mandating the X509v3 extension for TLS certificates means that downstream servers don't have to be updated for CT awareness, and we should never be in a case where a Mozilla product is accepting a certificate that we can't independent review at a further point via the CT logs. It should also prevent an undisclosed intermediately from being undetected (as we've seen with Issue Y). I'd also like to add the following to the transition plans: - Limit certificate expiration to nine months from the existing roots for new certificates. - The above SCT requirement shall come into affect for the old roots no less that three months from the date the proposal is ratified. - Create a whitelist of intermediate certificates from the root that can continue issuing certificates, but cutting off RAs after an initial six month time period - Require that Symantec reapply to the root program for a new DV and EV root certificates, and begin the migration here. Once the new roots are approved, then they can cross-sign from the old roots to the new ones. My thought process here is to try and keep impact on WebPKI a minimum, while making sure that we can externally audit how Symantec is using their root store for certificates that will be trusted by Mozilla. I'm concerned that spinning up new roots and having them be in the most common root stores is going to take a significant period of time and during that window we're still stuck with the old roots being in operation. By limiting the branches of the old roots, it should limit our risk while the new roots come into existence and begin to spread through the ecosystem. Winding down the old roots (phase four as described in the proposal) is going to be a long and slow process so I want to make sure we're making sure that while we're in the transition period that we've got an extremely clear picture on what's going on on both sets of roots. My problem with the Google "sliding scale" is that's its damn hard to understand when exactly a certificate is good or when it expires since the dates in the X509 certificate don't necessarily correspond with reality. By simply capping Symantec certificates to nine months, it puts us in a position that moving to a new DV/EV root would be required for them to remain competitive while not drastically affecting the ecosystem as a whole. Maybe I'm off-kilter here, but I think this proposal would help keep impact on WebPKI to a minimum but light a fairly serious fire to get users moved to the new root stores ASAP. Please let me know if I am seriously off base with my understanding of the situation or the technologies involved; WebPKI is a complicated thing to understand :) Michael signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
On 05/15/2017 09:32 AM, Jakob Bohm wrote: > This won't work for the *millions* of legitimate, not-misissued, > end certificates that were issued before Symantec began SCT > embedding (hopefully in the past) and haven't expired before such > an early deadline. > Sorry, I could have been more clear here. What I'm proposing is that after a specific TBD NotBefore date, we require SCTs to be in place on the certificate to be trusted. Certificates from before that date would remain trusted as-is (pending any reduction of expiration time). I don't know if NSS has support for checking of SCTs (I can't pull the source at the moment to check), but it should fail if the SCT is missing, and otherwise behave like OCSP validation. > Also, since both Mozilla and Debian-derived systems such as Ubuntu > use the the Mozilla store as the basis for S/MIME checking, it is > worth noting that CT-logging of S/MIME end certs under the current > Google- dominated specifications is a guaranteed spam disaster, as > it would publish all the embedded e-mail addresses for easy > harvesting. > I didn't consider the S/MIME use case here. A brief look at the root store I'd be fine with the SCT restriction only applying when looking at CKA_TRUST_SERVER_AUTH, and not in other cases. Looking at certdata, it looks like at least some of the current Verisign/Symantec roots have both the S/MIME and server auth bits enabled. While I feel CT would be a nice thing for S/MIME, unfortunately, I have to agree with this point that we don't need to make spammers lives easier. That being said, part of me wonders if there would be other undisclosed intermediates if one could easily evaluate S/MIME issuances ... >> Mandating the X509v3 extension for TLS certificates means that >> downstream servers don't have to be updated for CT awareness, and >> we should never be in a case where a Mozilla product is accepting >> a certificate that we can't independent review at a further point >> via the CT logs. It should also prevent an undisclosed >> intermediately from being undetected (as we've seen with Issue >> Y). >> > > However it would mandate that they be updated with new > certificates instead. A lot easier, but still a mountain not > easily moved. See above on NotBefore. >> >> I'd also like to add the following to the transition plans: - >> Limit certificate expiration to nine months from the existing >> roots for new certificates. > > I strongly believe the "9 month" rule mysteriously proposed but > never explained by Google was designed specifically to make buying > certs from Symantec all but worthless, chasing away all their > customers. People *paying* for certificates generally don't want > to buy from anyone selling in increments of less than 1 year, > preferably 2 or 3. "9 months" is an especially bad duration, as it > means the renewal dates and number of renewals per fiscal year will > fluctuate wildly from an accounting perspective. > I can see the point here, but I'm not sure I agree. Every time we keep digging, we keep finding more and more problems with these roots. WebPKI depends on all certificates in the root store being trustworthy, and Symantec as a whole has not exactly shown themselves to be responsive or willing to communicate publicly on the various issues brought up on the list. There's a decent argument to be had to simply disallow new issuance from the existing roots and allow the current certificates to age out (in which case imposing SCT embedded as I propose is simple), but I'm not sure we've gotten a complete picture of how far this rabbit hole goe s. There's been a continual pattern of "this is everything", and then we find another bunch of misissued certificates/undisclosed subCAs/etc. Can we honestly say that we're comfortable with allowing these roots to still be active at all? >> - The above SCT requirement shall come into affect for the old >> roots no less that three months from the date the proposal is >> ratified. - Create a whitelist of intermediate certificates from >> the root that can continue issuing certificates, but cutting off >> RAs after an initial six month time period > > Are there any RA's left for Symantec? > TBH, I'm not sure. I think Gervase asked for clarification on this point, but its hard to keep track of who could issue as an RA. I know quite a few got killed, but I'm not sure if there are any other subCAs based off re-reading posts in this thread. >> - Require that Symantec reapply to the root program for a new DV >> and EV root certificates, and begin the migration here. Once the >> new roots are approved, then they can cross-sign from the old >> roots to the new ones. >> >> My thought process here is to try and keep impact on WebPKI a >> minimum, while making sure that we can externally audit how >> Symantec is using their root store for certificates that will be >> trusted by Mozilla. >> >> I'm concerned that spinning up new roots and having them be in >> the most
Re: [EXT] Re: Draft further questions for Symantec
I took a stab at trying to grok this. I find I have more questions and a lot more concerns the more I read though. Please let me know if I'm not the only one having issues decoding the responses. Here's my first impressions: RA & EV: Were all the certificates issued by the RAs uploaded to a CT log? If not, what, if any, subsets were uploaded? I'm aware Symantec was required to upload certificates to CT or if it was retroactive, but I'm unsure if that requirement was extended to the RAs. Furthermore, based on what I'm reading, at least one of these certificates should be in the logs since it took place post 01/01/15. Issue Y: A simple yes or no answer for the questions would have been nice here. What I'm reading and my understanding suggests that the subCA certificates could have technically issued a certificate trusted by Mozilla, but system controls prevented them from being used that way. How these system controls work is at best unclear. It's worth noting that the subCA "State of Florida AHCA Medium Assurance CA" and several other fPKI subCAs chaining off "VeriSign Class 3 SSP Intermediate CA - G2" are listed in crt.sh is listed as trusted in Mozilla in crt.sh (https://crt.sh/?caid=1384), and based on my understanding thus could theoretically issue certificates as there's no EKU. I can't find any leaf certificates issued by these CAs in crt.sh to confirm this fact though. Here's a question for Symantec, how are they aware of what certificates these sub-subCAs have or have not issued? I'm not sure if the green bar requires OIDs in all points along the certificate chain or if this Florida CA could have issued an leaf certificate by adding the OIDs there. Issue L: Given that the cross-signature was doing by VeriSign, I've got more questions. As far as I can tell, the response suggests that Symantec was aware that the cross-signature allowed the FPKI to be trusted in places it otherwise wouldn't be, and decided to ignore it until it expired out in 2016. That sounds bad, but my other possible reading of this was: "We were unaware of the cross-signature until 2014, and we let it expire in 2016 since we didn't know what it did". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
On 05/15/2017 06:05 PM, Jakob Bohm wrote: > > Ok, that's much better. > Yay for reasonable courses of action. We'll see if it goes into the next proposal. >> I can see the point here, but I'm not sure I agree. Every time we keep >> digging, we keep finding more and more problems with these roots. >> WebPKI depends on all certificates in the root store being >> trustworthy, and Symantec as a whole has not exactly shown themselves >> to be responsive or willing to communicate publicly on the various >> issues brought up on the list. >> > > Yes, that seems to be the trend. But it has nothing to do with if the > "9 month" rule or some other measures are the best remedy. > There might be a reasonable compromise here, see below. > RAs (external companies that can decide if Symantec itself should issue > a cert) are completely different from external SubCAs (external > companies that have their own CA and a certificate chain back to a > Symantec root), which are different from internal SubCAs (CA > certificates for Symantec controlled keys, such as the SubCA that > signed normal OV certificates issued in January 2017). > > External and Internal SubCAs can be blocked by simple technical means > via TrustDB and OneCRL manipulations. RAs are indistinguishable from > Symantec itself when checking certificates, because the certificates > were in fact signed by Symantec itself. > I thought the RAs were being issued off their own intermediate branches and not off Symantec ones. Rechecking crt.sh "C=KR, O=CrossCert, OU=AccreditedCA, CN=CrossCert Class 1 Server CA" is a separate intermediate chaining to KISA so I done goofed here. Oops. Re-reading the issues, I think I got crossed between subCAs missing audits, and RA issuance. > The standard way this is done is that the old roots (which are trusted > by old browsers) cross-sign the new roots or the subCAs of the new > roots. People buying new certs get (as always) a new cert chain for > their new cert, which contains enough data to pass in browsers that > trust new root, trust the old root, or trust both roots. > > Servers with old certs still return the old certificate chain that > leads to the old roots. > > Other measures (such as browser embedded SubCA/cross certs) can be used > to reduce how much of the old CA tree Firefox/Thunderbird trust during > the transition. > Thanks for clearing this up. > I think we will need to look separately at two very different issues: > > 1. Symantec's PKI and the location of the EV trust bit unfortunately > allows non-EV SubCAs to issue EV certs that Firefox marks as green. >This same issue applies to most Mozilla trusted roots, because > Mozilla implemented the EV trust at the root CA level rather than at > a SubCA level. > >This can be fixed technically by restricting the EV trust to the > SubCAs that are supposed to issue EV certs, rather than to whatever > general WebPKI root cert resides above it (in order for legitimate EV > certs to be trusted as normal certs by old browsers). > This is a start. We'd need confirmation from Symantec which subCAs are supposed to be able to sign EV as I don't believe we have a complete list. That's also assuming that things are that nice and organized (which is far from a given). If we can successfully cut a good chunk of the crud away, it would at least help in mind keeping EV being a reasonable option. > 2. If there were any significant failures in the validation of EV > certs signed directly by the dedicated EV SubCAs at Symantec (other > than the one test cert that got some Symantec people fired some time > ago). > Can we reasonably determine we're good here beyond a reasonable doubt? The current responses to the last question found new parts of the fPKI that are chaining via the Issue Y intermediates that appear that they would be trusted by Mozilla. We also have confirmation that some of the RAs could issue EVs and could validate certificates. Symantec said that they independently checked the non-expired EV certificates, but I think I have (IMHO) justified concerns there might be additional ones here we don't know about. Given the number of unknown knows with the EV situation right now, I think I'm going to wait for more information before pushing any one specific option, but at a minimium, we need to cut down the parts of the tree that can sign for EV. There's also a third issue is "what is the correct response to the severity of Symantec's trust issues". We're fairly close to CNNIC territory here, since we've got multiple intermediates that chain to the Mozilla roots and can issue certificates which are either not BR compliant, or out of scope of an audit. In an attempt to try and get this thread to a point where the powers that be might choose to include it in their proposal, let's try the following in the addition to what is under PKI concerns in the gdoc: --- - For any Symantec-owned root certificate in the Mozilla trust prog
Re: Symantec: Update
On 05/16/2017 03:50 AM, Michael Casadevall wrote: > On 05/15/2017 06:05 PM, Jakob Bohm wrote: >> > > - A three-day grace period shall be in place from the issuance date of > a certificate to when it must be in the CT logs for validation reasons > (this is in line with other proposals here). > > - All server authentication certificates shall be submitted to at least > two public CT logs. > Just realized I had a brainfart when writing this. Don't believe I can supersede on this list to fix it so sorry for the chatter. This should say that certificates must be issued with an embedded SCT which Symantec can get from their own log, and then upload the certificate to other logs as part of the issuance. As part of the CT validation, there would be a three day grace period from the issuance date, to when the certificate can start failing due to CT failure which should leave a nice bit of padding for the maximum merge delay on the current public logs. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
On 05/16/2017 06:05 AM, Peter Gutmann wrote: > Ryan Sleevi via dev-security-policy > writes: > > Unless someone has a means of managing frequent updates of the root > infrastructure (and there isn't one, or at least none that work), this will > never fly. There's a reason why roots have 20-40 year lifetimes and why they > get on-sold endlessly across different owners rather than simply being > replaced when required. > > Peter. > Arguably, this would be a nice thing to fix since it could help reduce issues with CA's changing owners. If we could update root stores retroactively, it would make a lot of migrations simpler. For example, if a device took the entire Mozilla root store before CNNIC was booted out, those devices would still trust those certificates. Given the glacier pace some things update at, having a type of root agility would be rather desirable. Just spitballing ideas here, but in Alex's case, part of me would be tempted to see if X509 could be extended with a new "CanIssueUntil" field. Basically, it would act as an off switch for CA:TRUE after a given date, but certificates signed before that would still be valid for that root, and then can be wound down beyond that point. Maybe a bit out there, but an interesting thought none the less. It would definitely go a good way at preventing one root certificate from underpinning a large chunk of the internet. My thought here is if a large "Too Big to Fail" CA's private key was compromised/factored/physically stolen, our only recourse would be to remove them from the root store, and deal with half the internet breaking. Would be nice if that could not be a thing. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
On 05/16/2017 08:40 AM, Rob Stradling wrote: > On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote: > >> Just spitballing ideas here, but in Alex's case, part of me would be >> tempted to see if X509 could be extended with a new "CanIssueUntil" >> field. Basically, it would act as an off switch for CA:TRUE after a >> given date, but certificates signed before that would still be valid for >> that root, and then can be wound down beyond that point. > > That sounds like the "Private Key Usage Period" extension, which was > present in RFC3280 but removed in RFC5280. > > https://tools.ietf.org/html/rfc3280#section-4.2.1.4 > I learned something new today. I'm about to run out the door right now so I can't read the RFCs but do you know off the top of your head why that was removed? Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/16/2017 11:10 AM, Peter Bowen wrote: > Jakob, > > What I think Ryan has been trying to express is his view that this > request is not possible. A *stable* data format is unable to > express future graduated trust rules. > I've been thinking on this and I'm starting to question this. The fact of the matter is most of the graduated trust scenarios involve a whitelist/blacklist, or putting restraints on the values of fields on a certificate. If you simply have a way to express requirements for ASN1 fields and such, that handles lot of the simple cases. For example, wosign would need the following constraints: "CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=C N" blacklist-leafs: - NotBefore: > 2016-21-10 - Attributes: inclusive For the case of ANSSI, it would look something like this *ANSSI Distinished Name* - blacklist-leafs - whitelist-leafs: - CommonName: - ends-in .fr - ends-in .gp - ends-in .gf - ends-in .mq - ends-in .re etc. For knocking out the future certificates, and that this blacklist should apply if this certificate appears anywhere in the chain of trust. While that won't handle every single case, being able to specify that a field must be present, or have this valid (or not have this valid) in an extensiable way would handle a fair number of cases for graduated trust. Granted, it won't handle everything, but it's not let perfect be the enemy of good here. Right now, if you naively imported the Mozilla root store, you get a number of certificates you probably shouldn't be trusting. In the case we need to specify a new type of trust restrictions, then we extend the format, and implement it. It's up to downstream authors to actually parse the data and do something with it. If the graduated trust data is in a standardized format, there's a decent chance other libraries may be willing to support it. If someone can prove me wrong and show a case where Mozilla proposed or implemented graduated trust that couldn't be expressed as a combination of a whitelist/blacklist, and attribute comparsions, I'd very much like to know if it. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJZGzGOAAoJEHM+GkLSJHY5dTEP/iLWY9Wgeb8gvt/dY/Bp0BCA QLX+/i3rv/TOm/plxL/tKrHg8pM7YDVwBHRR51i5vmko2712yVPlXbSAnnqyL3bV IzSNgKUiMjbeLhO98P9pXH5M586VzAPnLrxilrjrvXZJRmL+nTdguDRBAPO1+6qe La7WOpPgxVfaf2u+8e+waqjDF517VaAy2PaZAm5VP5EB+i50QqyGHJfwuTvArBeY c28ZHXso5t1qze2dmKCvg4lIARwvckwTdx0dqiedcZSIm++wd8K0Yq+I85R0SH6g gUv6LLf4b4JlQER0KQ3ozdqRhNwRd+VwReuGDTeE6PH9/2UCpIkt44BDLlfC+Jt5 Y+4lw3FTGgHDLdVaeLZqGVaE/47aQgmU3gdfAPRe0q47GBb3uqwSsfg4LBO7+lFQ BAIGNOi3v2Zr/aALmtBCo0zzn+wt67OF4uIAFhhNTyP6o7XsWXJwSSwW0eO41mOe QuSYx6ETNOh5u01uAR5+GSaOwNxKZBSYMyXBv3yAV9ZSrSD1aA17oRJFlClYkHyM uhLPpn5TZ5Q25gtQiS8MvxiHqo6+joV9hAw/b0nNqkFAFzHI1OaZzy0p8bOmKI+d /auRC56g5mGdOIY8h0fFgoFAfh/adohubqiGqMt0Yn9c9yB51OjM+JJ9XKGuAI3+ 2+gZjY9o4tH+qCmVD/Va =JEMo -END PGP SIGNATURE- ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On 05/16/2017 01:04 PM, Jakob Bohm wrote: > > Could you please point out where in certdata.txt the following are > expressed, as I couldn't find it in a quick scan: > > 1. The date restrictions on WoSign-issued certificates. > > 2. The EV trust bit for some CAs. > Not the OP, but WoSign restrictions are hardcoded: https://dxr.mozilla.org/mozilla-aurora/source/security/certverifier/NSSCertDBTrustDomain.cpp#741 EV OIDs live in PSM, and are hardcoded into the browser: https://dxr.mozilla.org/mozilla-aurora/source/security/certverifier/ExtendedValidation.cpp At least in the case of EV though, I'm not sure if anything beside the browser itself actually cares EV vs. DV (or OV) in practice though. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/17/2017 05:04 AM, Kurt Roeckx wrote: > If the key is compromised, you can't rely on any date information > anymore, you need to revoke it completely and break things. > Won't that only be true in certificates without SCTs? Once you have a SCT, you have an independent timestamp you can check beside the NotBefore value, and can independently confirm since CT logs are append-only. (Granted, I realize nothing actually checks the SCT in this way to my knowledge, but the idea itself may be on semi-solid ground). Michael -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJZHDLHAAoJEHM+GkLSJHY5rnAP/A7Y7x0B5yr/t3ft5Ua4k5BP P1EKD/Oguwf2QqTiBYgvuKOvdc8aCkOCoVXcq9awyERUzxpW/Pcvz5bOfLLyYY8v qLLFTAXylJSJvFCSlw8+M1aiFEcTzeVptOUl51yQbBxxooWh4Oc8BrhvBZsCZqO3 j5KEWKo7kGLN0pAfocXDHBktb3DVJBnQnyakrUFooz0BgoH+cfJ2te/dSSSNspvw TfPfydWC/ANg7FBkvuc4cZrH3PSGEfpnR7kcvFTfD56Pg2Q90i46gS3ikGdqHaA0 F3GOQ456J0sFpM3wjmIVvLV6OKnQG0jBNicrkyYOydw+YHTVwyhJN12VT7kAlYdc HUVdl18T+Fx2waf/J8sQLyrYoE8QQ0nEZ+8DC4/XXe7gkxwxSFfvD8fUTLnYRI8F TNfq1D+DnIQIQsEDEX5PYfgRAgNohKhzy6L+btLeyqLsqI1Vxak3cCJ40Zl68Pj8 NpTSvPchlSiUZNPRDD6moRIJdsSIfEGPDn6jjOntw4Go3gwg67jPl8btePBM3VWD 9WRAy6KGdX5rRWsrvH1Zrrmeqjsqe8kQ6t3vGbuU0Qcd7hDT4EoDWWTRafy8Nsbc BIag3UXSWtF27LLpw/0C+6wPDT9krdl01JMTPwc0li0tYYL8h7W3FfHe8jMvnOmT Z0bUn1hiBjaFftVpdlM0 =RWD4 -END PGP SIGNATURE- ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
On 05/19/2017 10:25 AM, Gervase Markham wrote: > Embedding SCTs is not the only way SCTs can be delivered - they can come > in the SSL handshake or via OCSP. Requiring them to be embedded does > have the advantage that certificates now carry an unforgeable timestamp, > and it was something I proposed in a version of Mozilla's now-dormant CT > policy. But for various reasons, it's not necessarily practical to > require it in all circumstances (which is why the CT RFC defines > multiple mechanisms). > > Firefox does have some support for checking SCT presence and validity, > but it's not turned on. > My concern here is right now, we're trying to rebuild trust for Symantec. We're very much in a "trust but verify" sorta thing, and I don't think it's an unjustified requirement to do so. I think CT is about the only thing that has allowed us to reasonably consider keeping Symantec in the root store at all. However, for Mozilla's purposes, is there a case where having a SCT in certificate would either break something, or otherwise be undesirable? Well, at least with the current state of webpki, mandating an embedded SCT is probably not practical for everyone. I actually forgot about the OCSP stapling mechanism for SCTs, though my concern here is not everyone turns on OCSP stapling. Since both OCSP CT stapling and embedded SCTs require that the cert be submitting to a log at issuance, part of me wonders if the right middle ground is this: As far as I know, I think Microsoft's IIS is the only major web server that turns OCSP stapling on out of the box. - By default, Symantec shall issue certificates with embedded SCTs (soft-fail for failure to validate SCT information) - If, due to customer demand, a certificate with an embedded SCT can not be used, said certificate must get the SCT information by a stapled OCSP response or via TLS extension to be trusted by Mozilla. (hard-fail) This should cover the general case fairly well, and for the edge cases, well either its for a special class of device that we don't care about, or the customer has to do some work to get things working in Mozilla. Or in other words, if there's a case where an embedded SCT can't fly here, then we mandate that one of the other two validation options must be present for things to fly. That being said, for my personal knowledge, I'd love to know more on the real world practicalities of embedding SCTs. Thanks for your feedback. >>> Are there any RA's left for Symantec? Following up to this, the question that I should have asked is who can technically do an issuance of certificates based on Symantec's roots. SSP customers are a recent discovery. I wonder if there's anything else. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Plan for Symantec posted
Comments inline. On 05/19/2017 05:10 PM, Jakob Bohm wrote: > Suggested trivial changes relative to the proposal for Mozilla use: > > 3. All non-expired Symantec issued certificates of any kind (including > SubCAs and revoked certificates) shall be CT logged as modified by #4 > below. All Symantec referenced OCSP responders shall return SCTs for > all such certificates, if possible even for revoked certificates. This > also applies to expired certificates that were intended for use with > validity extending timestamping, such as the code signing certificate > issued to Mozilla Corporation with serial number 25 cc 37 35 e9 ec 1f > c9 71 67 0e 73 e3 69 c7 91. Independent parties or root stores may at > their option use this data to generate public trust whitelists. > > Necessity: Whitelists in various forms based on such CT log entries, > as well as the SCTs in OCSP responses can provide an alternative for > relying parties checking current certificates even if the cleanup at > Symantec reveals a catastrophic breach during the past 20+ years. > > Proportionality: This should be relatively easy for the legitimate > certificates issued by Symantec, since the underlying data is still > used for OCSP response generation. > Sanity check here, but I thought that OCSP-CT-Stapling required SCTs to be created at the time of issuance. Not sure if there's a way to backdate this requirement. If this is only intended for the new roots then just a point of clarification. > 4. All stated requirements shall also apply to S/MIME certificates. I *really* like this since it solves the problem of S/MIME + CT, but I think this has to get codified into a specification. My second thought here though is that there's no way to independently check if the CT logs correspond to reality unless you have the public certificate since the hashed fields would cause the signature to break. I'd love to see this go somewhere but probably needs a fair bit of thought and possible use of a different CT log vs. the primarily webPKI ones. > > 5. All stated requirements shall also apply to SubCA certificates other > than the specially blessed "Managed CA" SubCAs. These shall never be > redacted. As a special exception, the root programs may unanimously on > a one-by-one bases authorize the signing of additional Managed SubCAs > and/or new infrastructure cross certificates, subject to full > validation and signing ceremonies. The root programs will authorize > enough new infrastructure cross signatures if and when they include the > roots of the new infrastructure. > Believe this was already covered by the PKI concerns that Symantec would not be allowed to use third-party validation. Not sure if we can realistically do a technical measure here since if we put a NotBefore check in NSS, we have no easy way to change it in the future if it becomes necessary for a one-off. > > 6. All stated requirements except premature expiry and the prohibition > against later issuance shall apply to delegated OCSP signing, CRL > signing and other such revocation/validation related signatures made > by the existing Symantec CAs and SubCAs, but after the first deadline > (ultimo August), such shall only be used for the continued provision of > revocation information, and shall have corresponding EKUs. This > corresponds to standard rules for dead CA certs, but adds CT logging of > any delegated revocation signing certificates. These shall never be > redacted. > I think this can be more easily put as "intermediate certificates restricted via EKU for use for OCSP/CRL shall always be trusted for purposes of maintain infrastructure". I don't think there's much risk of a subCA that's limited to these roles to general webPKI unless such a certificate was used to misissue a CRL that blacklisted all of Symantec's certificates (which wouldn't be our problem per say). > > 7. All stated requirements except the premature expiry shall apply to > time stamping signatures and certificates for timestamps > 8. As Mozilla products don't currently trust any code or object > signing certificates > 9. Symantec shall be allowed and obliged to continue operation of the > special "managed signing" services Can't help but feel that this is out of scope; Mozilla only cares about emailProtection and serverAuth EKU bits. A few CAs still have code signing bits in NSS due to historic reasons but Mozilla isn't a code-signing root store. What other root stores (especially those not related to WebPKI) is not our business. > 10. Symantec shall be allowed for marketing purposes ... I'm hesitant on this one because this requirement seems overly broad and out of line with current practice. Going to leave it for other people to poke at. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Plan for Symantec posted
On 05/19/2017 05:43 PM, Kurt Roeckx wrote: > So I think we have a few categories of certificates: > - Those issued in the past, which can still be valid for up to 3 > years. I'm not sure when the last 5 year certificates are > supposed to expire, or if they all expired, but I don't think > those take long to expire. > - Those that still get issued before they move to some new PKI. > > If you want to distrust their existing roots before those > certificates expire, this will most likely results in at least > some people having problems. And that it would be up to Symantec > to make sure those people get new certificates and started using > them. > When it boils down to that, I'm OK with the existing certs being allowed to age out (perhaps capped to 39 months total if there are any five year certificates still floating around) as long as new issuances are stopped from the old roots within a reasonable time frame. That being said, new issuances from the existing PKI should be capped on expiration. >>From the mail about Chrome's plan, I understand that Chrome's plan > is to only allow certificates from the old PKI if they qualify for > their CT requirements. They plan to only allow certificates issued > after 2016-06-01 because that's the date when they required CT > from Symantec. It seems that Symantec can still issue new certificates > using the old PKI up to 2017-08-08 that are still valid for 3 > years. > > I'm a little concerned that Firefox and Chrome will have different > certificates they don't trust, and would hope that you can come to > some agreement about when which one would get distrusted. > This was likely unavoidable due to the simple fact that the Google-Symantec discussions happened behind closed doors. Unless we can influence Google's final policy, then this is likely going to be the case no matter what. > I have a problem with one CA signing an other unrelated CA. I > would prefer that we have a policy that forbids that, and that the > CA should make sure it's own root gets added to the root store. > The only reason I can see for cross signing is for people that still > using an old root store. > ++ here >> - I'm not sold on the idea of requiring Symantec to use third-party CAs to >> perform validation/issuance on Symantec's behalf. The most serious concerns >> that I have with Symantec's old PKI is with their third-party subCAs and >> third-party RAs. I don't have particular concern about Symantec doing the >> validation/issuance in-house. So, I think it would be better/safer for >> Symantec to staff up to do the validation/re-validation in-house rather than >> using third parties. If the concern is about regaining trust, then add >> auditing to this. > The current proposal is more complicated than that since it talks about reusing part of the original validations and OIDs to control the max length of the certificate. I rather dislike that since its both complex, and introduces the trust issues from the old hierarchy into the new one which moots the point of spinning up a new root in the first place. > So they should just create new root CAs and ask them to be > included in the root store? > Honestly, we got into this mess in the first place due to third-party signers. I don't think the right solution to stopping a gas fire is to throw more gas on it. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Plan for Symantec posted
On 05/21/2017 02:37 PM, userwithuid wrote: > To me, the most noticable difference between how Google and Mozilla can take > action is with regards to exisiting certs. As proposed, Google has a really > neat timeline to get rid of Symantec's questionable legacy stuff quickly and > effectively. (Legacy stuff which we - and arguably Symantec themselves > judging from their responses on here so far - still don't have a complete > picture of). > There's also a fair number of points dealing with who can sign and for what while Symantec spins up the new roots (which the Google proposal says a trusted third party CA signed by Symantec"). I'm against this point specifically because third-party CA operations is how we got into this mess. I rather cap new certificate length from the existing roots as both a way to light a fire under Symantec and to avoid the same old mistakes. Michael ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy