Re: How to submit WebTrust audits in CCADB

[jomo via dev-security-policy]

I contacted CPA Canada in early 2017 about XSS and some other issues on
cert.webtrust.org.

They did not fix the issues but stated:

> CPA Canada is currently working on upgrading the WebTrust site to
> enhance the security.
As of April 2018 the issues were still unfixed. I wonder if the limited
access is part of those security "enhancements"?

PS: This change also breaks "legitimate" WebTrust Seal links when either
the website or the web browser is configured to not send the "Referer"
header.

jomo

On 10.8.18 01:19, Kathleen Wilson via dev-security-policy wrote:
> All,
>
> In their effort to better protect WebTrust seals, CPA Canada has made
> it so we can no longer access WebTrust pdf files directly from the CCADB.
>
> I received the following response when inquiring about this.
> “”
> Thank you for contacting Chartered Professional Accountants of Canada.
> You can no longer link directly to PDF documents. You will need to go
> to the registered website where the seal is provided and click on the
> seal to obtain the document (e.g. audit report).
> Also, we are now enforcing the domain requirement when a seal is
> opened.  Domain enforcement is essential to the program to prevent
> fraudulent use. It ensures that the WebTrust seals will only function
> on the certificate authority’s websites.
> If a seal is opened from a non-registered domain or other source (e.g.
> email, internal lists, etc.) the seal will not load and will display a
> notice indicating that the domain is not valid.
> “”
>
> Therefore, for the foreseeable future, please do the following when
> creating an Audit Case in the CCADB for WebTrust audits.
>
> 1) Make the PDFs of the audit statements available directly on your
> CA's website.
> OR
> Upload your audit statement PDF files to Bugzilla, as described here:
> https://ccadb.org/cas/fields#uploading-documents
>
> 2) For the audit statement link in your CCADB Audit Case either
> provide the URL to the PDF on your CA's website, or use the link to
> the document in Bugzilla.
>
> 3) Add a Audit Case Comment to indicate the URL where the WebTrust
> seals may be found on your CA’s website.
>
> 4) When you run the Audit Letter Validation (ALV), you can ignore the
> “Cleaned=Fail” ALV result. I will check the seal on your website
> manually, and add a comment to the Audit Case.
>
>
> Also, the cert.webtrust.org audit links that are currently in the root
> cert records and the intermediate cert records in the CCADB no longer
> work either. Fortunately we started archiving audit statements this
> year. So you can scroll down to the “File Archive…” section of the
> record, and you will be able to find the stored audit pdfs.
>
> Thanks,
> Kathleen
>
>
> ___
> 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[jomo via dev-security-policy]

On 17.4.18 06:24, Jakob Bohm via dev-security-policy wrote:
> I am not the only one with that expectation.  In the concrete case the
> expectation was succinctly stated by Mathew in Message-ID
> mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as
>
> Mathew> With respect to domain name labels, all CAs maintain high risk
> Mathew> lists.  I doubt  would issue for
> Mathew> paypal.any_valid_tld even if CAA would permit.
> [ Name of CA elided ]
> The question asked by Matthew and me, and which you keep blocking, is if
> jomo has publicly disclosed a case in which that CA's procedures
> accidentally fail to achieve that CA's security goals for those
> procedures.  This is a perfectly normally vulnerability issue
> investigation, which jomo (not I) made public 4 days ago.

I was merely interested if Matthew's statement was correct, as I assumed
it was not. This was not intended to be (and is not) a vulnerability
issue investigation. It turned out Let's Elide indeed does issue a
certificate [0], which I find nothing wrong with.

They maintain a blacklist of high risk domains, as has been discussed in
their community forums [1].
They do not make the list public, but have made previous statements
about it; they have, in the past, accidentally blacklisted permutations
of domains that were not malicious, but happened to use a similar name
as a "high risk" domain, which made them change their blacklisting
mechanisms [2]. They might, for example, blacklist TLD permutations of
"high risk" domains registered by the same corporation. In this case it
would include, for example, paypal.com and paypal.de, but not
paypal.cologne, as it is not registered by the same corporation (PayPal
Inc.) as the high risk paypal.com.

The BRs do not require CAs to exclude domains from DV only because a big
corporation uses a similar name. See also [3].


0: https://crt.sh/?id=393717424

1: https://community.letsencrypt.org/search?q=%22Name%20is%20blacklisted%22

