Re: [Acme] ALPN based TLS challenge [invalid signature!]
On Fri, Feb 23, 2018 at 03:04:46PM +, Doug Beattie wrote: > > 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). Assuming that: - The hosting provoder has dependent HTTP and HTTPS (most do). - The hosting provoder supports sharing IP addresses between customers with HTTPS enabled, or maps each customer to dedicated address (AFAIK, all nowadays do either of these). - The hosting provoder is not vulernable to unauthorized certificate replacements (which is fundamentally exploitable for Denial of Service). Then this mechanism is secure against misvalidation. These two conditions are not sufficient for TLS-SNI-0x, because this method also requires assumption that the attacker can not claim arbitrary names. However, there are some provoders with indepedent HTTP and HTTPS. For example, the first provoder from the TLS-SNI misvalidation blogpost (which was not identified, and has probably fixed this already). Names hosted by these provoders can be attacked if the legimate owner does not have HTTPS set up. Specifically: Claim the name and then just validate it using some method related to HTTPS, the hosting provoder thinks it is yours. One can notice that the definition of method 6 has no provisions to not be vulernable in such context (method 6 is also vulernable to misvalidation if the victim has set up HTTPS but not HTTP). -Ilari ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ALPN based TLS challenge [invalid signature!] [invalid signature!]
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 <doug.beat...@globalsign.com> Datum: 2018-02-23 16:04 (GMT+01:00) 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> 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: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
Re: [Acme] ALPN based TLS challenge [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: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 "Sec
Re: [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 validat
