Http challange on port 25?

DNS entries can be CNAMEd to any other zone.
[including sub zones of the same domain]
Like:
_acme-challenge.example.com CNAME deligated-sub-zone.for-acme-only.example.com

Given that API control keys can be restricted to a specific sub zone (or zones).
That would allow me to sleep at night :zzz:
If not, then I don't think a web server is a very good place to keep the keys to the entire DNS zone.

The remote controls the robot!

4 Likes

In many situations, the DNS API keys also control domain transfer and registration - which is why they are very very dangerous and acme-dns is almost always preferable.

Wishlist: I think it would be useful to propose a general "privileged port" ACME challenge that could only be run by Root/Administrator, and would either run on a dedicated port or be configured to run on anything under 1024 (assuming windows respects those assignments as well).

A use-case would be allowing for certificates used by the service running on Port 80/443 (or Port 25) to be renewed without the involvement or coordination of that service. The client could just bind to the port on demand (i.e. like the standalone Certbot plugin) and handle the entire certificate procurement process without requiring any configuration or downtime of that main web service. The main service could then receive a graceful shutdown signal to reload the certificates on success.

I deploy this pattern a lot by leveraging (i) global proxypass of acme-challenges to a higher port, and (ii) running certbot on a higher port with the standalone plugin. Getting the first part done takes some testing and coordination, this would eliminate that. This would create the same effect as using the acme-dns challenge - completely isolate the verification system from the service that utilizes certificates - but allows that to be done within a single application/process and a simplified pattern.

Building ACME verification into existing web/dns/etc services is great - but I think we'd experience a lot more overall utility from developing a secure dedicated ACME service/port.

4 Likes

I think that in practice this kind of system might as well just use port 53 (DNS), and there are clients like agnos which can fulfill DNS challenges. It's basically "standalone" mode just for DNS instead, just CNAME the _acme-challenge name to the same system you're getting a certificate for, and the client takes care of everything.

4 Likes

There are often situations where there exists a local DNS server (e.g. LAN addresses, local cache, etc) so that port is not available for an ACME client. My goal is to enable ACME challenges on a configurable privileged port.

4 Likes

One could also choose a port not already "claimed" as "the ACME validation port" and add that port to the BR as a valid one.

4 Likes

why I proposed http-25 challenge was it already allowed on BR so LE can do that which BR change.

if we are considering authorized port change, how about port 115(which was mistakeing simple ftp for ssh sftp), which was authorized port in BR until 1.5.1(SEP 2017)? (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.0.pdf)

4 Likes

Just to be clear, I am suggesting two things:

  1. Create an ACME service that would run on a (relatively) unused trusted port by default. There are still some {insert service/port here} servers out there, but there are a large number of ports that have not been allocated or "well known" to be used by existing systems or protocols. This does have some limitations as non-unixlike systems may be able to bind to those ports. See: List of TCP and UDP port numbers - Wikipedia Note: it is common to host a SMTP relay server on port 25 and use that for sending mail instead of piping STDOUT to a "sendmail" binary.

  2. Allow that challenge to be invoked on alternate ports. This could be a subset of well-known/reserved ports.

I am onboard with the idea of the existing HTTP challenge being usable on a mix of trusted ports: 20 (ftp), 23 (telnet), 25 (smtp), 80 (http) seem like a good group to start with, as there is a good chance someone can take at least one of those ports offline to handle certificate procurement. Ideally that range could be expanded to run on some of the more esoteric/unused ports in the reserved range. i.e. An RFC for "HTTP-02" might define it as the same as HTTP-01, except the challenge trigger URL allows a specified port to be submitted in the POST.

Perhaps the DNS record could be augmented with a CAA or TXT record that specifies which of the compatible ports are allowable for "HTTP-02" challenges on that domain. Unlike the DNS-01 challenge, the records would only need to be set up once and there would not be a need to set up complex zones to support delegation.

Building challenges into existing protocols is great, but that approach raises the possibilities of downtime or introducing configuration errors that are not caught. Being able to procure a Certificate via a (i) single service that is (ii) isolated from running services and (iii) relatively easy to configure would eliminate many issues.

4 Likes

As an aside, this is how windows based ACME clients generally do port 80 http-01 challenges because windows supports http pipeline sharing via http.sys - you can just add a listener for http:///acme-challenge/ that your acme service takes care of, so that request never reaches the web server service. The only time that doesn't work if you have a non-windows native service bound to port 80 (like Apache or nginx, or certbot standalone) because they want exclusive port 80 for their own http handler.

To get similar results on linux etc you could run an ACME aware proxy on port 80 back to your actual web server of choice, it does add a hop in your http requests to some extent though.

6 Likes

I should add regarding DNS credentials, of course if you are using DNS validation there is no need to perform your certificate renewals on your webserver, instead you can do it on an internal server dedicated to the job.

You can then either deploy from there or store certs in a secrets store and have your web servers (which nowadays are probably fairly transient container instances pointing to storage for the real content and config) pull only the certs they are entitled to by their respective credentials.

4 Likes

I would also endorse this idea. But I'm afraid that many people would try to use it in environments where port 25 is blocked (and they don't even realize it, since they've potentially never tried to use port 25 for anything before).

If this is ever deployed, I would favor have a special error message that mentions (or links to a page mentioning) the idea that your ISP may not allow connections on port 25, even by default in a data center with a VPS or colocated server, and that there's no way to work around this with that challenge method, without getting the ISP to change its policy or add a special case rule for a specific account or server.

I don't really have actual data about this, but I'm guessing inbound port 25 is about 10× more likely to be blocked on a residential account than port 80, and might also be blocked in default firewall policies of the majority of VPS services.

5 Likes

I suspect you're actually far underestimating it, at least for people likely to run ACME clients: Blocking port 25 is very common (especially outgoing, but blanket 25 bans are pretty common), but blocking 80 inbound is relatively uncommon.

But if you're running a mail server and want to accept mail on 25, you're going to have to deal with that anyways, which is why I think an ACME-SMTP on 25 might make sense, but that reusing 25 for other things (like an alternate HTTP challenge port) would not.

6 Likes

Yes. As a default, I implement that in nginx with a config macro included in all location blocks; it just proxies /.well-known/acme-challenge onto a higher port. Nginx is rather compatible with this design, because I can just alter the include port in one file and do a graceful reload. This is my hot-fix backup plan for situations where DNS-01 via our acme-dns instance isn't a timely option. The big draw for me on DNS-01 is that it is decoupled from active services and we can host a dedicated acme-dns instance.

While most of the people in this thread personally don't encounter issues stemming from this because of expertise in these configurations, most end-users are relatively inexperienced and encounter variations of this pattern that result in one or all websites going offline. DNS-01 is rather advanced as it requires a secondary system, most vendors do not offer granular permissions making it a security risk, and the current best-practice setups require a dedicated authorization namespace and a delegation system. There is simply a strong need in the ecosystem for an ACME challenge that is decoupled from Port 80 and other active services, can run via Certbot standalone, and requires a minimum setup/configuration.

5 Likes

I can see that, if we could opt to run http challenges on any low port it would certainly be beneficial. So how do we get the ball rolling for a new challenge type (http-02)?

I imagine the challenge submission part would require an updated payload to specify your port of choice (earlier parts of the acme workflow don't really present an opportunity to specify your port preference). Are there any specific reasons why low ports have previously been dismissed for use with http challenges?

5 Likes

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.