Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

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 accurate and comprehensive listing of implementations of all
and/or part of the JOSE specs, the developers of many ACME client and
server implementations may find themselves needing to convert between
serializations before and/or after using JOSE libraries. Such conversion
processes, if needed, should be well-documented somewhere.

I've started on a very rough draft of a possible JWS and JWE serialization
conversion guide at
https://github.com/u2/jwe-jws-serialization-conversion-guide. I made
the conversion guide draft by copying a few items from the ACME GitHub
repository (the Markdown file, the makefile, and the .gitignore), replacing
the text from the Markdown file, and renaming the Markdown file. I designed
the conversion guide draft to be non-ACME specific, so I've tried to
include things like unencoded JWS payloads, JWEs, multiple signatures,
detached payloads, etc. If you have any changes or suggestions, please let
me know.

Logan

On Fri, Jan 5, 2018 at 7:11 PM, Jörn Heissler 
wrote:

> On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote:
> > What do you think of the following:
>
> > Content type application/jose+json: MUST be supported. If used, the JWS
> > will need to be in the Flattened or General serialization. Flattened MUST
> > be supported; General MAY be supported.
>
> > Content type application/jose: MAY be supported. If used, the JWS MUST
> use
> > the Compact serialization. Or should this content type not be allowed?
>
> Agreed. I wouldn't disallow "compact". And it could be clarified:
>
> The server SHOULD use the "Content-Type" HTTP header as an indication
> for the request format.
>
> > JWS Unprotected Header: Not currently used in ACME. Should this be banned
> > in ACME?
>
> I don't see much sense in those. But some client implementations might
> automatically add an unprotected header like e.g. "cty".
> Maybe with a "SHOULD NOT"?
>
> > Multiple signatures: MAY be supported.
>
> > Should messages signed by both MAC keys and private keys be allowed?
>
> This is already forbidden.
>
> > What about Key IDs not issued by the CA?
> > Or are multiple signatures more trouble than they're worth to the point
> of
> > banning them entirely?
> >
> > Multiple signatures on messages that need to be signed by account key: At
> > least one signature MUST be from the account key
> >
> > Multiple signatures on revokeCert: Should this be allowed?
> >
> > Multiple signatures on externalAccountBinding field of newAccount: Should
> > it be possible to bind to multiple pre-existing accounts? Or should this
> > not be allowed?
> >
> > Multiple signatures on newAccount: Not allowed?
> >
> > Multiple signatures on keyChange: Not allowed for outer or inner JWS?
>
> I see no use case. All the authentication is based on accounts and those
> have exactly one keypair. Having multiple signatures would equal using
> multiple accounts at the same time. That makes no sense to me.
> Client libs would probably not generate multiple signatures
> automatically.
> Multiple signatures should be banned in my opinion.
>
> > JWS Unencoded Payload Option (RFC 7797): Not allowed?
>
> Yep, they would make things very complicated.
>
> > Conversion guide between the different JWS serialization formats: Is it
> > completely safe to assume that any and all programmers given the JWS RFC,
> > pre-existing JWS implementations with sufficient documentation, and
> > pre-existing JSON libraries with sufficient documentation could figure
> out
> > how to convert the serialization formats as needed?
>
> Why, yes! Of course every programmer can do that! ;-)
>
> > Or is the conversion
> > guide necessary? If the guide is necessary, then include a reference to a
> > separate new or pre-existing conversion guide. If the guide is necessary,
> > and there is no pre-existing conversion guide, how should the new
> > conversion guide be published? Should the new conversion guide be
> > ACME-specific, or more general (possibly with coverage of JWE as well as
> > JWS features not utilized in ACME)?
>
> It's not necessary, *most* programmers can figure it out. But it would
> doubtlessly be helpful. E.g. I didn't consider the possibility to do
> this conversion in an ACME implementation before/after using a preexisting
> JOSE lib.
> If such a guide were to be published, it should not be ACME-specific.
>
>
> Cheers
> Jörn
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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 providers actually do). Definitely interested in the results of
> the scan. There could still be some argument about ‘misuse’ of the
> SNI extension but unless we have a concrete reason to the host name
> being validated I’m not sure I’m convinced we should.