2: https://community.letsencrypt.org/t/name-is-blacklisted-on-renew/9012/19

3: https://letsencrypt.org/2015/10/29/phishing-and-malware.html


jomo

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[jomo via dev-security-policy]

On 13.4.18 05:40, Matthew Hardeman via dev-security-policy wrote:
> Wow.  I’m impressed.
>
> Let’s Encrypt by their own declaration and by observed interactions in
> their community help forums maintains a high value blacklist of domains.
> It’s difficult to imagine how that list doesn’t include PayPal but did
> include mail.ru.

I would guess they do blacklist paypal.com but not paypal.*

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[jomo via dev-security-policy]

> I doubt Let's Encrypt would issue for paypal.any_valid_tld even if CAA would
> permit.

https://paypal.cologne :)


On 13.4.18 00:18, Matthew Hardeman via dev-security-policy wrote:
> Independent of EV, the BRs require that a CA maintain a High Risk
> Certificate Request policy such that certificate requests are scrubbed
> against an internal database or other resources of the CAs discretion.
>
> The examples particularly call out names that may be more likely to be used
> in phishing, etc., names that have previously been revoked, etc.
>
> How is declining issuance or revoking "Stripe, Inc" because of High Risk
> not consistent with that policy?  It's noteworthy that the intent appears
> to be security first (from the perspective of protecting relying parties)
> ahead of any right to get a certificate of any sort, much less an EV
> certificate.
>
> It's definitely a name that would be more likely to be used in phishing.
>
> With respect to domain name labels, all CAs maintain high risk lists.  I
> doubt Let's Encrypt would issue for paypal.any_valid_tld even if CAA would
> permit.
>
> This appears to be an extension of that kind of scrubbing to other Subject
> DN components.
> ___
> 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: How do you handle mass revocation requests?

[jomo via dev-security-policy]

> Basically, we're revoking 50k people without
> being able to explain why (well, other than the key was compromised). 

Unless I misunderstood, you originally said you received 23k compromised
keys and are revoking those.

> Currently, we are only revoking the certificates if we received the private
> keys. There are additional certificates the reseller requested to have
> revoked, but DigiCert has decided to disregard that request until we receive
> proof of compromise or more information about the cause of this incident.
Has DigiCert received proof of compromise of all 50k in the meantime?


