Re: Arabtec Holding public key?

[Santhan Raj via dev-security-policy]

On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote:
> On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote:
> > (Resending after I typo'd the ML address)
> > 
> > At the risk of further embarrassing myself in the same week, while
> > working further on mimicking Firefox trust decisions I found this
> > pre-certificate for Arabtec Holding PJSC:
> > 
> > https://crt.sh/?id=926433948
> > 
> > Now there's nothing especially strange about this certificate, except
> > that its RSA public key is shared with several other certificates
> > 
> > https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26
> > 
> > ... such as the DigiCert Global Root G2:
> > 
> > https://crt.sh/?caid=5885
> > 
> > 
> > I would like to understand what happened here. Maybe I have once again
> > made a terrible mistake, but if not surely this means either that the
> > Issuing authority was fooled into issuing for a key the subscriber
> > doesn't actually have or worse, this Arabtec Holding outfit has the
> > private keys for DigiCert's Global Root G2
> > 
> > Nick.
> 
> AFAIK there's no requirement in the BRs or Mozilla Root Policy for CAs to 
> actually verify that the Applicant actually is in possession of the 
> corresponding private key for public keys included in CSRs (i.e., check the 
> signature on the CSR), so the most likely explanation is that the CA in 
> question did not check the signature on the Applicant-submitted CSR and 
> summarily embedded the supplied public key in the certificate (assuming 
> Digicert's CA infrastructure wasn't compromised, but I think that's highly 
> unlikely).
> 
> A very similar situation was brought up on the list before, but with WoSign 
> as the issuing CA: 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/zECd9J3KBW8/OlK44lmGCAAJ
> 
> Thanks,
> Corey

While not a BR requirement, the CA's CPS does stipulate validating possession 
of private key in section 3.2.1 (looking at the change history, it appears this 
stipulation existed during the cert issuance). So something else must have 
happened here.

Except for the Arabtec cert, the other certs looks like cross-sign for the 
Digicert root. 

Thanks,
Santhan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GoDaddy Underscore Revocation Disclosure

[Santhan Raj via dev-security-policy]

On Friday, February 8, 2019 at 7:25:08 PM UTC-8, Jakob Bohm wrote:
> On 09/02/2019 01:36, Santhan Raj wrote:
> > On Friday, February 8, 2019 at 4:09:32 PM UTC-8, Joanna Fox wrote:
> >> I agree on the surface this bug appears to be the same, but the root cause 
> >> is a different. The issue for bug 1462844 was a specific status not 
> >> counting as active when it was. To mitigate this issue, we updated the 
> >> query to include the missing status. However, we are in the process of 
> >> simplifying the data structures to simplify these types of queries.
> >>
> >> For the underscore certificates, these were non-active, not even 
> >> considered as provisioned since they were not delivered to a customer and 
> >> not publicly used for any encryption. These certificates were effectively 
> >> abandoned by our system.
> > 
> > Is the term "certificate" accurate in this case? Assuming you embed SCTs 
> > within the EE cert, what you have is technically a pre-cert that was 
> > abandoned (not meant to be submitted to CT). Right? I ask because both the 
> > cert you linked are pre-certs, and I understand signing a pre-cert is 
> > intent to issue and is treated the same way, but still wanted to clarify.
> > 
> > Or by non-active certificate, are you actually referring to a fully signed 
> > EE that was just not delivered to the customer?
> > 
> 
> And in either case, the only reasonable sequences of events within
> expectations (and possibly within requirements) would have been:
> 
> Good Scenario A:
> 1. Pre-certificate is logged in CT.
> 2. Matching certificate is signed by CA key.
> 3. Signed certificate is logged in CT.
> 4. At this point the customer _might_ retrieve the certificate from CT
>without knowledge of CA.
> 5. Thus certificate is in reality active, despite any records the CA
>may have of not delivering it directly to customer.
> 
> Good Scenario B:
> 1. Pre-certificate is logged in CT.
> 2. CA decides (for any reason) not to actually sign the actual
>certificate.
> 3. The serial number listed in the CT pre-certificate is formally
>revoked in CRL and OCSP.  This is done once the decision not to
>sign is final.
> 4. If possible, label these revocations differently in CRL and OCSP
>responses, to indicate to independent CT auditors that the EE was
>never signed and therefore not logged to CT.
> 
> Scenario B should be very rare, as the process from pre-cert logging to
> final cert logging should typically be automatic or occur within a
> single root key ceremony. Basically, something unusual would have to
> happen at the very last moment, such as an incoming report that a
> relied-upon external system (Global DNS, Internet routing, reliable
> identity database etc.) may have been compromised during the vetting.
> 
> In neither case would a CT-logged serial number be left in a
> not-active but not-revoked state beyond a relevant procedural
> delay.
> 
> As pointed out in other recent cases, CA software must allow
> revoking a certificate without making it publicly valid first, in
> case Scenario B happens.
> 
> 
> 
> 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

My assumption is,

1) Pre-cert is generated
2) something breaks
3) pre-cert is never submitted to CT (and is termed a non-active certificate)

