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

[josh--- via dev-security-policy]

On Friday, January 12, 2018 at 9:38:42 PM UTC-6, jo...@letsencrypt.org wrote:
> On Thursday, January 11, 2018 at 4:29:09 PM UTC-6, jo...@letsencrypt.org 
> wrote:
> > On Thursday, January 11, 2018 at 3:36:50 PM UTC-6, Ryan Sleevi wrote:
> > > On Wed, Jan 10, 2018 at 4:33 AM, josh--- via dev-security-policy <
> > > dev-security-policy@lists.mozilla.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.
> > > >
> > > 
> > > (Wearing a Google Chrome hat on behalf of our root store policy)
> > > 
> > > Josh,
> > > 
> > > Thanks for bringing this rapidly to 

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

[josh--- via dev-security-policy]

On Thursday, January 11, 2018 at 4:29:09 PM UTC-6, jo...@letsencrypt.org wrote:
> On Thursday, January 11, 2018 at 3:36:50 PM UTC-6, Ryan Sleevi wrote:
> > On Wed, Jan 10, 2018 at 4:33 AM, josh--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.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.
> > >
> > 
> > (Wearing a Google Chrome hat on behalf of our root store policy)
> > 
> > Josh,
> > 
> > Thanks for bringing this rapidly to the attention of the broader community
> > and proactively reaching out to root programs.
> > 
> > As framing to the discussion, we still believe TLS-SNI is fully permitted
> > by the Baseline Requirements, which, while not ideal, still permits
> > issuance using this method. As such, the 'root' cause is that the Baseline
> > Requirements permit 

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Matt Palmer via dev-security-policy]

On Fri, Jan 12, 2018 at 02:52:54PM +, Doug Beattie via dev-security-policy 
wrote:
> I’d like to follow up on our investigation and provide the community with 
> some more information about how we use Method 9.
> 
> 1)  Client requests a test certificate for a domain (only one FQDN)

Does this test certificate chain to a publicly-trusted root?  If so, on what
basis are you issuing a publicly-trusted certificate for a name which
doesn't appear to have been domain-control validated?  If not, doesn't this
test certificate break the customer's SSL validation for the period the
certificate is installed, while you do the validation?

- Matt

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

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Ryan Sleevi via dev-security-policy]

On Fri, Jan 12, 2018 at 4:24 PM, Doug Beattie 
wrote:

> Wayne,
>
>
>
> We didn’t really investigate wildcard issuance yet, but we can.
>
>
>
> Given the discuss so far, we’re planning to proceed with a whitelisting
> approach tomorrow and we will plan to end the use of Method 9 (schedule
> TBD) which follows Let’s Encrypt handling of Method 10.  If there are any
> additional security concerns that we need to be made aware of, please let
> me know and we can adjust the plan accordingly.
>

(Wearing a Google Hat)

Doug,

Thanks for sharing additional details. On the basis of what you've shared
so far, we do not believe this results in an appropriate level of security
for the ecosystem, and request that you do not re-enable issuance at this
time. This applies for any CA using methods similar to what you're using.

Broadly speaking,
https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/HACyY9tMAAAJ
has shared the some of the principles we've used in this consideration. If
there is additional details that GlobalSign can share, related to those
principles, this would be invaluable.

This assessment is based on a number of factors, but includes:
- The validity period of certificates issued via this method means that
there is an unacceptably large window for certificates improperly issued to
be used.
- Based on the available information of expiration times and the potential
difficulty in renewing certificates using this method, the ecosystem risk
of disallowing this method is much less.
- The subtleties regarding Authorization Domain Names means that the risk
analysis provided is not sufficient - namely, it is unclear, as described,
whether it is possible to obtain a certificate for "www.example.com", on a
host that has a customer already configured on that domain (and
checking/enforcing certificates), by first applying for a certificate for "
example.com" as an attacker, providing and provisioning a test certificate
using that method (which is not configured to serve a certificate by the
'victim'), and then using that subsequent authorization of the
Authorization Domain Name to then apply for "www.example.com". Mitigating
this as a site operator would necessitate blocking not just on existant
domains, but also by the notion of Authorization Domain Name, and thus
represents a significant greater complexity in both assessing compliance
(for those on the whitelist) and for minimizing risk.
- The potential risk in maintaining this whitelist, given both the
statements provided by plans to move to deprecate this method post-haste
(e.g. no such plans) and the validity period of issued certificates (up to
39 months or, soon, 825 days).
- The lack of preexisting review and documentation of the specific protocol
being employed
- The potential risk of both domain name wildcards and of wildcard
issuance, which remains