Note that method 10 definition seems to require the name to be
validated to appear in the certificate. The name appearing in either
the request or response is also required for validation to be
deputizable (and I regard any non-deputizable validation to not be
proper domain validation; both HTTP-01 and DNS-01 are deputizable).


And I guess the reason why there is no blind echoing of ALPN has more
to do with the horrible breakage rates it would cause (due to HTTP/2).

Also, even if one used the name to be validated in the SNI, there is
still a concern that there is some horribly broken hoster, that:

- Allows claiming arbitrary https name, even if there is existing http
  site there (apparently these exist). And,
- Allows claiming arbitrary ALPN values.

Note that there is no requirement to be able to serve different
certificate for given ALPN, because other ALPNs are not checked, so
those might have the spoofed validation certificate.


AFAICT, these are not common. Most provoders that let one claim
arbitrary names (which would make TLS-SNI vulernable) do not let
one claim name in use for http.

And I suppose provoders that let one claim arbitrary ALPN values
without forwarding the entiere connection are extremely rare
(also, any such setup would need off-band signaling for ALPN, e.g.,
via PROXY/HAPROXY protocol).


With "squatting" for SNI, one obtains weaker security bounds, as
this drops the "even if" condition. So any provoder that is
vulernable to TLS-SNI misissuance and lets one claim arbitrary
ALPNs (and then presumably signals those off-band).



-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Daniel McCarney]

>
> 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
https://github.com/ietf-wg-acme/acme/pull/390/commits/3441d4435a6e8454fa68749231d801ec4f894bbc

Thanks Ilari,

- Daniel / cpu

On Fri, Jan 12, 2018 at 1:23 PM, Ilari Liusvaara 
wrote:

> 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 replacement,
> > TLS-SNI-02.
> >
> > 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 https://github.com/ietf-wg-
> acme/acme/pull/390
> > to make this change.
>
> > What are the thoughts of the other WG participants?
>
> 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. I think separating TLS failures and TCP failures is useful for
> debugging.
>
> Example of TLS failure is that somewhat common misconfiguration where
> port 443 is not using TLS: That is _not_ a connection error, the error
> happens inside TLS. Saying it is a connection error is misleading.
>
>
> Other than that, I agree that we can't block on TLS-SNI-03, or
> whatever -> Punt it to future draft (work on which should start soon
> after getting acme-acme through IESG).
>
>
> -Ilari
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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 replacement,
> TLS-SNI-02.
> 
> 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 https://github.com/ietf-wg-acme/acme/pull/390
> to make this change.

> What are the thoughts of the other WG participants?

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. I think separating TLS failures and TCP failures is useful for
debugging.

Example of TLS failure is that somewhat common misconfiguration where
port 443 is not using TLS: That is _not_ a connection error, the error
happens inside TLS. Saying it is a connection error is misleading.


Other than that, I agree that we can't block on TLS-SNI-03, or
whatever -> Punt it to future draft (work on which should start soon
after getting acme-acme through IESG).


-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Salz, Rich]

> 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 
> https://github.com/ietf-wg-acme/acme/pull/390
>  to make this change.

Does anyone on the WG object to doing this?  Please respond by the end of next 
week.  Editors, please hold off on merging the PR until we confirm consensus.



___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Jonathan Rudenberg]

> 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 currently specified replacement, 
> TLS-SNI-02. 
> 
> 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 https://github.com/ietf-wg-acme/acme/pull/390 to make this 
> change.
> 
> It also seems prudent that the working group take its time considering the 
> design and specification of TLS-SNI-03. It will also take time for there to 
> be server and client implementations of a new TLS-SNI-03 specification once 
> ready. 
> 
> With these thoughts in mind I think we should consider TLS-SNI-03 outside the 
> scope of the current draft and proceed with a draft that has only HTTP-01 and 
> DNS-01 challenge types, deferring TLS-SNI-03 for a follow-up document.
> 
> What are the thoughts of the other WG participants?