The basis for my assumption is "In rare cases, due to an order of operation 
problem, non-active certificates were being logged to CT." and in another 
response "These non-active certificates were revoked and we are taking steps to 
prevent non-active certificates from being logged to CT within the next 2 
weeks. "

There is no reason to "prevent non-active certificates from being logged to CT" 
if the pre-cert is already in CT. To me, it makes sense to say "prevent 
non-active pre-cert from being logged to CT". 

Thanks,
Santhan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regional BGP hijack of Amazon DNS infrastructure

[Santhan Raj via dev-security-policy]

On Wednesday, April 25, 2018 at 1:57:28 AM UTC-7, Ryan Hurst wrote:
> On Tuesday, April 24, 2018 at 5:29:05 PM UTC+2, Matthew Hardeman wrote:
> > This story is still breaking, but early indications are that:
> > 
> > 1.  An attacker at AS10297 (or a customer thereof) announced several more
> > specific subsets of some Amazon DNS infrastructure prefixes:
> > 
> > 205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24
> > 
> > 2.  It appears that AS10297 via peering arrangement with Google got
> > Google's infrastructure to buy (accept) the hijacked advertisements.
> > 
> > 3.  It has been suggested that at least one of the any cast 8.8.8.8
> > resolvers performed resolutions of some zones via the hijacked targets.
> > 
> > It seems prudent for CAs to look into this deeper and scrutinize any domain
> > validations reliant in DNS from any of those ranges this morning.
> 
> This is an example of why ALL CA's should either already be doing 
> multi-perspective domain control validation or be working towards that in the 
> very near future.
> 
> These types of attacks are far from new, we had discussions about them back 
> in the early 2000s while at Microsoft and I know we were not the only ones. 
> One of the earlier papers I recall discussing this topic was from the late 08 
> timeframe from CMU - 
> https://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/
> 
> The most recent work on this I am aware of is the Princeton paper from last 
> year: http://www.cs.princeton.edu/~jrex/papers/bamboozle18.pdf
> 
> As the approved validation mechanisms are cleaned up and hopefully reduced to 
> a limited few with known security properties the natural next step is to 
> require those that utilize these methods to also use multiple perspective 
> validations to mitigate this class of risk.
> 
> Ryan Hurst (personal)

What is interesting to me is the DV certificate that Amazon had issued for 
myetherwallet.com (https://crt.sh/?id=108721338) and this certificate expired 
on Apr 23rd 2018. 

Could it be that the attackers were using this cert all along in place of a EV 
cert?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Santhan Raj via dev-security-policy]

