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 <[email protected]> Datum: 2018-02-23 16:04 (GMT+01:00) Till: Sebastian Nielsen <[email protected]>, 'Roland Bracewell Shoemaker' <[email protected]>, 'Rich Salz' <[email protected]> Kopia: 'IETF ACME' <[email protected]>, 'Martin Thomson' <[email protected]> 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 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:[email protected]] > Sent: Friday, February 23, 2018 9:48 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 [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:[email protected]] > Skickat: den 23 februari 2018 15:47 > Till: Sebastian Nielsen <[email protected]>; '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 [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:[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