I support this plan. Given the late stage, I think it makes sense to move the 
new TLS challenge type work to a new document.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Matthew D. Hardeman]

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 non-TLS port 80 customers, with web 
hosting contexts discriminated by HTTP/1.1 Host: header are bound to this IP 
address.

For same said given IP address, one and only one TLS customer is assigned.  
This customer’s web context is bound to that IP address and port 80 for the 
customer’s named Host: values only.  But on the port 443, the IP address is 
bound to this customer in all cases, regardless of TLS SNI value or lack 
thereof, all connections to that IP and host will go to the one TLS customer’s 
web hosting context.

The end result is that https://non-tls-customer.on-same-ip.com will go to the 
TLS website of the one paying TLS customer on that host IP.

(Normally, of course, there would be a name mismatch and the certificate would 
not validate.)  In many of these infrastructures, the site admin of the TLS 
customer would be able to change out that SSL certificate at will.

> On Jan 12, 2018, at 11:39 AM, Ilari Liusvaara  
> wrote:
> 
> 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 vhost via SNI
>>> 
>>> Well, I think both are impiled by default vhost.
>> 
>> The first yes.
>> 
>> But the second I'm not so sure.
>> 
>> AFAIK, with Apache httpd you'll get the tls default vhost just for requests 
>> without SNI.
>> 
>> Of course not everyone is using Apache, but I think it makes it an 
>> additional 
>> condition for the attack to work.
> 
> Actually, reading the detectify post, it seems that at least one hoster
> has the following problem:
> 
> If the legit holder of domain has HTTP but not HTTPS enabled, one can
> take over the HTTPS version, including serving one's own content on it.
> And thanks to HSTS, this can then used to take over the HTTP version
> too.
> 
> 
> -Ilari
> 
> ___
> 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

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

[Daniel McCarney]

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 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 https://github.com/ietf-wg-acme/acme/pull/390
to make this change.

It also seems prudent that the working group take its time considering the
design and specification of TLS-SNI-03. It will also take time for there to
be server and client implementations of a new TLS-SNI-03 specification once
ready.

With these thoughts in mind I think we should consider TLS-SNI-03 outside
the scope of the current draft and proceed with a draft that has only
HTTP-01 and DNS-01 challenge types, deferring TLS-SNI-03 for a follow-up
document.

What are the thoughts of the other WG participants?

- Daniel / @cpu

[0]:
https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996
[1]:
https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
[2]:
https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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 vhost via SNI
> > 
> > Well, I think both are impiled by default vhost.
> 
> The first yes.
> 
> But the second I'm not so sure.
> 
> AFAIK, with Apache httpd you'll get the tls default vhost just for requests 
> without SNI.
> 
> Of course not everyone is using Apache, but I think it makes it an additional 
> condition for the attack to work.

Actually, reading the detectify post, it seems that at least one hoster
has the following problem:

If the legit holder of domain has HTTP but not HTTPS enabled, one can
take over the HTTPS version, including serving one's own content on it.
And thanks to HSTS, this can then used to take over the HTTP version
too.


-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Gerd v. Egidy]

> > 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 yes.

But the second I'm not so sure.

AFAIK, with Apache httpd you'll get the tls default vhost just for requests 
without SNI.

Of course not everyone is using Apache, but I think it makes it an additional 
condition for the attack to work.

> > > (And there are countermeasures that can detect default vhosts).
> > 
> > Could you explain in more detail?
> > 
> > Will they still work in conjunction with TLS and SNI?
> 
> One trick: Use some wild host value, and see that either TLS handshake
> fails with alert 112, or that returned certificate is different.

Did you (or anybody else) see any setup where that check gives the wrong 
results?

Kind regards,

Gerd

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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 certificates.
> 
> 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.
 