While it is possible that you may be correct that the underlying root cause
of TLS-SNI presents greater risk, compared to this method, the many
mitigating factors that influenced our decision are not applicable here.

As this thread shows, we anticipate we will continue to find variants of
risk, and thus the whitelist approach, combined with the validity periods
caused by the risk (both of issued certificates and "completed
validations"), poses a long-term risk, even if we catch issues 'within
days'.

We'd like to continue discussing with GlobalSign and the community as to
the risk posed by immediately and permanently disabling this method, as
well as possible mitigations to the risk - both through issuance policies
of GlobalSign and technical measures in the usage - that may permit its
usage for a short-time to transition this method away. This is a
conversation we look forward to having over the next week. In the interim,
we'd ask you not re-enable this method.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident report: Failure to verify authenticity for some partner requests

[Bruce via dev-security-policy]

On Wednesday, January 10, 2018 at 4:24:54 PM UTC-5, Tim Hollebeek wrote:
 
> As you know, BR 3.2.5 requires CAs to verify the authenticity of a request
> for an OV certificate through a Reliable Method of Communication (RMOC).
> Email can be a RMOC, but in these cases, the email address was a constructed
> email address as in BR 3.2.2.4.4.  Despite the fact that these addresses are
> standardized in RFC 2142 or elsewhere, we do not believe this meets the
> standard of "verified using a source other than the Applicant
> Representative."

I agree. The intention for the constructed email from BR 3.2.2.4.4 was supposed 
to be to "confirm the Applicant's control over  the FQDN" and not to perform 
the BR 3.2.5 requirement "to verify the authenticity of the Applicant 
Representative’s certificate request."

I also don't think a CA should use the information from 3.2.2.4.2 (Email, Fax, 
SMS, or Postal Mail) or 3.2.2.4.3 (phone number) to get the BR 3.2.5 
authorization. The issue is the CA may end up using the same data to perform 
both 3.2.2.4 and 3.2.5 and will not mitigate the risk that the attacker 
controls the WHOIS data.

It would be more secure if the CA used two separate methods of communication 
for 3.2.2.4 and 3.2.5.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Doug Beattie via dev-security-policy]

Wayne,

We didn’t really investigate wildcard issuance yet, but we can.

Given the discuss so far, we’re planning to proceed with a whitelisting 
approach tomorrow and we will plan to end the use of Method 9 (schedule TBD) 
which follows Let’s Encrypt handling of Method 10.  If there are any additional 
security concerns that we need to be made aware of, please let me know and we 
can adjust the plan accordingly.

Doug


From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Friday, January 12, 2018 3:43 PM
To: Doug Beattie 
Cc: Gervase Markham ; r...@sleevi.com; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting 
environment

On Fri, Jan 12, 2018 at 11:21 AM, Doug Beattie 
> wrote:

Normally a web hosting provider should not let you set SNI for a domain someone 
else is using, especially on that IP address.  I think this is where method 9 
deviates from method 10.

I agree, it seems somewhat less likely that a hosting provider would allow 
someone to create a site for abc.example.com if one 
already exists on the same server. Are you aware of any hosting providers that 
do allow this? Also, did you consider wildcard DNS records in your analysis of 
the vulnerability? (see below)

For method 10, you set up SNI on your server and add the acme.invalid string 
associated with your request/cert.  Since nobody owns that invalid domain, the 
provider probably doesn’t care that you set up that SNI name and are using a 
certificate for that fqdn on their shared IP address.

It's also possible that the only thing the hosting provider checks is if there 
is already an SNI entry for that FQDN, in which case sites that aren't 
configured for TLS would be vulnerable.

For method 10 we look explicitly for the FQDN in the cert and there is no 
special SNI reconfiguration required (the site is there before, during and 
after the validation and issuance).

Are you confusing method 9 and method 10 in this sentence and the one below?
Yes, Method 9.

  Do hosting providers allow you to set SNI for domains you don’t own on a 
shared IP addresses?

I think that is exactly what has been found to be true.

  That sounds bad, but I defer to the experts here.  Method 9 does not require 
that.


