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

[Jonathan Rudenberg]

> On Jan 11, 2018, at 22:26, Martin Thomson  wrote:
> 
> If you are using a new protocol, all of the concerns Peter have come
> into play.  If you are there, why wouldn't you do the challenge
> validation within the new protocol rather than using the certificate
> (which is sent in the clear in current TLS versions).  That might be
> easier to implement than generating the self-signed certificate…

I don’t think an entirely new protocol makes sense. In order to do the 
TLS/SNI/ALPN handshake a certificate is already sent in the ServerHello, so 
there’s no reason not to use it to transport the authorization token. 
Generating a self-signed certificate is trivial, and I’m not aware of any 
relevant security concerns around fetching the authorization in the clear (the 
dns-01 and http-01 challenge types are plaintext as well).
___
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 19:49, 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.

I’ve completed[0] a scan of the Alexa Top 1M list, and no servers repeated back 
the unknown ALPN protocol of “acme” that I used[1].

I also opened a PR that adds this change to the spec: 
https://github.com/ietf-wg-acme/acme/pull/389

Jonathan

[0] https://storage.googleapis.com/titanous-acme/alpn_scan.csv.gz
[1] https://gist.github.com/titanous/8daa24ed3375f3c690950e8a97c7527d
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Jonathan Rudenberg]

> 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] Fixing the TLS-SNI challenge type

[Jonathan Rudenberg]

As many of you are probably aware, Frans Rosén of Detectify discovered a method 
of exploiting many shared hosting providers to obtain unauthorized certificates 
using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt is in the 
process of removing support for these challenge types[1].

Obviously this is not ideal, as the TLS-SNI challenge is useful in a variety of 
use cases. The good news is that TLS-SNI-02 appears to be fixable.

In order to get the ball rolling on a fixed version (aka TLS-SNI-03), here’s a 
straw proposal, based on something originally publicly suggested by Ryan 
Sleevi[2]:

Start with the TLS-SNI-02 challenge specification, and add the requirement that 
the ACME server MUST send an ALPN extension in the ClientHello with a single 
“acme” protocol name, and the ACME server MUST confirm that the ServerHello 
also includes an ALPN extension with a single “acme” protocol name.

The only concern I’ve seen about this is the theoretical possibility that 
servers might just repeat back the ALPN extension with the same protocol name, 
which I believe we can remedy by doing a scan of the Alexa Top 1M (or similar) 
to see if this behavior exists in the wild.

Jonathan

[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://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Order states after finalize

[Jonathan Rudenberg]

Section 7.4. (Applying for Certificate Issuance) says:

> A valid request to finalize an order will return the order to be
> finalized.  The client should begin polling the order by sending a
> GET request to the order resource to obtain its current state.  The
> status of the order will indicate what action the client should take:
>
...
>
> o  "pending": The server does not believe that the client has
>fulfilled the requirements.  Check the "authorizations" array for
>entries that are still pending.

This raises a couple questions:

1) Is it valid for an ACME server to respond to a finalization request with an 
order status of pending if the requirements have been fulfilled?
2) Is it valid for for an ACME server to respond to a “GET order” request with 
a status of pending after finalization if the requirements have been fulfilled?

Pebble currently does both, as it transitions to the processing status 
asynchronously. My understanding is that Boulder transitions to valid 
synchronously, without any intermediate statuses being visible to the client.

My initial understanding is that the answer to first question is yes given the 
explicit suggestion that the client needs to request the order again to get the 
current state, and the answer to the second is no, subsequent requests should 
never return a pending state if the requirements are valid because there is no 
way to distinguish indefinitely pending from pending soon-to-be processing if 
the answer is yes.

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

[Acme] nit: order authorizations array mutability

[Jonathan Rudenberg]

I just came across what appears to be a minor inconsistency around the 
mutability of the order object’s authorizations array.

Section 7.1.3 (Order Objects), says:

> The elements of the "authorizations" and "identifiers" array are
> immutable once set.  The server MUST NOT change the contents either
> array after they are created.  If a client observes a change in the
> contents of either array, then it SHOULD consider the order invalid.

However, the authorizations array appears to be documented as changing between 
the pending and final states, which would make it mutable.

> authorizations (required, array of string):  For pending orders, the
>authorizations that the client needs to complete before the
>requested certificate can be issued (see Section 7.5).  For final
>orders (in the "valid" or "invalid" state), the authorizations
>that were completed.  Each entry is a URL from which an
>authorization can be fetched with a GET request.

Jonathan



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

Re: [Acme] Preconditions

[Jonathan Rudenberg]

It seems that there are potentially multiple valid sets of authorizations that 
are mutually exclusive.

Consider a request for a certificate that has three SANs: a.example.com, 
b.example.com, c.example.com

There are two valid paths to issuance: validate example.com, or validate the 
three SANs as specified in the CSR.

Under the precondition system, with ACME server/client implementations that 
were aware of this shortcut, the client could present a CSR that included 
example.com as one of the SANs, the server would return a single authorization 
request for example.com, and then after fulfilling that request, a subsequent 
request could be made with a CSR that did not contain the example.com SAN, only 
the subdomains, which would lead to immediate issuance without further 
authorization.

Does it make sense for the server to be allowed to return multiple exclusive 
sets of authorizations that could lead to issuance, in order to avoid knowledge 
of the issuance rules in the client?

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