> > (And there are countermeasures that can detect default vhosts).
> 
> Could you explain in more detail?
> 
> Will they still work in conjunction with TLS and SNI?

One trick: Use some wild host value, and see that either TLS handshake
fails with alert 112, or that returned certificate is different.


-Ilari 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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:
> > 
> > - 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.
> > 
> > Note that this is strictly stronger condition than the one for TLS-SNI
> > vulernability, which only required capability to upload arbitrary
> > certificates, but not to control default vhost.
> > 
> > (And there are countermeasures that can detect default vhosts).
> 
> This vulnerability would also require that not only a customer can
> upload an arbitrary certificate but that they can cause that hosting
> infrastructure to present said certificate upon matching the SNI
> label being sent in, correct?

My interpretation of the TLS-SNI issues was that it was exactly
that. No default-vhost control needed.

> Generally that would mean that the attacker would have to be the
> party in control of the default vhost correct?

This http validation over https would need default vhost to be in
control of attacker to be vulernable.


The one system I saw that had default vhost for http:// happened
to point it to pretty privileged vhost. It fixed the issue for
http://, but https:// still points to the same vhost. However,
acme-challenge is filtered for both.


Also, regarding testing default vhosts: Some servers respond with
some default certificate if one sends unknown SNI, some just
fail the connection with alert 112.


-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Gerd v. Egidy]

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

> Note that this is strictly stronger condition than the one for TLS-SNI
> vulernability, which only required capability to upload arbitrary
> certificates, but not to control default vhost.

Yes, definitively.
 
> (And there are countermeasures that can detect default vhosts).

Could you explain in more detail?

Will they still work in conjunction with TLS and SNI?

Kind regards,

Gerd

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Matthew D. Hardeman]

> 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 like this:
>> 
>> The client creates a self-signed certificate or uses a certificate signed 
>> by any CA as long as it carries the hostname he wants to challenge within 
>> the subject alternative names (SAN).
>> 
>> The CA does the regular HTTP-01 request. But this request is via HTTPS 
>> and the CA sends the hostname via SNI. The CA does not do any validity or
>> trust checks on the presented certificate except to check the hostname
>> in the subject alternative names for authorization.
>> 
>> I'd call this type of challenge "https-01" to let the client explicitly
>> request this type of challenge in contrast to requesting "http-01" over
>> http.
> 
> 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.
> 
> Note that this is strictly stronger condition than the one for TLS-SNI
> vulernability, which only required capability to upload arbitrary
> certificates, but not to control default vhost.
> 
> (And there are countermeasures that can detect default vhosts).

This vulnerability would also require that not only a customer can upload an 
arbitrary certificate but that they can cause that hosting infrastructure to 
present said certificate upon matching the SNI label being sent in, correct?

Generally that would mean that the attacker would have to be the party in 
control of the default vhost correct?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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 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 running over TLS (like SMTP/TLS).  The TLS-SNI
> mechanisms do facilitate that.  Still, if the risks are otherwise
> acceptable, such a challenge mechanism might be a path of least
> resistance for those impacted by the TLS-SNI-01 deprecation.

I had actually written code (but ripped it out after LE announced
they are dropping support for TLS-SNI) that supported TLS-SNI
challenges at TLS level. This code relied on being able to detect
validation attempts at ClientHello time and then handling those
connections specially.


-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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 any CA as long as it carries the hostname he wants to challenge within 
> the subject alternative names (SAN).
> 
> The CA does the regular HTTP-01 request. But this request is via HTTPS 
> and the CA sends the hostname via SNI. The CA does not do any validity or
> trust checks on the presented certificate except to check the hostname
> in the subject alternative names for authorization.
> 
> I'd call this type of challenge "https-01" to let the client explicitly
> request this type of challenge in contrast to requesting "http-01" over
> http.

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.

Note that this is strictly stronger condition than the one for TLS-SNI
vulernability, which only required capability to upload arbitrary
certificates, but not to control default vhost.

(And there are countermeasures that can detect default vhosts).
 