Also, the ACME client actively support the process of allowing this random 
acme.invalid value to be tied to the real FQDN and looks for requests based on 
that SNI name.  All of the OneClick plugins (which btw, support similar 
features like client like key generation, cert installation and apache 
configuration), require that the FQDN being validated match the value in the 
certificate and the SNI server name.  Validation will fail when the SNI does 
not match what is expected.  The vast majority of OneClick endpoints are not 
vulnerable (yes, bad guys can modify the plugins and subvert the security we 
built in).  Yes, there is a vulnerability, but I think it’s a smaller scale 
than what’s in TLS-SNI-01.

Do you perform wildcard certificate validation with this method? If so, could 
someone create a site for evil.example.com on the same 
server as www.example.com and then get a cert for 
*.example.com by relying on a wildcard DNS record in the 
example.com zone (i.e. DNS responds to a query for 
evil.example.com with the IP for 
www.example.com)?



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

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Wayne Thayer via dev-security-policy]

On Fri, Jan 12, 2018 at 11:21 AM, Doug Beattie 
wrote:

>
>
> Normally a web hosting provider should not let you set SNI for a domain
> someone else is using, especially on that IP address.  I think this is
> where method 9 deviates from method 10.
>
>
>
I agree, it seems somewhat less likely that a hosting provider would allow
someone to create a site for abc.example.com if one already exists on the
same server. Are you aware of any hosting providers that do allow this?
Also, did you consider wildcard DNS records in your analysis of the
vulnerability? (see below)

For method 10, you set up SNI on your server and add the acme.invalid
> string associated with your request/cert.  Since nobody owns that invalid
> domain, the provider probably doesn’t care that you set up that SNI name
> and are using a certificate for that fqdn on their shared IP address.
>
>
>
It's also possible that the only thing the hosting provider checks is if
there is already an SNI entry for that FQDN, in which case sites that
aren't configured for TLS would be vulnerable.

For method 10 we look explicitly for the FQDN in the cert and there is no
> special SNI reconfiguration required (the site is there before, during and
> after the validation and issuance).
>

Are you confusing method 9 and method 10 in this sentence and the one
below?

  Do hosting providers allow you to set SNI for domains you don’t own on a
> shared IP addresses?
>

I think that is exactly what has been found to be true.

  That sounds bad, but I defer to the experts here.  Method 9 does not
> require that.
>
>
>


> Also, the ACME client actively support the process of allowing this random
> acme.invalid value to be tied to the real FQDN and looks for requests based
> on that SNI name.  All of the OneClick plugins (which btw, support similar
> features like client like key generation, cert installation and apache
> configuration), require that the FQDN being validated match the value in
> the certificate and the SNI server name.  Validation will fail when the SNI
> does not match what is expected.  The vast majority of OneClick endpoints
> are not vulnerable (yes, bad guys can modify the plugins and subvert the
> security we built in).  Yes, there is a vulnerability, but I think it’s a
> smaller scale than what’s in TLS-SNI-01.
>
>
>
Do you perform wildcard certificate validation with this method? If so,
could someone create a site for evil.example.com on the same server as
www.example.com and then get a cert for *.example.com by relying on a
wildcard DNS record in the example.com zone (i.e. DNS responds to a query
for evil.example.com with the IP for www.example.com)?

>
>
> While the vulnerabilities and risks are different between ACME TLS-SNI-01
> and OneClick,
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Taiwan GRCA Root Renewal Request

[Wayne Thayer via dev-security-policy]

On Thursday, June 1, 2017 at 5:03:15 PM UTC-7, Kathleen Wilson wrote:
> On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote:
> > On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote:
> > All, 
> > 
> > I requested that this CA perform a BR Self Assessment, and they have 
> > attached their completed BR Self Assessment to the bug here:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30
> > 
> > Aaron has reviewed and verified the BR Self Assessment.
> > 
> > Therefore, I plan to approve this request from the Government of Taiwan 
> > (GRCA) to include their "Government Root Certification Authority" root 
> > certificate, and turn on the Websites and Email trust bits, and constrain 
> > this root to *.tw. 
> > 
> > If there are no further concerns, then I will close this discussion and 
> > recommend approval in the bug.
> > 
> 
> After further consideration, I have decided to wait for the CA to provide 
> their updated CP/CPS that will address all of the shortcomings that they 
> noted in their BR Self Assessment that they plan to fix in the next version 
> of their CP/CPS.
> 
> So, this discussion will be on hold again until I have received and reviewed 
> their updated CP/CPS documents.

