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 cant 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
