Http challange on port 25?

I think the big reason is there wasn't yet a need for it, and a lesser reason is the security aspect.

It is my understanding that Port 80 works for the CA/B forum, because it proves both (i) the domain owner wants 80/443 traffic routed to the server(s), and (ii) the domain owner is responding to port 80/443 as those ports require Admin/Root privileges on the major computing systems or have general protections already in place that are inherent to shared hosting situations.

This is what I am unsure of: Although all ports under 1024 are considered "well known" or "privileged", I have read that Windows does not (or did not at some point in the past) require admin privileges to bind to all those ports, and only a subset of well-known ports require admin privileges on both unixlike and windows systems.

If that is the case, my suggestion to use DNS records (CAA, TXT) to indicate allowed ports for ACME challenges would fully address those concerns.

I'm willing to collaborate on a draft spec and proof-of-concept. The question is if we can convince ISRG or another CA to back it and present to the CA/B forum.

Anyways, my general idea is:

  • define a DNS record to list allowable ports. e.g.:
    • TXT: _acme-service-http02-ports=25 80 115
    • CAA: example.com. CAA 0 http02-ports "80 25 115"
  • define a payload for the new challenge trigger that identifies a specific port to query. for example:
      "protected": ...
      "payload": base64url({
        "port": [
          "25
      }),
      "signature": ...
    }
    
    

The combination of those two would allow for a domain owner to use authoritive DNS records to enable the challenge on an alternate port (only needed on initial setup), and then identify the port on demand.

I still like the idea of a dedicated ACME service port, but I think this framework would handle all the use cases that @orangepizza and I are concerned with.

4 Likes

Yes currently you need to be administrator to bind to those ports (or admin can allow specific users account to bind to those ports) but I'm fuzzy on the specifics and versions as well. I'll see if I can find a definitive article somewhere.

3 Likes

Correct Windows has not always considered privileged ports <1024 "well known" or "privileged"

https://answers.microsoft.com/en-us/windows/forum/all/windows-and-privileged-ports-1024/c0cc4cf4-e073-4bfd-9e56-4a52939d2f5d

2 Likes

but how long has it been? that page sounds like before y2k, and if you run NT4.0 on internet you'd have bigger problem than certificates.

3 Likes

Yes; very True.

2 Likes

I didn't find a better article regarding windows ports <1024 - I'd guess Server 2008 upwards is safe enough in this regard (possibly even 2003 onwards) but I haven't tested it and I think the specifics of that are a distraction to some extent anyway.

I'd imagine a spec would be OS agnostic and could if required just include a phrase like:

The environment used to host this challenge type MUST protect low ports from binding by non-privileged users/processed to ensure only authorized users accounts can create an appropriate challenge listener process.

For comparison the current ACME v2 spec says

Because many web servers 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.

It doesn't really tackle specifics around environments that could allow port tcp 80 listeners for no-privileged users, it's assumed. e.g. it doesn't call out old versions of OSes which could host tcp port 80 without requiring admin.

Perhaps that can also be assumed for any low port (as all low ports, including port 80 are otherwise practically the same until a service consumes them as far as I know, they vary only on the conventional service expected per port and the likelihood of the firewall being open).

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.