We have received the updated CP/CPS and have received and verified the most 
recent audits for this CA. Since we haven't yet implemented the changes to our 
inclusion process proposed by Kathleen a few days ago, I am now restarting 
discussion on this request, and I will post my comments once the CP/CPS review 
is completed.

I plan to recommend that the XCA, MOICA, and MOEACA sub-CAs be added to OneCRL 
because they are neither technically constrained or BR audited.

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

New Reports for CAA Identifiers and Problem Reporting Mechanisms

[Kathleen Wilson via dev-security-policy]

Just FYI that two new public reports are now available via the 
https://wiki.mozilla.org/CA/Included_CAs wiki page. One for Problem 
Reporting Mechanisms, and one for CAA identifiers.


Here's the direct links to the new reports:

https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport

https://ccadb-public.secure.force.com/mozilla/CAAIdentifiersReport

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

Re: CCADB Report: AllCertificateRecordsCSVFormat

[Kathleen Wilson via dev-security-policy]

On 11/15/17 1:48 PM, Kathleen Wilson wrote:

All,

The following report lists data for all root and intermediate cert 
records in the CCADB.


https://ccadb-public.secure.force.com/mozilla/AllCertificateRecordsCSVFormat 



A link to this report is here:
http://ccadb.org/resources

Cheers,
Kathleen




Just FYI that the following two columns have been added to the 
AllCertificateRecordsCSVFormat report.

1) Parent Salesforce Record ID
2) Parent SHA-256 Fingerprint

Cheers,
Kathleen


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

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Doug Beattie via dev-security-policy]

Wayne and Gerv,

I’ll try to answer both of your questions here.

From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Friday, January 12, 2018 11:03 AM
To: Doug Beattie 
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting 
environment

Doug,

I have some questions:

c.The hosting company must allow you to manually create and upload a 
CSR for a site you don’t own
Did you mean to say 'certificate' here instead of 'CSR'?
Yes, I meant to say certificate.


d.   The user must be able to trick the hosting provider to enable SNI for 
this domain and link it to the certificate they uploaded
Is 'trick' the right term here? Isn't this just a default configuration for 
vulnerable hosting providers?

From Gerv: Doug: what do you see as the exact differences between your setup 
and the TLS-SNI-01 configuration? It seems to me that both are vulnerable in 
the same circumstances (i.e., hosting provider has many users hosted on the 
same IP address, and users have the ability to upload certificates for 
arbitrary names without proving domain control).

Normally a web hosting provider should not let you set SNI for a domain someone 
else is using, especially on that IP address.  I think this is where method 9 
deviates from method 10.

For method 10, you set up SNI on your server and add the acme.invalid string 
associated with your request/cert.  Since nobody owns that invalid domain, the 
provider probably doesn’t care that you set up that SNI name and are using a 
certificate for that fqdn on their shared IP address.

For method 10 we look explicitly for the FQDN in the cert and there is no 
special SNI reconfiguration required (the site is there before, during and 
after the validation and issuance).  Do hosting providers allow you to set SNI 
for domains you don’t own on a shared IP addresses?  That sounds bad, but I 
defer to the experts here.  Method 9 does not require that.

Also, the ACME client actively support the process of allowing this random 
acme.invalid value to be tied to the real FQDN and looks for requests based on 
that SNI name.  All of the OneClick plugins (which btw, support similar 
features like client like key generation, cert installation and apache 
configuration), require that the FQDN being validated match the value in the 
certificate and the SNI server name.  Validation will fail when the SNI does 
not match what is expected.  The vast majority of OneClick endpoints are not 
vulnerable (yes, bad guys can modify the plugins and subvert the security we 
built in).  Yes, there is a vulnerability, but I think it’s a smaller scale 
than what’s in TLS-SNI-01.


While the vulnerabilities and risks are different between ACME TLS-SNI-01 and 
OneClick,

Can you explain this statement? My impression is that the same vulnerability 
affects both methods.
Listed above.


we’d like to propose a risk mitigation approach similar to Let’s Encrypt with 
the use of a whitelist.  We’ll verify that certain providers have secure 
practices in place to prevent users from requesting certificates outside of 
their permitted domains and then whitelist them.
Let's Encrypt  has stated that this is a short- to medium-term mitigation. Is 
your plan to continue to use this method indefinitely? Or are you ultimately 
planning to fix or deprecate the method?

