Define a new challenge type that runs on a dedicated port

[coolaj86]

See letsencrypt/acme-spec#33.

Webservers are already running on 443.

If the validation also requires using 443 that means that the admin has to take down their webserver to make port 443 available for the validation and then has to put their webserver back up.

Alternatively they could use something like HAProxy, but this puts more administrative burden on the user. (I consider myself a fairly knowledgable guy and it took me a few hours of experimentation to arrive at a working solution)

Also note that there are a number of ports available for IANA registration:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

It looks like port 4 is ripe for an RFC. And 6,8,10,12,14,16,26,28,30,32,34,36,40,60.

One of the available ports could be used in place of 443 for validation.

Or, to make it super simple, the client could request any port below 1024 (or even above it!) to be used for validation / registration.

[pde]

ACME should certainly support this. For DVSNI the server should declare a list of ports that it allows, and the client can pick one of those; I proposed spec language here though it seems Richard removed it while merging the other aspects of that change.

And @coolaj86 if you want to make the case that in the medium term Let's Encrypt or some other CA should actually allow this type of validation, it could be helpful if were to run scans on some candidate privileged ports and report back what you can learn about the existing populations of servers that use them.

[hlandau]

It seems like there is a clear roadmap for doing this securely:

• Register a new port <1024 with IANA, exclusively for the purposes of ACME challenge. The semantics of this port is that control of it is deemed to constitute control of the system.
• Might want to require that TLS be used on this port; otherwise you have the possibility that either HTTP or TLS (either for HTTP or DVSNI) is running on the port. These sorts of ambiguities should be avoided. It also allows this "hostmaster" port to be extended for other purposes at a later time via ALPN.
• Allow either port 443 or that port to be used.
• Arguably, one should not even allow the use of port 443 if this port is open. Note that use of 443 has already proven a problem once with the vulnerabilities in the dvsni challenge mechanism w.r.t. common hosting configurations.

[richsalz]

Please discuss this on the mailing list, acme@ietf.org.

[rdebath]

What's to discuss ?
Authentication machine opens plain TCP connection to special port on client machine.
Client machine sends token.
Client machine closes connection.
Authentication machine closes connection.
DONE.

HTTP and especially SSL validation are workarounds for the port already being occupied by a web server, for a dedicated service they would be serious overkill!!

(If sanity has prevailed you should close this issue)

[Gunni]

+1

Using a port already used by most users of this service is really dumb, especially considering that certificates can then be used for a lot of other things than https (example: mumble, or anything that uses x509 certs).

If i am validating example.com, and it has an A or cname record that points there, then the port should not really matter.... right? I am proving that i control the content of example.com... right?

[rdebath]

I later found (ie: actually decided to look for it) the mailing list archive at https://mailarchive.ietf.org/arch/search/?email_list=acme

The problem seems to be that they (a vocal portion) are seeing themselves trying to validate some sort of "legal authority" to issue the certificate rather than a simple technical access to the server. The (IMO) strawman for this problem is that there are shared hosts out there that allow access to shared ports and services by any of the legal entities that host web servers on that machine. This is taken to mean that only the web server port (80) can actually be assumed to represent the legal entity because it is the only one that is guaranteed to be already occupied (usually).

The fact that for a reasonably managed shared webhost every tcp port that doesn't provide a declared service (eg <1024/<>21/<>20 <>80 <>22, for ftp, www and sftp/ssh respectively) will be firewalled is ignored by this argument as are several others. One other fact that is ignored is that port 443 is also not guaranteed to be occupied but it must be supported for secure updates.

Unfortunately, this is a classic "bootstrap" problem which cannot be solved by them, it's a policy decision by "lets encrypt" and other CAs.

[hardie]

Proposed at IETF 95 to defer this into an extension specification.

[jsha]

This isn't possible to do under the current BRs, unfortunately.

[drzraf]

What? Could please explain where the upstream (ietf?) issue about spec' has been discussed and supposedly closed? Since this a is such an important (and long-awaited) change it's probably worth a more elaborate explanation.

[jsha]

The CA/Browser Forum's Baseline Requirements, ballot 169.

[richsalz]

I think it is good to know that a private, closed, group has a particular set of requirements but that shouldn’t really define IETF requirements.

In this case, however, I think the WG decided to stick with the assigned ports for security reasons.

[drzraf]

https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/

Authorized Port: One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

Shouldn't the feature-request about later three be opened here?

[richsalz]

As WG co-chair: What CabForum does is their own business. It is not our business unless the WG decides to have other ports. So far, consensus has been against doing this. If you, or anyone else, want this, please bring the issue up (again) on the WG mailing list, acme@ietf.org.