On Wednesday, January 10, 2018 at 1:33:31 AM UTC-8, jo...@letsencrypt.org wrote:
> At approximately 5 p.m. Pacific time on January 9, 2018, we received a report 
> from Frans Rosén of Detectify outlining a method of exploiting some shared 
> hosting infrastructures to obtain certificates for domains he did not 
> control, by making use of the ACME TLS-SNI-01 challenge type. We quickly 
> confirmed the issue and mitigated it by entirely disabling TLS-SNI-01 
> validation in Let’s Encrypt. We’re grateful to Frans for finding this issue 
> and reporting it to us.
> 
> We’d like to describe the issue and our plans for possibly re-enabling 
> TLS-SNI-01 support.
> 
> Problem Summary
> 
> In the ACME protocol’s TLS-SNI-01 challenge, the ACME server (the CA) 
> validates a domain name by generating a random token and communicating it to 
> the ACME client. The ACME client uses that token to create a self-signed 
> certificate with a specific, invalid hostname (for example, 
> 773c7d.13445a.acme.invalid), and configures the web server on the domain name 
> being validated to serve that certificate. The ACME server then looks up the 
> domain name’s IP address, initiates a TLS connection, and sends the specific 
> .acme.invalid hostname in the SNI extension. If the response is a self-signed 
> certificate containing that hostname, the ACME client is considered to be in 
> control of the domain name, and will be allowed to issue certificates for it.
> 
> However, Frans noticed that at least two large hosting providers combine two 
> properties that together violate the assumptions behind TLS-SNI:
> 
> * Many users are hosted on the same IP address, and
> * Users have the ability to upload certificates for arbitrary names without 
> proving domain control.
> 
> When both are true of a hosting provider, an attack is possible. Suppose 
> example.com’s DNS is pointed at the same shared hosting IP address as a site 
> controlled by the attacker. The attacker can run an ACME client to get a 
> TLS-SNI-01 challenge, then install their .acme.invalid certificate on the 
> hosting provider. When the ACME server looks up example.com, it will connect 
> to the hosting provider’s IP address and use SNI to request the .acme.invalid 
> hostname. The hosting provider will serve the certificate uploaded by the 
> attacker. The ACME server will then consider the attacker’s ACME client 
> authorized to issue certificates for example.com, and be willing to issue a 
> certificate for example.com even though the attacker doesn’t actually control 
> it.
> 
> This issue only affects domain names that use hosting providers with the 
> above combination of properties. It is independent of whether the hosting 
> provider itself acts as an ACME client.
> 
> Our Plans
> 
> Shortly after the issue was reported, we disabled TLS-SNI-01 in Let’s 
> Encrypt. However, a large number of people and organizations use the 
> TLS-SNI-01 challenge type to get certificates. It’s important that we restore 
> service if possible, though we will only do so if we’re confident that the 
> TLS-SNI-01 challenge type is sufficiently secure.
> 
> At this time, we believe that the issue can be addressed by having certain 
> services providers implement stronger controls for domains hosted on their 
> infrastructure. We have been in touch with the providers we know to be 
> affected, and mitigations will start being deployed for their systems shortly.
> 
> Over the next 48 hours we will be building a list of vulnerable providers and 
> their associated IP addresses. Our tentative plan, once the list is 
> completed, is to re-enable the TLS-SNI-01 challenge type with vulnerable 
> providers blocked from using it.
> 
> We’re also going to be soliciting feedback on our plans from our community, 
> partners and other PKI stakeholders prior to re-enabling the TLS-SNI-01 
> challenge. There is a lot to consider here and we’re looking forward to 
> feedback.
> 
> We will post more information and details as our plans progress.

As others have mentioned, the transparency in the disclosure and quick response 
is applaudable. However, it doesn't mention anything about whether anyone has 
exploited this already. Have you started analyzing your existing certs to see 
if any may have been mis-issued? If so, how?

Thanks,
Santhan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[Santhan Raj via dev-security-policy]

On Wednesday, August 2, 2017 at 6:44:51 PM UTC-7, Peter Bowen wrote:
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
>  wrote:
> > Today, DigiCert and Symantec announced that DigiCert is acquiring the
> > Symantec CA assets, including the infrastructure, personnel, roots, and
> > platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
> > will validate and issue all Symantec certs as of Dec 1, 2017.  We are
> > committed to meeting the Mozilla and Google plans in transitioning away from
> > the Symantec infrastructure. The deal is expected to close near the end of
> > the year, after which we will be solely responsible for operation of the CA.
> > From there, we will migrate customers and systems as necessary to
> > consolidate platforms and operations while continuing to run all issuance
> > and validation through DigiCert.  We will post updates and plans to the
> > community as things change and progress.
> >
> > Thanks a ton for any thoughts you offer.
> 
> Jeremy,
> 
> A while ago I put together a list of all the certificates that are or
> were included in trust stores that were known to be owned by Symantec
> or companies that Symantec acquired.  The list is in Google Sheets at
> https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdRDGFuGehdzcvo8/edit?usp=sharing
> 
> Can you confirm that DigiCert will be "solely responsible for
> operation" of all of these CAs once the deal closes?
> 
> Thanks,
> Peter

Hi Jeremy,

A similar question regarding Symantec's CT log infrastructure. Are they part of 
the deal and do you plan to continue hosting them?

Thanks,
Santhan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

[Santhan Raj via dev-security-policy]

