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 cant 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 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
