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 <firstname.lastname@example.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 <email@example.com>; 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
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme