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:[email protected]] > Sent: Friday, February 23, 2018 9:43 AM > To: Doug Beattie <[email protected]>; 'Roland Bracewell > Shoemaker' <[email protected]>; 'Rich Salz' <[email protected]> > Cc: 'IETF ACME' <[email protected]>; 'Martin Thomson' > <[email protected]> > 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:[email protected]] För Doug Beattie > Skickat: den 23 februari 2018 14:18 > Till: Roland Bracewell Shoemaker <[email protected]>; Rich Salz > <[email protected]> > Kopia: IETF ACME <[email protected]>; Martin Thomson > <[email protected]> > Ä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:[email protected]] On Behalf Of Roland Bracewell > > Shoemaker > > Sent: Friday, February 23, 2018 3:00 AM > > To: Rich Salz <[email protected]> > > Cc: IETF ACME <[email protected]>; Martin Thomson > > <[email protected]> > > 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 <[email protected]> wrote: > > > > > > Yes, like Martin said, submit the individual draft and we can call for > adoption. > > > > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