-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Matthew D. Hardeman]

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. Hardeman  
> wrote:
> 
> 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  
>> 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 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 running over
>>> TLS (like SMTP/TLS).  The TLS-SNI mechanisms do facilitate that.
>> 
>> Really? Isn't TLS-SNI-01/-02 just allowed over TCP port 443?
>> 
>> "This connection MUST be sent to TCP port 443 on the TLS server"
>> 
> 
> ___
> 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

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

[Matthew D. Hardeman]

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  
> 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 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 running over
>> TLS (like SMTP/TLS).  The TLS-SNI mechanisms do facilitate that.
> 
> Really? Isn't TLS-SNI-01/-02 just allowed over TCP port 443?
> 
> "This connection MUST be sent to TCP port 443 on the TLS server"
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Gerd v. Egidy]

> 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 running over
> TLS (like SMTP/TLS).  The TLS-SNI mechanisms do facilitate that.

Really? Isn't TLS-SNI-01/-02 just allowed over TCP port 443?

"This connection MUST be sent to TCP port 443 on the TLS server"

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Daniel McCarney]

+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 latest draft specifies "errors" as a plural array on challenges
> > (vs singular "error" for earlier drafts implemented by Boulder and
> > others). However, the ACME spec now also has subproblems as a way to
> > express plural errors (mainly on new-order and finalize).
> >
> > This means we have two different ways to express multiple errors: One
> > for API requests, and one for validation responses. I propose to
> > simplify the spec by using subproblems consistently in both places:
> > https://github.com/ietf-wg-acme/acme/pull/388
>
> This change makes sense to me.
>
> ___
> 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

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

[Matthew D. Hardeman]

> 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 HTTP-01 does. This may not be important 
> for regular webhosting, but for a scenario where the certificate protects 
> some 
> software running on a host behind a router or firewall only allowing port 443 
> through.
> 
> What do you think?
> 

As I’ve not yet considered the other aspects, I can’t comment as to the 
advisability.

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 running over TLS (like 
SMTP/TLS).  The TLS-SNI mechanisms do facilitate that.  Still, if the risks are 
otherwise acceptable, such a challenge mechanism might be a path of least 
resistance for those impacted by the TLS-SNI-01 deprecation.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Gerd v. Egidy]

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 
webhosters will put a burden on the developers and maintainers of these 
systems because ALPN is relatively new and the deployed software and libraries 
will not make it easy to use it for anything but HTTP/2. The same goes for 
developers of ACME clients.

This may hinder adoption or may lead to incorrect or insecure implementations.
As these insecure implementations have thwarted TLS-SNI-01/02, I think we
should be especially sensitive about risks coming from this side.

So I'd now like to revisit the discussion about using HTTP-01 over HTTPS in 
[3] as alternative to TLS-SNI or as complement to TLS-SNI-ALPN.

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 any CA as long as it carries the hostname he wants to challenge within 
the subject alternative names (SAN).

The CA does the regular HTTP-01 request. But this request is via HTTPS 
and the CA sends the hostname via SNI. The CA does not do any validity or
trust checks on the presented certificate except to check the hostname
in the subject alternative names for authorization.

I'd call this type of challenge "https-01" to let the client explicitly
request this type of challenge in contrast to requesting "http-01" over
http.

Let's consider the shared hosting attack with this method:
1. The domains a.example.com and b.example.com are both hosted on the
   same shared hosting server
2. The shared hosting environment doesn't do any checking of the certificates
   their users install onto the shared webserver
3. While allowing the wrong certificate to be presented for a request, the 
   shared hosting server still checks the HTTP Host-header and responds with 
   data from the document root folder of the correct domain
4. The owner of b.example.com activates a certificate with the SAN 
   a.example.com on the shared hosting server
5. He requests the CA to issue the https-01 challenge request
6. The CA is presented the certificate installed by b, but the document root
   of a.example.com does not contain the correct keyAuthorization, so the 
   challenge fails