On 28.2.18 22:42, Jeremy Rowley via dev-security-policy wrote:
> We don't have a process to prevent third parties from storing private keys.
> I'm not sure how that would even work considering the approved third-party
> use cases vs. non-approved use cases.  In fact, I'd postulate there's
> nothing wrong with Trustico holding the private keys if they were hosting
> the site or providing CDN services for all of these sites. The issue is
> Trustico alleged compromise of the certificates and sent us the private keys
> believed compromised in support. There were a lot of them. 
>
> This is a mass revocation without any explanation of what went wrong or why.
> The reseller mentioned and proved compromise, but there's no way to see if
> what happened, whether the issue was mitigated, or how it's going to be
> prevented from happening again. Basically, we're revoking 50k people without
> being able to explain why (well, other than the key was compromised). 
>
> -Original Message-
> From: dev-security-policy
> 
> On Behalf Of urijah--- via dev-security-policy
> Sent: Wednesday, February 28, 2018 2:24 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: How do you handle mass revocation requests?
>
> Is Trustico's storage of private keys related to this security report from a
> few months back (which did not appear to ever have been fully
> investigated...)?
>
> https://clicktime.symantec.com/a/1/gUJtIwxyRazHoxd9FIcS40cx3EykeGjrwv4urOpHj
> u0=?d=-1kl6pTbi8aU0HfRh9ZNP86TCSEsjm5TvumKZsLlfO6tgKV5N4_MitDAK64FGwutmiXu3D
> eTelMEfv3ep7X8kj6GIwMY8tUVM_WKGkqW_uhm0fHWgY9ZwlUytCHVYb_1WWceLMVi9w9Ec7h3sH
> G1wIJHWNk2L8RcVycGdrIGRFvV76QXqOck9szIT1MqOPD6gSaSZRnxp-ItDtBU5xSit2RwQjv5sB
> Ln2qFtnD9T_wuM6-KAeTUDm1O51uIY3NpT-q5hyIKG5YG-Ds6a9ceM0JgMrLhM3evdd-BmO3e6eP
> 1fXZXAQgJCZ_A7SnTbSagjzHzUVC65PN3AnrdJ6ANhZAwjjCdHdbjOeIqwInT-oFJ8lufSzaBeui
> OECQuf-IqhCnfsam6KnTGT5k-aQlG_BjOW8fny0TS21Upa4k4aX2Xm7es0oRfOUS-OxAQLVKCGg-
> cER_Pj3TmyKGPFFw_SzUky=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmozilla
> .dev.security.policy%2FCEww8w9q2zE%2FF_bzX1guCQAJ
>
> Does Digicert have (or will it have) some sort of process in place to
> prevent resellers from storing private keys so casually?
>
> On Wednesday, February 28, 2018 at 12:38:16 PM UTC-5, Jeremy Rowley wrote:
>> Hi everyone,
>>
>>  
>>
>> I wanted to share an incident report regarding the revocation of 
>> certain certificates ordered through a reseller.
>>
>>  
>>
>> On February 2nd, 2018, we received a request from Trustico to mass 
>> revoke all certificates that had been ordered by end users through
> Trustico.
>> Unfortunately, the email was not sent to the appropriate certificate 
>> problem reporting channels and did not surface immediately so we're 
>> delayed in sharing the concerns and information. Once we were alerted, 
>> the team kicked off a debate that I wanted to bring to the CAB Forum. 
>> Basically, our position is that resellers do not constitute 
>> subscribers under the Baseline Requirement's definitions (Section 
>> 1.6.1). As such, we needed to confirm that either the key was 
>> compromised or that they revocation was authorized by the domain 
>> holder (the subscriber) prior to revoking the certificate. The
> certificates were not alleged as compromised at that time.
>>  
>>
>> Later, the company shared with us that they held the private keys and 
>> the certificates were compromised, trying to trigger the BR's 24-hour 
>> revocation requirement.  However, we insisted that the subscriber must 
>> confirm the revocation request or there must be evidence of the private
> key compromise.
>>  
>>
>> Normally, we permit partners to revoke and manage the certificates 
>> freely on behalf of their customer, with DigiCert providing all 
>> validation and issuance services. However, the sheer number of 
>> revocation requests (50k) and allegation of compromise triggered 
>> concerns around the impact to the web and browser users. Therefore, 
>> this was categorized as high risk, especially considering the relationship
> between Trustico and DigiCert is terminating.
>>  
>>
>> On 2/27/2018, at my request for proof of compromise, we received a 
>> file with 23k private keys matched to specific Trustico customers. 
>> This definitely triggered our 24-hour revocation processing 

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[jomo via dev-security-policy]

IMHO it should be possible to affect the connection and the UI. This
would allow plug-ins for alternative certificate validation methods,
such as Convergence
(https://en.wikipedia.org/wiki/Convergence_%28SSL%29) / FreeSpeechMe
(https://bit.namecoin.org/freespeechme.html).

While I agree that it is a potentially dangerous capability, a bad
extension can already gain full access to a secure website's content.
Possibly the UI could reflect that an extension has changed the normal
validation result?

- jomo

On 27.2.18 17:20, Wayne Thayer via dev-security-policy wrote:
> I am seeking input on this proposal:
>
> Work is underway to allow Firefox add-ons to read certificate information
> via WebExtensions APIs [1]. It has also been proposed [2] that the
> WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to
> change or ignore the normal results of certificate validation.
>
> This capability existed in the legacy Firefox extension system that was
> deprecated last year. It was used to implement stricter security mechanisms
> (e.g. CertPatrol) and to experiment with new mechanisms such as Certificate
> Transparency and DANE.
>
> When used to override a certificate validation failure, this is a dangerous
> capability, and it’s not clear that requiring a user to grant permission to
> the add-on is adequate protection. One solution that has been proposed [4]
> is to allow an add-on to affect the connection but not the certificate UI.
> In other words, when a validation failure is overridden, the page will load
> but the nav bar will still display it as a failure.
>
> I would appreciate your constructive feedback on this decision. Should this
> capability be added to the Firefox WebExtensions APIs?
>
> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
> [3] https://mail.mozilla.org/pipermail/dev-addons/2018-February/003629.html
> [4] https://mail.mozilla.org/pipermail/dev-addons/2018-February/003641.html
> ___
> 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