Subject: [Acme] Server on >= 1024 port

From: Paul Millar <[email-masked]>
Date: Wed, 25 Nov 2015 11:13:56 +0100

Hi,

[apologies if this question duplicates the earlier thread "Issue: Allow 
ports other than 443"]

I was wondering whether people have considered services running on a 
port other than port 443; in particular, ports greater than 1024.

One particular use-case is that some services run on a higher port as 
they can (more easily) run as a non-root user, limited the danger if the 
service is compromised.

As I understand it, Domain Validated certificates provide an assurance 
about the DNS name of the asserted identity.  It specifically makes no 
claim who is running the service.

Therefore, there seems no reason to limit ACME to the traditionally 
secure port number.

Cheers,

Paul.

---

From: moparisthebest <[email-masked]>
Date: Wed, 25 Nov 2015 12:14:26 -0500

Hello all,

On 11/25/2015 05:13 AM, Paul Millar wrote:
> I was wondering whether people have considered services running on
> a port other than port 443; in particular, ports greater than
> 1024.

I'm also somewhat concerned about this, I've read statements like this
when talking about port 443:

> ACME server needs some sort of assurance that the client controls
the server.

But I don't really know why that is or should be the case at all?
Certs aren't really issued to the machine, but rather to any service
on any port.  There are countless services that run over TLS, IRC
generally on 6697/7000/9999, XMPP on 5223, imaps, smtps, pops etc etc etc.

Why shouldn't the client simply be able to tell the ACME server what
port to test, and the ACME server assume if the client has access to
ANY port on the server then it should be able to host ANY TLS service
on that server?

Thanks,
moparisthebest

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Nov 2015 09:15:25 -0800

> ANY port on the server then it should be able to host ANY TLS service
Because this doesn't match operational reality on a number of shared
hosting systems.

-Ekr

> moparisthebest
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: moparisthebest <[email-masked]>
Date: Wed, 25 Nov 2015 12:28:47 -0500

On 11/25/2015 12:15 PM, Eric Rescorla wrote:
> On Wed, Nov 25, 2015 at 9:14 AM, moparisthebest wrote:

That sounds like a problem for the sysadmin's who misconfigured those
shared systems?

A domain validated certificate doesn't and never has said "This entire
machine is controlled solely by the domains specified in this
certificate", instead it says "This particular service/port on this
server is authorized by this domain to provide this service, however
this machine or even this port (via SNI) could host plenty of other
services/domains as well"

---

From: Roland Zink <[email-masked]>
Date: Wed, 25 Nov 2015 19:22:08 +0100

> services/domains as well" 
The resolution of a certificate is the domain name, e.g. it is valid for 
all services on the machine. If you get the certificate for a port then 
you may misuse it to intercept traffic to other ports / services.

Roland

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Nov 2015 15:32:59 -0800

On 25 November 2015 at 02:13, Paul Millar <[email-masked]> wrote:
> Therefore, there seems no reason to limit ACME to the traditionally secure
> port number.

I would be OK with having an ACME server validate against any port,
but only if it were going to issue a certificate with a subjectAltName
that references the port number in question.  Otherwise, for the
reason ekr noted, a user that happens to get shell access on a shared
hosting environment could get certificates issued to them for the
entire domain.

---

From: Paul Millar <[email-masked]>
Date: Thu, 26 Nov 2015 10:49:50 +0100

> you may misuse it to intercept traffic to other ports / services.

This is certainly true for any certificate that asserts the DNS name 
only (irrespective of the vetting: DV, OV or EV).  There's an inherent 
trust relationship between everyone running services under the same DNS 
name.

One potential solution is for the CA to issue a certificate that assert 
the DNS and port number together; for example, with a URI as the only 
SubjectAltName.

Unfortunately, it looks like there is no support in openssl/libressl for 
certificates with only URI-based SubjectAltName.

Cheers,

Paul.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Nov 2015 03:16:52 -0800

> all services on the machine.

        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE

from a soon very popular ca

randy

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Nov 2015 13:17:00 +0200

> On 26 Nov 2015, at 11:49 AM, Paul Millar <[email-masked]> wrote:
> 
> This is certainly true for any certificate that asserts the DNS name only (irrespective of the vetting: DV, OV or EV).  There's an inherent trust relationship between everyone running services under the same DNS name.
> 
> One potential solution is for the CA to issue a certificate that assert the DNS and port number together; for example, with a URI as the only SubjectAltName.
> 
> Unfortunately, it looks like there is no support in openssl/libressl for certificates with only URI-based SubjectAltName.

That is one issue. The other is that it goes against section 3.1 in RFC 2818:

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used.

Yes, you could have a URI SAN, but clients would ignore that one and take the server name from the CN field or another dNSName SAN. So the certificate would still apply to all ports. Even if we decide to update 2818, all existing browsers and clients would have the above behavior, so they would be vulnerable to the privilege escalation.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Nov 2015 13:20:44 +0200

> On 26 Nov 2015, at 1:16 PM, Randy Bush <[email-masked]> wrote:
> 

The other CAs do the same. Notice how it says “Web server authentication”, not “port 443 server authentication”.  Another thing is that I don’t get why some CAs have the web *client* authentication EKU thrown in there.  Either way, that certificate is just as good for port 5000 (python flask’s default port) as it is for port 443, and vice versa.

Yoav

---

From: Rob Stradling <[email-masked]>
Date: Thu, 26 Nov 2015 11:32:34 +0000

On 26/11/15 11:20, Yoav Nir wrote:
<snip>
> Another thing is that I don’t get why some CAs have the web *client* authentication EKU thrown in there.

Because a sufficiently large number of customers asked for it.  :-)

AIUI the use case is server-to-server comms, where server A acts as a 
TLS client and server B requires TLS client auth.  Server A also acts as 
a TLS server and its operator doesn't want to have to manage 2 different 
certs.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Nov 2015 11:35:43 +0000

> a TLS server and its operator doesn't want to have to manage 2 different

Yep. I also want that. Not needed everywhere but it's good to have.

S.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 26 Nov 2015 11:38:37 +0000

> Yep. I also want that. Not needed everywhere but it's good to have.

Yes, it's not needed everywhere, but for the sake of simplicity it's 
easier to just include it by default.