Turning off old/insecure challenge types

[Josh Aas]

Let's Encrypt will no longer be offering the "simpleHttp" and "dvsni"
challenges as of Thursday, November 18. If your client depends on
these challenges, you will need to update to the "http-01" or
"tls-sni-01" challenges by that date, or your client will no longer
work. The current version of the official Let's Encrypt client
supports the new challenges.

This change is required because these older challenges have a
signature reuse vulnerability, reported on the IETF ACME list by
Andrew Ayer several weeks ago.

Also, please note: The "tls-sni-01" challenge currently offered by
Let's Encrypt is currently not compatible with the "tls-sni-01"
challenge defined in draft-ietf-acme-acme-01. It lacks the "n"
parameter. This is a known issue, and will be resolved once the IETF
ACME working group decides whether to keep the "n" parameter.

--
Josh Aas
Executive Director
Internet Security Research Group

[Kaiduan Xie]

Josh,

Where can I find the detailed description of http-01? Is it defined in
a new draft?

Thanks,

/Kaiduan

> --
> You received this message because you are subscribed to the Google Groups "Let's Encrypt CA Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ca-dev+un...@letsencrypt.org.
>

[Richard Barnes]

On Sat, Nov 14, 2015 at 2:48 PM, Kaiduan Xie <kaid...@gmail.com> wrote:
> Josh,
>
> Where can I find the detailed description of http-01? Is it defined in
> a new draft?

https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7.2

[Kaiduan Xie]

Can anyone explain the following?

"Because many webservers allocate a
default HTTPS virtual host to a particular low-privilege tenant user
in a subtle and non-intuitive manner, the challenge must be completed
over HTTP, not HTTPS."

The reason to drop HTTPS support is not clear for me.

Thanks,

/Kaiduan

[Chris Drake]

Hi Kaiduan,

I agree - this makes no sense.  HTTPS has extensions for identifying the virtual host now - there's no reason to downgrade to HTTP anymore.

Kind Regards,
Chris Drake


Sunday, November 15, 2015, 10:17:59 AM, you wrote:

KX> Can anyone explain the following?

KX> "Because many webservers allocate a
KX>  default HTTPS virtual host to a particular low-privilege tenant user
KX>  in a subtle and non-intuitive manner, the challenge must be completed
KX>  over HTTP, not HTTPS."

KX> The reason to drop HTTPS support is not clear for me.

KX> Thanks,

KX> /Kaiduan

[Richard Barnes]

What that text means is that if your hosting provider hasn't
configured HTTPS properly, then whichever host got assigned to be a
default virtual host could get certificates for any other website
hosted on that server that doesn't already have HTTPS running. I hope
you'll agree that that would be a bad thing :)

In any case, if you would like to propose a change here, this is not
the right mailing list for it; use ac...@ietf.org instead.

[Anders Henke]

The description pretty much matches Apache httpd's implicit configuration of a "default" host.

https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI gives a nicer summary than the original documentation:

---cut
Changes in configuration to use SNI

There is one new directive related to using SNI with name-based virtual hosts, SSLStrictSNIVHostCheck, which controls whether to allow non SNI clients to access a name-based virtual host.

The first (default) vhost for SSL name-based virtual hosts must include TLSv1 as a permitted protocol, otherwise Apache will not accept the SNI information from the client and it will be as if the client did not support SNI at all.

Since the first (default) vhost will be used for any request where the provided server name doesn't match another vhost, it is important that the first vhost have the most restrictive access control, otherwise clients can access restricted resources by sending a request for any unknown hostname. (This isn't actually any different from using virtual hosts without SSL.)
---cut

Read:
- Apache httpd uses the first virtualhost to configure some protocol-level options. If the first virtualhost doesn't permit TLSv1, no other virtualhost can implement SNI.
- If SSLStrictSNIVHostCheck does permit connections from clients without SNI, those connections will be handled by the first TLS-configured virtualhost. The connection will use the certificate configured for the first virtualhost (which may raise a warning within the user's browser) and deliver any website content configured within this virtualhost.
In order not to bypass any other restrictions configured for other virtualhosts, the content served from this virtualhost should be restricted (e.g. rather a simple error page "your browser doesn't do SNI" than a browsable directory tree with any other document roots). This behaviour is the same for namebased HTTP.

The reasoning to drop HTTPS support isn't clear for me as well: as the last quoted wiki-sentence in brackets stated, Apache httpd does behave the same way for namebased HTTP hosting. The only difference: namebased HTTP hosting has been actively used for about 16 years now, while most TLS/SSL-hosting has been done on "dedicated" IPs and SNI just started spreading within the very last years.

Best,
Anders

[Kaiduan Xie]

Subscribing to acme mail list
(https://www.ietf.org/mailman/listinfo/acme) took too long, so I post
the comment about the
https://www.ietf.org/id/draft-ietf-acme-acme-01.txt here,

7.2. HTTP

keyAuthorization (required, string): The key authorization for this
challenge. This value MUST match the token from the challenge and
the client's account key.

{
"keyAuthorization": "evaGxfADs...62jcerQ"
}
/* Signed as JWS */

!xkd! I do not think the keyAuthorization value returned by ACME
client over HTTP needs to be signed as JWS, it should be the plain
text value of calculated keyAuthorization, right?

3. Dereference the URI using an HTTP or HTTPS GET request. If using
HTTPS, the ACME server MUST ignore the certificate provided by
the HTTPS server.

Because many webservers allocate a
default HTTPS virtual host to a particular low-privilege tenant user
in a subtle and non-intuitive manner, the challenge must be completed
over HTTP, not HTTPS.

!xkd! Why HTTPS is mentioned in 3.? Can we make it clear that HTTPS is
only used when ACME client redirects HTTP to HTTPS? I assume
letsencrypt.org ACME server will follow the HTTP redirect to use
HTTPS.

!xkd! Although I still do not like the idea to use HTTP.

!xkd! Again, the above sentence "... in a subtle and non-intuitive
manner" should be re-phrased, the explanation from Richard in this
email thread is clearer. Also can we cite the reference of "many
webservers allocate a default HTTPS ...."?

6. Verify that key authorization provided by the server matches the

^^^^^
token for this challenge and the client's account key.

!xkd! This should be client, right?

Thanks,

/Kaiduan

> You received this message because you are subscribed to the Google Groups "Let's Encrypt Client Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to client-dev+...@letsencrypt.org.
> To post to this group, send email to clien...@letsencrypt.org.
> To view this discussion on the web visit https://groups.google.com/a/letsencrypt.org/d/msgid/client-dev/8ff5bec6-f697-4209-a32f-94d699d697b8%40letsencrypt.org.