Exactly. But its also not the CA's responsibility if web host companies are 
insecure. Customers choosing insecure hosting companies and then having certs 
issued for their domains by attackers, have themselves to blame.
The problem was that web hosting companies were unaware about the SNI 
validation method, thus it was really not the customer's or webhost's fault. 
With ALPN, they have indicated "Yes we are aware about the security 
consequences for our customers. Lets continue anyways".
Then it's not really the CA's problem anymore, the CA has done everything in 
its power to ensure security.
-------- Originalmeddelande --------Från: Doug Beattie 
<doug.beat...@globalsign.com> Datum: 2018-02-23  16:04  (GMT+01:00) Till: 
Sebastian Nielsen <sebast...@sebbe.eu>, 'Roland Bracewell Shoemaker' 
<rol...@letsencrypt.org>, 'Rich Salz' <rs...@akamai.com> Kopia: 'IETF ACME' 
<acme@ietf.org>, 'Martin Thomson' <martin.thom...@gmail.com> Rubrik: RE: [Acme] 
ALPN based TLS challenge [invalid signature!] [invalid
  signature!] 

Oh yes, right.  The scope of attack is only those domains that point to the
same IP address.  But, this still relies on web hosting companies to have
secure configurations such that User A can’t get a cert for user B's domain
when they share the same IP address.

As a CA I like this and would be able to get method 9 added back,  but it
still has a dependency that the web hosting company is doing the right
thing, and that might be a concern (we'd be depending on a web server
configuration to enforce accurate domain validation).

If this has the endorsement of Google and Mozilla, I'm in for it also.

Doug

> -----Original Message-----
> From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> Sent: Friday, February 23, 2018 9:48 AM
> To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@gmail.com>
> Subject: SV: [Acme] ALPN based TLS challenge [invalid signature!]
> 
> Yes. The domain validated must still point to the correct server. This is
> true for both the old TLS-SNI-01 validation and the new ALPN validation.
> 
> -----Ursprungligt meddelande-----
> Från: Doug Beattie [mailto:doug.beat...@globalsign.com]
> Skickat: den 23 februari 2018 15:47
> Till: Sebastian Nielsen <sebast...@sebbe.eu>; 'Roland Bracewell Shoemaker'
> <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Kopia: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@gmail.com>
> Ämne: RE: [Acme] ALPN based TLS challenge [invalid signature!]
> 
> Does this prevent an advisory from setting up their own "hosting provider"
> and getting certificates for any domain on the internet?  We can’t assume
> all landlords are good.
> 
> Doug
> 
> > -----Original Message-----
> > From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> > Sent: Friday, February 23, 2018 9:43 AM
> > To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> > Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> > Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> > <martin.thom...@gmail.com>
> > Subject: SV: [Acme] ALPN based TLS challenge
> >
> > The problem was that there was hosting providers which did not know that
> the
> > SNI would be used in validation,
> > and did not limit or restrict which SNI names a customer could set up
> > content for, to the domain names that the customer had proofed ownership
> > of.
> >
> > The new ALPN based challenge, requires the server to explicitly say it
do
> > support validation, thus it means a hosting provider needs explicit
> > configuration of the TLS parameters to enable Lets Encrypt validation,
> thus
> > the risk that a hosting provider unknowingly allows a adversiary to
> > authenticate as a another customer on the same hosting platform is
> > eliminated.
> >
> > There is still the risk that a hosting provider explicitly sets up a
> server
> > which annouces support for TLS validation in ALPN, and still do allow
> > third-parties to set up validations for arbitary domain names.
> >
> > But then the error is on that hosting provider. Remember that the
security
> > issue ONLY appears if both the customer (which has legiitmate access to
a
> > domain) and the adversiary is on the same hosting provider, and in most
> > cases, even the same server.
> >
> > Thus there is the responsibility of the real customer to move away from
> any
> > hosting provider that have a explicit configuration that would allow a
> > adversiary to validate as that customer with ALPN enabled.
> >
> >
> > To make a analog comparisation:
> > Imagine a house with 4 apartments. Normally, each apartment should be
> > separate. But there is old houses with doors between apartments that are
> not
> > locked. A delivery guy comes with a package containing sensitive things,
> and
> > the delivery guy simply checks that the person receiving the package can
> > exit out of the correct apartment door.
> >
> > Due to the security risk in the house with the unlocked door between
each
> > apartment, any tenant can exit out of any apartment door, and thus
receive
> > the package, creating a security risk if a evil adversiary hires one of
> the
> > apartments.
> >
> > The ALPN challenge, is equvalient with a new sign the landlord can set
up
> on
> > the doors, that these apartments are "Secure". The delivery guy will
only
> > deliver to apartments that have a "Secure" sign. Thus the old apartments
> > lacking doors between the apartments will then not have any "Secure"
sign.
> > Yes, the landlord can set up a "Secure" sign even on insecure
apartments,
> > but thats an explicit action, and the passive security risk is
eliminated,
> > which means that if the landlord sets up the "Secure" sign on insecure
> > apartments, its the responsibility of the tenant to move away from
there.
> >
> > You understand now?
> >
> > -----Ursprungligt meddelande-----
> > Från: Acme [mailto:acme-boun...@ietf.org] För Doug Beattie
> > Skickat: den 23 februari 2018 14:18
> > Till: Roland Bracewell Shoemaker <rol...@letsencrypt.org>; Rich Salz
> > <rs...@akamai.com>
> > Kopia: IETF ACME <acme@ietf.org>; Martin Thomson
> > <martin.thom...@gmail.com>
> > Ämne: Re: [Acme] ALPN based TLS challenge
> >
> > I'm probably not understanding a key piece of technical info about the
> > protocol, but when I see this statement it makes me think it has similar
> > issues to tls-sni-01.  If we're relying on the hosting provider
enforcing
> > certain constraints like this, then we're delegating a critical piece of
> > domain control back to the hosting provider which would be a no-go.
> >
> > 4.  Security Considerations
> >
> >    The design of this challenges relies on some assumptions centered
> >    around how a server behaves during validation.
> >
> >    The first assumption is that when a server is being used to serve
> >    content for multiple DNS names from a single IP address that it
> >    properly segregates control of those names to the users on the server
> >    that own them.  This means that if User A registers Host A and User B
> >    registers Host B the server should not allow a TLS request using a
> >    SNI value for Host A that only User A should be able to serve that
> >    request.  If the server allows User B to serve this request it allows
> >    them to illegitimately validate control of Host A to the ACME server.
> >
> > Please let me know what I'm missing.
> >
> > Doug
> >
> > > -----Original Message-----
> > > From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Roland
> Bracewell
> > > Shoemaker
> > > Sent: Friday, February 23, 2018 3:00 AM
> > > To: Rich Salz <rs...@akamai.com>
> > > Cc: IETF ACME <acme@ietf.org>; Martin Thomson
> > > <martin.thom...@gmail.com>
> > > Subject: Re: [Acme] ALPN based TLS challenge
> > >
> > > Here is the ID:
> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-
> > > alpn/
> > >
> > > > On Feb 22, 2018, at 8:38 PM, Salz, Rich <rs...@akamai.com> wrote:
> > > >
> > > > Yes, like Martin said, submit the individual draft and we can call
for
> > adoption.
> > > >
> > >
> > > _______________________________________________
> > > Acme mailing list
> > > Acme@ietf.org
> > > https://www.ietf.org/mailman/listinfo/acme
> >
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to