If we’re required to deprecate this because of similar security concerns, we 
can do that.

If this is acceptable, we’d like to resume issuance today if possible.
If my understanding of the 3.2.2.4.9 vulnerability being essentially the same 
as the 3.2.2.4.10 vulnerability, then this seems reasonable to me, at least in 
the short term.

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

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Gervase Markham via dev-security-policy]

On 12/01/18 14:52, Doug Beattie wrote:
> For shared IP address environments, it may be possible to receive a
> certificate for a domain you don’t actually control, but a number of
> things need to happen in order for this to be successful.  What can
> go wrong?

Doug: what do you see as the exact differences between your setup and
the TLS-SNI-01 configuration? It seems to me that both are vulnerable in
the same circumstances (i.e., hosting provider has many users hosted on
the same IP address, and users have the ability to upload certificates
for arbitrary names without proving domain control).

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

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Wayne Thayer via dev-security-policy]

Doug,

I have some questions:

>
> c.The hosting company must allow you to manually create and upload
> a CSR for a site you don’t own
>
> Did you mean to say 'certificate' here instead of 'CSR'?

d.   The user must be able to trick the hosting provider to enable SNI
> for this domain and link it to the certificate they uploaded
>
> Is 'trick' the right term here? Isn't this just a default configuration
for vulnerable hosting providers?

While the vulnerabilities and risks are different between ACME TLS-SNI-01
> and OneClick,


Can you explain this statement? My impression is that the same
vulnerability affects both methods.

we’d like to propose a risk mitigation approach similar to Let’s Encrypt
> with the use of a whitelist.  We’ll verify that certain providers have
> secure practices in place to prevent users from requesting certificates
> outside of their permitted domains and then whitelist them.
>
> Let's Encrypt  has stated that this is a short- to medium-term mitigation.
Is your plan to continue to use this method indefinitely? Or are you
ultimately planning to fix or deprecate the method?

If this is acceptable, we’d like to resume issuance today if possible.
>
> If my understanding of the 3.2.2.4.9 vulnerability being essentially the
same as the 3.2.2.4.10 vulnerability, then this seems reasonable to me, at
least in the short term.

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

Re: Compromised certificate for localhost.cmdm.comodo.net / Comodo ITSM

[Rob Stradling via dev-security-policy]

Hanno, thanks for reporting this to us earlier today.

Mozilla, please consider adding https://crt.sh/?id=245397620 to OneCRL. 
Thanks.


On 12/01/18 15:33, Hanno Böck via dev-security-policy wrote:

Hi,

Comodo ITSM (IT Service Management Software) runs an HTTPS server on
localhost and port 21185. The domain localhost.cmdm.comodo.net pointed
to localhost.

It is obvious that with this setup the private key is part of the
application and thus compromised. With advanced next generation key
extraction software (strings and grep) I was able to extract the
private key from the software executable.

There exist two certificates that use the same key plus two
precertificates. Only one of the certificates is still valid, the other
is expired. List:
https://crt.sh/?spkisha256=accbb60afe2d28949e21d76f298a2f20c0a24488ad0980ea31b4c0e04b952879

I reported this to Comodo earlier today and the certificate got revoked
very quickly. It was pointed out to me that Comodo ITSM was developed
by Comodo Security Solutions and that Comodo CA played no part in the
development of that software.



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Compromised certificate for localhost.cmdm.comodo.net / Comodo ITSM

[Hanno Böck via dev-security-policy]

Hi,

Comodo ITSM (IT Service Management Software) runs an HTTPS server on
localhost and port 21185. The domain localhost.cmdm.comodo.net pointed
to localhost.

It is obvious that with this setup the private key is part of the
application and thus compromised. With advanced next generation key
extraction software (strings and grep) I was able to extract the
private key from the software executable.

There exist two certificates that use the same key plus two
precertificates. Only one of the certificates is still valid, the other
is expired. List:
https://crt.sh/?spkisha256=accbb60afe2d28949e21d76f298a2f20c0a24488ad0980ea31b4c0e04b952879

I reported this to Comodo earlier today and the certificate got revoked
very quickly. It was pointed out to me that Comodo ITSM was developed
by Comodo Security Solutions and that Comodo CA played no part in the
development of that software.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Doug Beattie via dev-security-policy]

Ryan,

