allow ports other than 443.

[dnozay]

see also issue #19.

practical examples:

• https://proxy.example.com:8080/;

  port 8080 is commonly used but 8080 is not a privileged port.

• running multiple services on the same host

  • https://www.example.com:443/ - already used for regular website
  • https://www.example.com:8080/ - another service (e.g. proxy, jenkins, any app really...)

• SSL endpoint not being apache/nginx but the app

  • uwsgi
  • tomcat / jetty / winstone servlet

[dnozay]

The argument brought forward was need to prove administrative control over a machine.

• if an attacker gains root access, they can listen in to the connection, acquire the certs / keys ...etc.
• there are legitimate use cases for ssl endpoints that do not terminate at apache / nginx / name-your-webserver but at the app level.
• there are legitimate use cases where services are running on the same machine, and sharing certs is a not as secure as having a different cert for each service.
• in the case where the ssl endpoint is apache/nginx, but the traffic is processed by something else (php, wsgi, cgi) down the line, attacker can listen in to unencrypted traffic between user-facing webserver and the layer that actually processes the requests.

[kuba]

Port 8080 is available to any user of the system. Say you give me a shell account on your machine. Would you like me to be able to register certificates for your domains? Definitely not.

ACME protocol is HTTP-server (or app) agnostic, so I don't see any point in discussing uwsgi, Apache etc. here.

Therefore, I believe that this bug report does not bring any value and should be closed as duplicate of #19.

[dnozay]

@kuba, i am not going to give you a shell account nor am I going to disable selinux, nor am I also going to have iptables not running. You are making assumptions about who the set of users of the system can be.

[kuba]

On the other hand, you are making assumptions on what the system has: selinux (non-standard) or iptables (also non-standard, i.e. appropriate firewall rules). Also, mind that there is a lot of software that you run as non-root that might bite you if exploited; you don't have to give me shell access.

Port < 1024 is a fairly good assumption, though not perfect.

[dnozay]

dude, if I can't even make assumptions about my own systems...

[kuba]

The question is how do you communicate to ACME server that it is safe to validate something on non-privileged ports. Not everyone has the same super secure setup as you.

[dnozay]

conversely: you cannot build on the premise that root is using port 443; an attacker could be running an ACME client and already control port 443. Therefore port 443 is irrelevant to the equation.

If a sysadmin wants to use port 443, then it's the sysadmin job to help secure that port. If a sysadmin wants to use port N, then it's the sysadmin job to secure port N.

e.g.

# good luck bob.
sudo sysctl -w net.ipv4.ip_local_port_range="65000 65000"

[ravisorg]

@dnozay You might want to take a moment and meditate on exactly what you're asking here, it's really not a good idea.

[kuba]

@dnozay Okay, while you're meditating, here is a little scenario for you to play with. Imagine you are an ACME server and you get a request to provide a certificate for example.com. What do you do? You can assume that none of the ports is assumed to be controlled by root.

[dnozay]

@dnozay You might want to take a moment and meditate on exactly what you're asking here, it's really not a good idea.

@kuba, @ravisorg, please keep it courteous. If you want to hurt people's feelings by calling them ignorant (my interpretation) on social media, at least back it up with some facts. I'm just trying to help here.

An administrator controls which ports are open for regular users to consume - this includes ephemeral ports / ports in the local port range. As I did show previously you can control that with sysctl. Effectively, root can control all ports if they want to. On your machine the local port range may start at 1024, on my machine it may start at whatever I decide.

Here is something stupid (stupid only because I am ignorant of a good use case for it) that a sysadmin could do:

sudo sysctl -w net.ipv4.ip_local_port_range="1 1024"

With the above regular users can control port 443 without administrative control of the machine.

@dnozay Okay, while you're meditating, here is a little scenario for you to play with. Imagine you are an ACME server and you get a request to provide a certificate for example.com. What do you do? You can assume that none of the ports is assumed to be controlled by root.

Same here, I would assume none of the ports to be controlled by root.

[kuba]

@dnozay Okay, let's assume none of the ports is controlled by root, you are ACME server. How do you validate me?

[dnozay]

@kuba I don't know, I am not writing the specs.

