Re: [Acme] Fixing the TLS-SNI challenge type

On 12.01.18 04:06, Roland Bracewell Shoemaker wrote: > I'm actually going to roll back my thoughts on the SNI value. Thinking > about this more I think it does actually make sense to revert to using > the actual host name here. > > In the initial design of the TLS-SNI challenge the

Re: [Acme] Fixing the TLS-SNI challenge type

So the original source of the TLS-SNI-01 in-the-field vulnerability that caused Let’s Encrypt to disable TLS-SNI-01 has just openly published details of the exploit he demonstrated:

[Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Hi, I've seen the proposal of Jonathan Rudenberg in [1] to use ALPN to fix the recently discovered problems with the TLS-SNI challenge [2]. While I think the usage of ALPN will fix the problem at hand, requiring support for ALPN on the frontend web servers, accelerators and so on at big

Re: [Acme] Fixing the TLS-SNI challenge type

> On Jan 11, 2018, at 22:46, Matthew D. Hardeman wrote: > > Hi, guys, > > I’m entirely new to this list and not sure whether or not I’m welcome, but I > have some comments on the ALPN idea. > > In order to actually be an improvement in security, the ALPN needs to be

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

> I did want to say that if an acceptable mechanism is found in this manner, > it does help with some but not all in-band TLS validation mechanisms. It > works for web server cases. It does not fully replace the mechanisms of > the TLS-SNI sort because it would not work for other protocols

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Not that I think that’s a sane or normal thing to do. But apparently it’s a thing people are doing. I didn’t know about it either until I saw this twitter post and did a little research on it. https://twitter.com/eey0re/status/951622012211900416 > On Jan 12, 2018, at 10:36 AM, Matthew D.

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

On Fri, Jan 12, 2018 at 06:03:34PM +0100, Gerd v. Egidy wrote: > > That is still vulernable to default-vhost issues if: > > > > - The hoster does not explicitly reserve default vhost (I have seen that > > kind of behavior with http:// too). > > - The hoster lets customers upload arbitrary

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

On Fri, Jan 12, 2018 at 05:20:39PM +0100, Gerd v. Egidy wrote: > > The problem mentioned with running HTTP-01 over HTTPS was the default-vhost > problem. But that could be avoided with checking the SAN like this: > > The client creates a self-signed certificate or uses a certificate signed > by

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Yes. But there are people forwarding that to the other service port so their application only has one real listener and then that non HTTP TLS server still manages to complete the TLS-SNI challenge (via port 443). > On Jan 12, 2018, at 10:33 AM, Gerd v. Egidy >

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

On Fri, Jan 12, 2018 at 10:46:47AM -0600, Matthew D. Hardeman wrote: > > > > On Jan 12, 2018, at 10:42 AM, Ilari Liusvaara > > wrote: > > > > On Fri, Jan 12, 2018 at 05:20:39PM +0100, Gerd v. Egidy wrote: > > > > That is still vulernable to default-vhost issues if:

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

> On Jan 12, 2018, at 10:42 AM, Ilari Liusvaara > wrote: > > On Fri, Jan 12, 2018 at 05:20:39PM +0100, Gerd v. Egidy wrote: >> >> The problem mentioned with running HTTP-01 over HTTPS was the default-vhost >> problem. But that could be avoided with checking the SAN

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

On Fri, Jan 12, 2018 at 10:28:31AM -0600, Matthew D. Hardeman wrote: > > > On Jan 12, 2018, at 10:20 AM, Gerd v. Egidy > > wrote: > > > I did want to say that if an acceptable mechanism is found in this > manner, it does help with some but not all in-band TLS

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

> That is still vulernable to default-vhost issues if: > > - The hoster does not explicitly reserve default vhost (I have seen that > kind of behavior with http:// too). > - The hoster lets customers upload arbitrary certificates. I think you also need: - A user is able to trick the server

Re: [Acme] Challenge "errors" -> "error"

+1 - I'm in favour of this change as well. On Thu, Jan 11, 2018 at 7:24 PM, Jonathan Rudenberg wrote: > > > On Jan 8, 2018, at 13:37, Jacob Hoffman-Andrews wrote: > > > > In the course of testing Let's Encrypt's ACME v2 endpoint, we realized > > that the

Re: [Acme] Fixing the TLS-SNI challenge type

Breaking that on purpose is actually why I most believe that the SNI should be required to reflect the exact SNI of the domain label being validated. The threat model I was concerned about evaporates if the SNI is the actual domain label and the decisioning of which TLS certificate to present

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

> On Jan 12, 2018, at 10:20 AM, Gerd v. Egidy > wrote: > > - As TLS-SNI-01/02 before, it is done completely via HTTPS on TCP port 443. > So > if HTTPS is the protocol you want to use the cert for, you wouldn't need > access to an additional TCP port like

Re: [Acme] Removing TLS-SNI-02, plans for continuation of last-call

> > This removes the "tls" error. I do not think this is appropriate, as http-01 > can redirect to https://, and such validation can hit TLS errors. Good point. I didn't consider HTTP-01 :80 -> :443. Restored in

[Acme] Removing TLS-SNI-02, plans for continuation of last-call

Hello folks, As I'm sure many of you are aware by now, recent developments[0] [1] [2] have identified real-world server/hosting configurations that violate the assumptions of TLS-SNI-01 as well as its currently specified replacement, TLS-SNI-02. In light of these issues and the feasibility of

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Yes. That can happen. I forget the name of it, but there was a historic web hosting framework that, in order to improve IP address costs AND maximize compatibility for those upgrading to TLS (non-SNI etc), encouraged the ultimate configuration: For a given IP address, a large number N of

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

> > I think you also need: > > > > - A user is able to trick the server into serving his document root as > > default vhost > > > > - The webserver serves the default tls vhost, even if the CA requested a > > specific vhost via SNI > > Well, I think both are impiled by default vhost. The first

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

On Fri, Jan 12, 2018 at 06:21:00PM +0100, Gerd v. Egidy wrote: > > > I think you also need: > > > > > > - A user is able to trick the server into serving his document root as > > > default vhost > > > > > > - The webserver serves the default tls vhost, even if the CA requested a > > > specific

Re: [Acme] Removing TLS-SNI-02, plans for continuation of last-call

> In light of these issues and the feasibility of addressing them across the > entire Internet it seems prudent that the ACME specification remove this > challenge type pending the development of a better alternative (TLS-SNI-03?). > I've submitted >

Re: [Acme] Removing TLS-SNI-02, plans for continuation of last-call

> On Jan 12, 2018, at 12:45, Daniel McCarney wrote: > > Hello folks, > > As I'm sure many of you are aware by now, recent developments[0] [1] [2] have > identified real-world server/hosting configurations that violate the > assumptions of TLS-SNI-01 as well as its

Re: [Acme] Removing TLS-SNI-02, plans for continuation of last-call

On Fri, Jan 12, 2018 at 12:45:55PM -0500, Daniel McCarney wrote: > Hello folks, > > As I'm sure many of you are aware by now, recent developments[0] [1] [2] > have identified real-world server/hosting configurations that violate the > assumptions of TLS-SNI-01 as well as its currently specified

Re: [Acme] Fixing the TLS-SNI challenge type

On Thu, Jan 11, 2018 at 04:49:45PM -0800, Roland Bracewell Shoemaker wrote: > This seems like a silver bullet for the problems we’ve been seeing. > Given that blindly responding to an unknown ALPN value would be an > RFC violation this seems safe (although, hey, who knows what servers/ > cloud

Re: [Acme] Specify which JWS serialization is used

Last night, I briefly surveyed the listings of JWT implementations on jwt.io. I could find only a small handful that appeared to support all serializations, and even fewer that appeared to give programmers control over what serialization was produced. Thus, assuming jwt.io is a sufficiently

Re: [Acme] Fixing the TLS-SNI challenge type

On Thu, Jan 11, 2018 at 09:46:28PM -0600, Matthew D. Hardeman wrote: > > In order to actually be an improvement in security, the ALPN needs > to be more than a mere marker of support. > > Consider: The new mechanism is implemented and Let’s Encrypt > deploys. > > Rather than do the work to