RE: Certificate with invalid dnsName issued from Baltimore intermediate
Nick, We are in discussions with Intesa Sanpaolo about implementing/pursuing OneCRL or a similar approach (e.g. outright revocation of the CAs). Thanks, Ben -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Nick Lamb via dev-security-policy Sent: Sunday, July 23, 2017 2:35 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificate with invalid dnsName issued from Baltimore intermediate On Sunday, 23 July 2017 20:12:18 UTC+1, Charles Reiss wrote: > This CA also issued a recent certificate for the unqualified dNSName > 'webinterfacestrong': https://crt.sh/?id=177606495 Another name that it shouldn't be possible to issue for, but this time one which can actually exist in local networks and therefore is put at risk by the existence of such bogus certificates. >From the view on https://crt.sh/ it appears that this CA does not automatically log all the certificates it issues which Mozilla will end up trusting. It may have issued certificates we haven't seen yet. DigiCert / Ben is that statement correct? If we cannot today see the "whole iceberg" of certificates issued by this subCA, and we know it can and does issue problematic certificates I think it's a good candidate for distrust in OneCRL. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)
On Monday, July 24, 2017 at 2:49:20 AM UTC-5, Gervase Markham wrote: > On 20/07/17 21:31, Ryan Sleevi wrote: > > Broadly, yes, but there's unfortunately a shade of IP issues that make it > > more difficult to contribute as directly as Gerv proposed. Gerv may accept > > any changes to the Mozilla side, but if the goal is to modify the Baseline > > Requirements, you'd need to sign the IPR policy of the CA/B Forum and join > > as an Interested Party before changes. > > I'm on holiday at the moment but, as Ryan says, this particular part of > what CAs do is the part most subject to IPR restrictions and so work on > it is probably best done in a CAB Forum context rather than a more > informal process. > > I will attempt to respond to your messages in more depth when I return. Hi, Gerv, I'm certainly willing and able to execute an IPR agreement in my own right and/or on behalf of my company. My concern is that I would like to have a more fully fleshed out proposal to bring to the forum. I have a strong understanding of the network and interconnection environment as pertains the issue of IP hijacking, etc, but significantly less understanding of the infrastructure side of the CA and so I feel rather limited in being able to structure mitigations which are practical for CAs to deploy. In short I can point out the weak spots and the potential consequences of the weak spots, and I can recommend mechanisms for reducing the risk, but I feel I could much better recommend specific solutions and frameworks for addressing the risks if I had a better understanding of typical CA interaction with the outside network as well as a firmer understanding of the various trust boundaries across the various CA elements. Thanks, Matt Hardeman ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)
On 22/07/2017 02:38, birge...@princeton.edu wrote: On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote: It seems that a group of Princeton researchers just presented a live theoretical* misissuance by Let's Encrypt. They did a sub-prefix hijack via a technique other than those I described here and achieved issuance while passing-through traffic for other destination within the IP space of the hijacked scope. They've got a paper at: https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf I say that theoretical because they hijacked a /24 of their own /23 under a different ASN but I am given to believe that the "adversarial" ASN is also under their control or that they had permission to use it. In as far as this is the case, this technically isn't a misissuance because hijacking ones own IP space is technically just a different routing configuration diverting the traffic to the destination they properly control to another point of interconnection they properly controlled. Hi, I am Henry Birge-Lee, one of the researchers at Princeton leading that effort. I just performed that live demo a couple hours ago. You are correct about how we performed that attack. One minor detail is that we were forced to use the same ASN twice (for both the adversary and the victim). The adversary and the victim were two different routers peering with completely different ASes, but we were forced to reuse the AS because we were performing the announcements with the PEERING testbed (https://peering.usc.edu/) and are not allowed to announce from another ASN. Thus from a policy point of view this was not a misissuance and our BGP announcements would likely not have triggered an alarm from a BGP monitoring system. Even if we had the ability to hijack another ASes prefix and trigger such alarms we would be hesitant to because of ethical considerations. Our goal was to demonstrate the effectiveness and ease of interception of the technique we used, not freak out network operators because of potential hijacks. I know some may argue that had we triggered alarms from the major BGP monitoring frameworks, CAs might not have issued us the certificates the did. We find that this is unlikely because 1) The DV certificate signing process is automated but the type of BGP announcements we made would likely require manual review before they could be definitively flagged as an attack 2) There is no evidence CAs are doing this (we know Let's Encrypt does not use BGP data because of their transparency and conversations with their executive director Josh Aas as well as their engineering team). Another testing option would have been to use another AS legitimately operated by someone associated with your research team. Unless Princeton has historically obtained 2 AS numbers (this is not uncommon), Cooperating with a researcher at another research facility could obtain the other AS number without any actual breach or hijack. As for further work, implementation of countermeasures into the CA and Browser forum Baseline Requirements is our eventual goal and we see engaging with this ongoing discussion as a step in the right direction. Over the next couple days I will look over these conversations in more detail and look for ways that we can integrate these ideas into the research we are doing. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Update on SubCA Proposal
Hi Rick, Some more thoughts on your post. I continue to invite community commentary on the issues we are discussing. On 21/07/17 07:00, Rick Andrews wrote: > In our June 1 post, we stated that we would update the community after the > end of the month. Indeed. I was more referring to the suggestions made in the meeting with Mozilla about when the public statement would be forthcoming. But no matter. > Correct. However, as we indicated in our update, with a change of > this magnitude we believe that there will likely be material > compatibility and interoperability issues that will only come to > light once server operators begin the transition to the Managed CA > issued certificates. Recognizing this, we recommend that we establish > a clear process to evaluate exception requests that includes > consultations with the browsers to handle such corner cases. Operators who have initial difficulty with the transition can, of course, stay on their certificates issued from the old infrastructure. (It's worth noting that if all of those customers had recently renewed their certificates, as my proposal suggests, then there would not be a problem with their existing-infra certs expiring while they were attempting to make the transition.) How would you see such an exception process working, and how would it be implemented technically? > While this is true under the terms of the SubCA proposal, we do not > believe this is consistent with the spirit of Google’s and Mozilla’s > prior commentary on their intent regarding the SubCA proposal, which > is to limit the issuance of Symantec certificates under Symantec’s > existing infrastructure and governance. I'm not sure how you reach that conclusion. We want to end new issuance in December, you want it to continue until next May. How are our dates more inconsistent than yours with a desire to limit the issuance of Symantec certificates under the existing infrastructure and governance? We want to limit it earlier. > dates. Accordingly, our intention and expectation is that the > majority of certificates issued before June 1, 2016 that will need to > be replaced before their expiration under the current SubCA proposal > will occur after the Managed CA is implemented. This will ensure > there are no limitations on the replacement certificates that are > issued to affected customers, which limits the substantial risks of > implementation problems if our customers are not given the > appropriate time to plan and execute their certificate replacements. It may be appropriate for the limitations on current-infra issuance lifetime in the plan to be adjusted by a few months such that a certificate issued now can continue to work until the full distrust date of November 1st, 2018. This would effectively mean that there are no (additional) limitations on the replacement certificates. > In our post we explained our rationale of why this period needs to be > a minimum of 9 months. It is important for the community to note the > significant operational burden and compatibility / interoperability > risks that our customers will face if they have to replace their > certificates once, let alone twice. Why do you see a compatibility and interoperability risk in the process of replacing a certificate with an identical certificate except that is a) definitely logged to CT, and b) has a later expiry date? You may argue that it's a customer operational burden but again, if customers have difficulty replacing their SSL certs in a 4-month timeframe, then they are not well positioned to deal with a number of potential crises in the SSL system, such as compromise (and distrust) of an intermediate, or compromise of their webservers. > Our recommendation for replacing certificates issued before June 1, > 2016 by May 1, 2018 (and preferably by February 1, 2019) enables a > single shift to our new PKI for SSL/TLS certificates and eliminates > any necessity for organizations to replace their certificates > multiple times. As noted above, I am not particularly impressed by arguments that "replacing our certificates twice in 2-3 years is too hard". It's also worth noting that in the timeline you propose, organizations would have only 5 months (Dec 1 2017 - May 1 2018), including the holiday period, to test and deploy the actual certificates they would be using from the Managed CAs - those which do carry compatibility risk. And it's only 3 months if they want to replace with fully-validated non-DV certificates. My plan allows 9 uninterrupted months for that, which gives significantly more scope to deal with unexpected compatibility problems caused by new algorithms, new chains, etc. etc. If customers are asking for time to manage a transition to a new hierarchy, and that is your key concern, the plan I am proposing gives them significantly more of it than yours does. > The practical effect of this suggestion is to require up to two early > replacements for affected customers of certificates
Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)
On 20/07/17 21:31, Ryan Sleevi wrote: > Broadly, yes, but there's unfortunately a shade of IP issues that make it > more difficult to contribute as directly as Gerv proposed. Gerv may accept > any changes to the Mozilla side, but if the goal is to modify the Baseline > Requirements, you'd need to sign the IPR policy of the CA/B Forum and join > as an Interested Party before changes. I'm on holiday at the moment but, as Ryan says, this particular part of what CAs do is the part most subject to IPR restrictions and so work on it is probably best done in a CAB Forum context rather than a more informal process. I will attempt to respond to your messages in more depth when I return. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