The attack on TLS-SNI is possible, because the certificate contains everything 
needed to fulfil the challenge. https-01 has the additional check of the
correct keyAuthorization in /.well-known/acme-challenge/{token}.

Advantages of this method:

- Implementing this scheme should not pose undue difficulties on client
developers.

- This protocol should also be easy to include in running infrastructure 
without disturbing regular requests while executing the challenge. As it sends 
the requested hostname via SNI, it works with shared hosting infrastructure.

- 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 HTTP-01 does. This may not be important 
for regular webhosting, but for a scenario where the certificate protects some 
software running on a host behind a router or firewall only allowing port 443 
through.

What do you think?

Kind regards,

Gerd

PS: Funny thing is, in the course of that previous discussion, Ilari Liusvaara 
already predicted exactly the vulnerability that now has hit TLS-SNI-01/02 
[4].

[1] https://mailarchive.ietf.org/arch/msg/acme/mrKOeRK1K6H_42Hxbt3A1XtLFJM
[2] 
https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188/2
[3] https://mailarchive.ietf.org/arch/msg/acme/mKKWN44SO1yepCffKpiIMb5bqEs
[4] https://mailarchive.ietf.org/arch/msg/acme/mSp709jDGw2bAEUI1Dq8E4iYpmw

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Matthew D. Hardeman]

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:

https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/

In this case, he used AWS CloudFront and Heroku to achieve the issue.

And it pertains to a TLS load balancer being programmatically bound to whatever 
newly unique to the platform name they want.  Just like the threat I had 
mentioned.

Now, imagine if there was a web host configured like AWS CloudFront and/or 
Heroku.  Then imagine that they’re sleazier, less well funded, and looking for 
quick resolution to a new customer complaint…

Customer complaint: My code used to be able to do X,Y,Z and achieve TLS-SNI-01 
validation.  Now, because your TLS balancer doesn’t send this “acme” ALPN 
signal, I can’t anymore.  Fix it!

The cheap quick fix to this — the one that makes the customer’s complaint go 
away while spending the least time and money possible — is to just patch in a 
fake echo of the “acme” ALPN signal.

Note: this is fully resolved if the TLS SNI name in the protocol is changed to 
specify that it must be the actual domain label being validated.  But if you 
don’t require that, you’ll create an opportunity for the web host to most 
expeditiously return to the prior status quo by making a minimal fake “acme” 
ALPN tag.

> On Jan 12, 2018, at 10:04 AM, Matthew D. Hardeman  
> wrote:
> 
> 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 to the 
> validator versus the normal far-end browser or other endpoint is then 
> dependent on the combination of the ALPN marker AND the SNI.
> 
> (i.e. use most recent real certificate/key for connection with real endpoints 
> indicating SNI of the real domain label, but use the validation 
> certificate/key when the real SNI + “acme” ALPN  tag is received.)
> 
> Imagine that the HAProxy you describe is run not by the website 
> administrator, but by the shared hosting provider.  Imagine that their 
> infrastructure was vulnerable to the TLS-SNI-01 and -02 problems because 
> their outside facing HAProxy matched SNI of any number of customer configured 
> unique labels with customer provided certificates…
> 
> If you keep letting that model be manipulated by customers of the hosting 
> provider, and keep the SNI as the .acme.invalid pattern, the path of least 
> resistance to return the web hosts’s prior level of function is simply to 
> create a fake “acme” ALPN signal and proceed with old behavior.  That’s a 
> danger.
> 
> The concerns I raised would more or less be fully resolved by standardizing 
> on having the SNI label be required to be the domain label being validated 
> and then the TLS termination endpoint on the server side has to look to the 
> “acme” ALPN tag to know to switch to presenting the validation 
> challenge-response cerfificate/keypair.
> 
>> On Jan 12, 2018, at 9:29 AM, Patrick Figel  wrote:
>> 
>> 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 XXX.acme.invalid
>>> value was used as a way to allow servers to dynamically serve both
>>> regular and validation traffic. Since we would be using ALPN here we no
>>> longer need a special SNI value in order to differentiate validation
>>> traffic from regular traffic so this token value is no longer needed.
>> 
>> One minor advantage of keeping the current acme.invalid scheme is that
>> it allows people to use SNI-based routing. Web servers like HAProxy
>> allow you to proxy requests (on the TCP layer) based on the SNI value,
>> so you could match "*.acme.invalid" and forward it to a validation
>> server that supports the new challenge and the ALPN ACME protocol, even
>> if the web server itself doesn't. If we use the "real" identifier for
>> SNI, we'd limit that option to web servers that natively support the
>> ALPN value for ACME and can route based on it.
>> 
>> Not sure how common this kind of setup is, if it's just a small subset
>> of HAProxy deployments it'd probably not have much of an impact.
>> 
>> Patrick
>> 
>> [1]:
>> https://www.cloudoptimizedsmb.com/articles/20160409-00/using-haproxy-to-split-letsencrypt-acme-challenges-from-regular-traffic
>> 
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
> 
> 

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