On Wednesday, June 21, 2017 at 12:02:51 PM UTC-7, Jonathan Rudenberg wrote:
> > On Jun 21, 2017, at 14:41, urijah--- via dev-security-policy 
> >  wrote:
> > 
> > Apparently, in at least one case, the certificate was issued directly(!) to 
> > localhost by Symantec.
> > 
> > https://news.ycombinator.com/item?id=14598262
> > 
> > subject=/C=US/ST=Florida/L=Melbourne/O=AuthenTec/OU=Terms of use at 
> > www.verisign.com/rpa (c)05/CN=localhost
> > issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
> > https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
> > reply
> > 
> > Is this a known incident?
> 
> Here is the (since expired) certificate: 
> https://crt.sh/?q=07C4AD287B850CAA3DD89656937DB1217067407AA8504A10382A8AD3838D153F

As bad as it may sound, issuing certs for internal server name from a public 
chain was allowed until Oct 2015 (as per BR).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued/Suspicious Symantec Certificates

[Santhan Raj via dev-security-policy]

On Friday, February 24, 2017 at 5:12:43 PM UTC-8, Peter Bowen wrote:
> "auditing standards that underlie the accepted audit schemes found in
> Section 8.1"
> 
> This is obviously a error in the BRs.  That language is taken from
> Section 8.1 and there is no list of schemes in 8.1.
> 
> 8.4 does have a list of schemes:
> 1. WebTrust for Certification Authorities v2.0;
> 2. A national scheme that audits conformance to ETSI TS 102 042/ ETSI
> EN 319 411-1;
> 3. A scheme that audits conformance to ISO 21188:2006; or
> 4. If a Government CA is required by its Certificate Policy to use a
> different internal audit scheme, it MAY use such scheme provided that
> the audit either (a) encompasses all requirements of one of the above
> schemes or (b) consists of comparable criteria that are available for
> public review.
> 
> 1. is slight problematic as no scheme exists by that name, but "Trust
> Service Principles and Criteria for Certification Authorities Version
> 2.0" does exist, which is what I assume is meant.
> 
This is something that should be fixed in the BR and in fact both the audit 
schemes (WTCA & WTBR) should be listed in Section 8.4 (obviously WTCA by itself 
doesn't cover all BR requirements, only WTBR does). While your assumption is 
just, Section 1.6.3 has the following reference, so its hard to tell what the 
intent is.

WebTrustfor Certification   Authorities ,   SSL 
BaselinewithNetwork Security,   Version 2.0,available   
at
http://www.webtrust.org/homepage‐documents/item79806.pdf.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GoDaddy Misissuance Action Items

[Santhan Raj via dev-security-policy]

On Monday, February 13, 2017 at 3:14:06 PM UTC-8, Santhan Raj wrote:
> On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote:
> 
> > That is why, despite some IPR-related tangles, Mozilla will be requiring
> > in its next CA Communication that all CAs move to using only those
> > documented methods in a fairly short timeframe, regardless of what the
> > BRs say. CAs may wish to not wait for that communication to arrive
> > before starting to adapt their systems.
> 
> Grev,
> 
> One thing to highlight here is that the WebTrust audits are performed against 
> the BRs and not against the root program requirements. I.e., unless ballot 
> 169 makes it to the BRs, a (naughty) CA may still chose to use "any other 
> method" and it will not be flagged in the audit report, provided they 
> disclose as such in the CP/CPS. This means, Mozilla will have to review 
> (each) CA's CP/CPS to determine whether it validates _only_ using methods 
> specified in "the documented methods" and will have to do so for each CP/CPS 
> update. So hopefully 169  makes it's way to BR soon.
> 
> -Santhan

And sorry I misspelled you name!!!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GoDaddy Misissuance Action Items

[Santhan Raj via dev-security-policy]

On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote:

> That is why, despite some IPR-related tangles, Mozilla will be requiring
> in its next CA Communication that all CAs move to using only those
> documented methods in a fairly short timeframe, regardless of what the
> BRs say. CAs may wish to not wait for that communication to arrive
> before starting to adapt their systems.

Grev,

One thing to highlight here is that the WebTrust audits are performed against 
the BRs and not against the root program requirements. I.e., unless ballot 169 
makes it to the BRs, a (naughty) CA may still chose to use "any other method" 
and it will not be flagged in the audit report, provided they disclose as such 
in the CP/CPS. This means, Mozilla will have to review (each) CA's CP/CPS to 
determine whether it validates _only_ using methods specified in "the 
documented methods" and will have to do so for each CP/CPS update. So hopefully 
169  makes it's way to BR soon.

-Santhan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy