Turning off old/insecure challenge types


#1

Let’s Encrypt will no longer be offering the “simpleHttp” and “dvsni” challenges as of Thursday, November 19. 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.


#2

#3

@josh i think ti would be an good idea to update the “official” spec under https://letsencrypt.github.io/acme-spec/ .
Because i think that if you link an spec for the protocol it should contain an description of these two methods if
they are in the 3 days the only available ones. Only to say this is the difference to another spec i think is not optimal.
If an developer try to build an client based on the spec he should expect that it is correct and complete.


#4

Nope, we should just delete all spec contents in acme-spec and just close all open issues once resolved and move everything else to the official spec.


#5

OK but as long as this move is not done there should be an place in the spec that mention for example the “n” Parameter difference. And not only in this community board.


#6

I think this goes back to “http://www.ietf.org/mail-archive/web/acme/current/msg00524.html

  1. The problem did not have anything todo with simpleHTTP only with TLS=true and defect tomcat config.
  2. The same description i think could be true for http if the site only support for one tenant https
    then the server will fall back to another default domain.
  3. simpleHTTP require serverSide acces to the challenge or the privateKey+token the http-01 challenge only
    require access to the token+publicKey this is in my eyes also an disadvantage.

#7

sorry to spoil the fun but according to my calendar nov18 is wednesday.

so what do we take? the thursday or nov18?


#8

Ugh, good catch. Assume it is the later of the two, Thursday the 19th.


#10

FYI, we just disabled these challenges in staging and will be disabling them in production tomorrow.


#11

Wow time flies it’s already Nov 19th !

thanks for heads up :+1:


#12

As far as I can tell, the previous default was for letsencrypt-auto to copy the challenge to the web root. Is this now disabled? Letsencrypt-auto is unlikely to be able to automatically change DNS so this makes a significant barrier to entry?


#13

no, no, there are different types of challenges that are essentially webroot, especially simpleHTTP and HTTP-01 are similar in some way but are different on the technical side (and the newer ones are more secure) so copy pasting into the webroot still works, and unless you use a rather old LE client it should already be copypasting over HTTP-01


#14

This change is now in production. New authorizations will not have simpleHTTP and DVSNI as challenge options. Their replacements, http-01 and tls-sni-01, have been in production for a while.

Thanks for paying attention, y’all.