[Matthew D. Hardeman]

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 to the 
validator versus the normal far-end browser or other endpoint is then dependent 
on the combination of the ALPN marker AND the SNI.

(i.e. use most recent real certificate/key for connection with real endpoints 
indicating SNI of the real domain label, but use the validation certificate/key 
when the real SNI + “acme” ALPN  tag is received.)

Imagine that the HAProxy you describe is run not by the website administrator, 
but by the shared hosting provider.  Imagine that their infrastructure was 
vulnerable to the TLS-SNI-01 and -02 problems because their outside facing 
HAProxy matched SNI of any number of customer configured unique labels with 
customer provided certificates…

If you keep letting that model be manipulated by customers of the hosting 
provider, and keep the SNI as the .acme.invalid pattern, the path of least 
resistance to return the web hosts’s prior level of function is simply to 
create a fake “acme” ALPN signal and proceed with old behavior.  That’s a 
danger.

The concerns I raised would more or less be fully resolved by standardizing on 
having the SNI label be required to be the domain label being validated and 
then the TLS termination endpoint on the server side has to look to the “acme” 
ALPN tag to know to switch to presenting the validation challenge-response 
cerfificate/keypair.

> On Jan 12, 2018, at 9:29 AM, Patrick Figel  wrote:
> 
> 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 XXX.acme.invalid
>> value was used as a way to allow servers to dynamically serve both
>> regular and validation traffic. Since we would be using ALPN here we no
>> longer need a special SNI value in order to differentiate validation
>> traffic from regular traffic so this token value is no longer needed.
> 
> One minor advantage of keeping the current acme.invalid scheme is that
> it allows people to use SNI-based routing. Web servers like HAProxy
> allow you to proxy requests (on the TCP layer) based on the SNI value,
> so you could match "*.acme.invalid" and forward it to a validation
> server that supports the new challenge and the ALPN ACME protocol, even
> if the web server itself doesn't. If we use the "real" identifier for
> SNI, we'd limit that option to web servers that natively support the
> ALPN value for ACME and can route based on it.
> 
> Not sure how common this kind of setup is, if it's just a small subset
> of HAProxy deployments it'd probably not have much of an impact.
> 
> Patrick
> 
> [1]:
> https://www.cloudoptimizedsmb.com/articles/20160409-00/using-haproxy-to-split-letsencrypt-acme-challenges-from-regular-traffic
> 
> ___
> 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

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

[Patrick Figel]

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 XXX.acme.invalid
> value was used as a way to allow servers to dynamically serve both
> regular and validation traffic. Since we would be using ALPN here we no
> longer need a special SNI value in order to differentiate validation
> traffic from regular traffic so this token value is no longer needed.

One minor advantage of keeping the current acme.invalid scheme is that
it allows people to use SNI-based routing. Web servers like HAProxy
allow you to proxy requests (on the TCP layer) based on the SNI value,
so you could match "*.acme.invalid" and forward it to a validation
server that supports the new challenge and the ALPN ACME protocol, even
if the web server itself doesn't. If we use the "real" identifier for
SNI, we'd limit that option to web servers that natively support the
ALPN value for ACME and can route based on it.