[kuba]

Despite all the madness above, I had an idea and for some time now...

Current ACME protocol does not state that explicitly, but all defined validations require ACME server to perform domain resolution to IP address before connecting to the client. I claim, that implicitly the protocol relies on the security of the DNS system.

On this assumption, without weakening the security, we could extend the current protocol to look up predefined TXT record, say acme.port and use it to contact ACME client instead of the default 443. This would not only allow to use any privileged port < 1024 (#19) but any valid TCP/UDP port number. The latter has a useful property that it would not require clients to run as privileged users, closing possibility of various OS exploits due to the bugs in the client software... Of course, care should be taken and administrator will have to remember to secure the port before setting the record. I feel like requiring low TTL on such record would be beneficial from the security point of view.

TXT acme.port should be optional, and ACME server would fall back to the standard 443. This way we give more flexibility for more tech-savy users, while still maintaining the goal of the protocol, i.e. making it easier to acquire certificates.

Note that another benefit of the TXT acme.port solution is that administrators can run the protocol and create certificates without taking down existing services running on port 443.

What do you think?

CC: @jdkasten

[ravisorg]

@dnozay My apologies, I wasn't meaning to insult you. I was trying to say you might want to step back and view your request more globally, instead of concentrating on your server and your setup. For example, take into account shared servers (like GoDaddy, but also little mom and pop shops that don't have full time sysadmins) where malicious users that have access to the system may be able to do things unexpected.

You comment that your system is secure. It might be. It might not be as secure as you think. But regardless I would suggest that most servers in the wild are not well secured, and by assuming they are (or saying "well, that's root's fault for not securing it then") makes us all less secure by potentially allowing unauthorized people to obtain trusted certificates. Certificates that your browser will now trust, because the verification system was made weaker.

Verification is the weak point in the CA system - it needs to be made as strong as possible, even if it makes your specific case slightly less convenient for you.

Specifically in this case:

• Ports <1024 are by default owned by root. Yes, root could control any port, but by default higher ports are open to anyone (and any software) on the system. Anything other than default will be untrusted, because in the real world very few servers will change those defaults.
• In the same way, port 443 can PROBABLY be trusted because, by default, it is controlled by root. Could a really bad sysadmin reconfigure the server in such a way that allows non root users to listen on 443? Sure. But because of the defaults (and the effort the admin would have to go through to change it accidental) it's probably a much safer bet to assume 443 is root, and >1024 is not root.
• You use an example where sudo can be used to gain access to root owned ports. Well, yes - if you can execute things as root then you can do things that root can do. But if you have sudo root access on a server you basically own it anyway, and probably should be allowed to authenticate. Shared hosts will generally not provide sudo access to untrusted users, and they certainly don't by default.

Let me know if I'm wildly misunderstanding your argument or if I've missed anything. I haven't had any caffeine today and I may be a little off ;)

[jdkasten]

It is difficult to separate out the eventual Let's Encrypt policy from what other CAs might want to do in the future. Mind you that any deviation from the "standards" poses additional risk on the CA system as a whole. The initial challenges were posed to be strictly stronger validations of existing CA practices.

I wrote up a bit of background on current validation methods and some CA background in an earlier question if you are interested. validation methods

In regards to @kuba, It seems reasonable, but I would have a few concerns.

It seems a bit heavy to me. Since there is already an existing DNS challenge, the only time someone would use it is if they were preparing to get a certificate sometime in the future and wanted to setup the initial phase now. The process requires two steps whereas if you already have ready access to DNS, you can always just perform the DNS challenge.

This technique may also lead to some prolonged attacks that may not be as easy to detect for the user. There is no sense of when the modification to the TXT record actually occurred and everything else seems to be fine. (This would still require some unprivileged box access, but this is the threat model we are trying to stop)

Finally, the CA will likely want to control which ports it thinks is valid for the current challenge.

Remember, as a client, you have to satisfy the CA and the CA is on the hook for any mistakes in verification. I know the Let's Encrypt CA will take additional policy measures to improve security and avoid misissuance.

What is more likely is that the challenges will allow the CA to specify a port to perform the challenge on... especially when ACME CAs begin issuing for different services.