I’d like to follow up on our investigation and provide the community with some 
more information about how we use Method 9.

We use a process that we refer to as OneClick to automate the domain validation 
and issuance of certificates by issuing a test certificate to an FQDN and then 
verifying that the certificate is present on that FQDN.  This is different from 
ACME method TLS-SNI-01, regardless of what some GlobalSign tweets may have 
mentioned.   Where dedicated IP addresses are used, we believe this method is 
safe and secure. So, I’ll focus this discussion on when there are shared IP 
addresses and SNI is used. This is how the OneClick validation works:

1)  Client requests a test certificate for a domain (only one FQDN)

2)  We issue a test certificate valid for 7 days

3)  Client places the test certificate on their server

4)  We connect to the server (DNS look-up and then use SNI to ask for the 
certificate)

5)  If the certificate is returned, the validation passes and we issue a 
production certificate which is downloaded and installed.  The issued 
certificate can have validity up to 39 months (soon 825 days)

For shared IP address environments, it may be possible to receive a certificate 
for a domain you don’t actually control, but a number of things need to happen 
in order for this to be successful.  What can go wrong?

1)  A user could request a test certificate for a domain they don’t own 
within a shared IP address environment.  In order for this to be successful:

a.   User must know which other sites are hosted on the same IP address 
(the attack is limited to the set of customers on that shared IP address)

b.   For this case, I’m assuming that sites don’t have TLS enabled (if they 
did when we went to validate them, we’d receive their certificate – more on 
this below in case 2)

c.The hosting company must allow you to manually create and upload a 
CSR for a site you don’t own

d.   The user must be able to trick the hosting provider to enable SNI for 
this domain and link it to the certificate they uploaded

2)  In the event that the target site does have TLS enabled and the 
attacker wants to override the account settings to provide this test 
certificate, they would need the provider to allow multiple accounts to claim 
the SNI traffic for that site. This scenario seems unlikely (and if they did, 
it would be generally insecure)

Our typical hosting customers have integrated certificate provisioning into 
their account/service set-up so a certificate can be provisioned quickly and 
easily.  Normally, there is no user involvement in key generation and the 
backend systems take care of this provisioning and would not allow test 
certificates to be uploaded other than for the purpose they are intended (to 
secure a specific site).  In this case, we don’t believe that there is a 
security issue since the system would be creating and validating 
domains/certificates as expected.

If users are able to initiate the domain validation process and if they are 
permitted to upload certificates for sites they don’t control, then there is a 
possibility that they could get a certificate for that domain.  We can’t 
control what every provider does, so this risk remains.

While the vulnerabilities and risks are different between ACME TLS-SNI-01 and 
OneClick, we’d like to propose a risk mitigation approach similar to Let’s 
Encrypt with the use of a whitelist.  We’ll verify that certain providers have 
secure practices in place to prevent users from requesting certificates outside 
of their permitted domains and then whitelist them.

If this is acceptable, we’d like to resume issuance today if possible.

Doug


From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, January 11, 2018 5:19 PM
To: Doug Beattie 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting 
environment



On Thu, Jan 11, 2018 at 4:50 PM, Doug Beattie via dev-security-policy 
>
 wrote:

Based on reported issues with TLS-SNI-01, we started investigation of our 
systems late yesterday regarding the use of "Test Certificate" validation, BR 
section  3.2.2.4.9.

We found that this method may be vulnerable to the some of the same underlying 
issue as the ACME TLS-SNI-01 so we disabled it at 10:51 AM today EST, January 
11th.

While TLS-SNI-01 uses a host name like 773c7d.13445a.acme.invalid, GlobalSign 
uses the actual host name, 
www.example.com which limits 
abuse, but we believe that the process might be vulnerable in some cases.

We're continuing to research this and will let you know what we find.

Doug

(Wearing a Chrome Hat, again)

Doug,

Thanks for the update. That seems consistent with Chrome's evaluation, as 
shared at 

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

[Jakob Bohm via dev-security-policy]

When I wrote my previous reply, I had not yet received Let's encrypt's
post in which they announced they would not reenable TLS-SNI-01
globally.  So this was written based on Let's encrypt only *temporarily*
disabling TLS-SNI-01 as stated in their original post and *allegedly*
(according to 3rd party posts) asking hosting providers to block uploads
of certificates for acme.invalid.

This situation has since changed, and most of my suggestions are thus
mostly moot.


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