Not sure how common this kind of setup is, if it's just a small subset
of HAProxy deployments it'd probably not have much of an impact.

Patrick

[1]:
https://www.cloudoptimizedsmb.com/articles/20160409-00/using-haproxy-to-split-letsencrypt-acme-challenges-from-regular-traffic

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Jonathan Rudenberg]

> 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 more 
> than a mere marker of support.

I don’t believe this is true. I’ve already established that there are no common 
TLS servers that blindly repeat back ALPN protocols, and this is expected 
because RFC 7301 does not allow it: 
https://tools.ietf.org/html/rfc7301#section-3.2

> Consider:  The new mechanism is implemented and Let’s Encrypt deploys.
> 
> Customer’s of not-secure-shared-webhost-A complain that they can’t get 
> validations via this easy mechanism.  (The complaint would actually likely 
> originate internally by their own development staff.)
> 
> Rather than do the work to ALSO fix the insecure aspects of the 
> infrastructure, they’ll hastily patch in the “acme" name.

This would be a vulnerability in the hosting provider, not in ACME or any ACME 
CA, in the same way that we wouldn’t blame the CA if a DNS provider allowed 
anyone to write _acme-challenge TXT records.

The reason why TLS-SNI-01/02 are in the process of being removed is a bit 
different, the widespread vulnerability in the shared hosting providers existed 
_before_ ACME, and so it makes sense to work around it to avoid unnecessarily 
putting users at risk. This is not the case for the proposed new method.

> To add security, perhaps the SNI that is sent should be the actual domain 
> label that is being validated, along with the “acme” ALPN name.

This is where we are headed, I’ll be posting a new TLS-ALPN proposal today 
based on the feedback from Roland.

> At this point, an actual ALPN extension should negotiate the authentication, 
> with the server having the opportunity to bind the proper target name to a 
> desired authentication and then if and only if the server has available the 
> account key credentials of the requestor, would it be able to answer with a 
> proper authentication.

It’s important that the account key is not required to be online for 
authorization, as it allows separation of privilege, the account key can be 
kept safely away from publicly exposed frontend servers. A random token is 
sufficient, I’m not aware of any reason why requiring the account key to be 
online would improve security.

Jonathan
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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 ALSO fix the insecure aspects of the
> infrastructure, they’ll hastily patch in the “acme" name.
> 
> To add security, perhaps the SNI that is sent should be the actual
> domain label that is being validated, along with the “acme” ALPN
> name.  At this point, an actual ALPN extension should negotiate the
> authentication, with the server having the opportunity to bind the
> proper target name to a desired authentication and then if and
> only if the server has available the account key credentials of the
> requestor, would it be able to answer with a proper authentication.
> 
> Just adding a marker with the hammer being that just doing this
> without implementing the promises that are supposed to be implied
> on pain of violating an RFC is…  Likely to get laughed at in a
> derisive way by the very web hosts whose behavior now has you
> contemplating improvements to the protocol.
> 
> There’s no fast way out of this mess.

The mechanism is presumably bound by "method 10" from current CABForum
BRs.

The language in the BRs is (paraphrased):

'A random value in a certificate on the name being validated'.


So the certificate must contain both the name being validated and the
random value.

That certificate may be either X.509 certificate (which are apparently
a bit nontrivial to generate, I personally don't think it is that bad)
or some other format of certificate.


However, if one is to keep with cryptographically kosher practices,
there are the following constraints:

- The account key can not sign X.509 certificate, or any other
  certificate with format not based on JWS.
- The account key can not directly sign TLS key exchange. 

Also, another certificate format would require a new TLS certificate
format. Codepoint assignment needs an RFC, but in practice, those
would likely be annoying to implement.

Then there are the following implementation constraints:

- The key used to sign the TLS key exchange must appear the
  certificate.


-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme