Subject: Re: [Acme] Server on >= 1024 port

From: Paul Millar <[email-masked]>
Date: Wed, 02 Dec 2015 10:52:22 +0100

Hi all,

I'm writing just to summarise this thread and check a consensus has been 
reached.

On 25/11/15 11:13, 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.

The decision is not to support unprivileged ports (>= 1024) because of 
two factors:

   1.	ACME wishes to support deployments where there are untrusted
	users have (non-root) access to the same machine that
	provides a trusted service.

   2.	There is no supported mechanism for a CA to issue a
	certificate that is bound to a specific port.

Removing either of these points would allow (in principal) ACME to 
support issuing certificates to services running on unprivileged ports.

Is that a fair summary?

Cheers,

Paul.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2015 08:30:39 -0500

On Wed, Dec 2, 2015 at 4:52 AM, Paul Millar <[email-masked]> wrote:

> The decision is not to support unprivileged ports (>= 1024) because of two
> factors:
>
> Removing either of these points would allow (in principal) ACME to support
> issuing certificates to services running on unprivileged ports.
>
> Is that a fair summary?

No.

The problem is that the validation process for the cert has nothing to do
with the port the cert is going to be used on. The purpose of the
validation process is to determine if the request is authorized by the
holder of the domain. It has nothing to do with what host or port the
certificate is going to be used for.

There is a useful rhyme:

Want a cert for HTTP? Validate the request on port 443
Want a cert for SMTP? Validate the request on port 443
Want a cert for NTP? Validate the request on port 443
Want a cert for Any other TP? Validate the request on port 443

The DNS only provides a binding between the domain name and the IP address
and the IP address identifies a Host that is typically shared between
multiple services and the OS can only be assumed to provide disambiguation
between domain names on port 443.

The only way to fix this would be to require navigation through an SRV
record and even that might not be enough.

Also note that this is not an area where IETF consensus is sufficient. The
IETF can publish an RFC describing a protocol that supports a particular
validation process. But that does not mean that the browser providers are
going to accept certs that are issued under that process.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Dec 2015 16:36:00 +0200

> On 2 Dec 2015, at 11:52 AM, Paul Millar <[email-masked]> wrote:
> 
> Hi all,
> 
> I'm writing just to summarise this thread and check a consensus has been reached.
> 
> The decision is not to support unprivileged ports (>= 1024) because of two factors:
> 
> Removing either of these points would allow (in principal) ACME to support issuing certificates to services running on unprivileged ports.
> 
> Is that a fair summary?

I think not. I think towards the end the discussion got to a point that we don’t think there is much difference between x>=1024 and x<1024 as long as x!=443. How particular operating systems authorize users to set up servers on different ports is not something we can make sweeping generalizations about. So I don’t think there is consensus to use any port other than 443 for validating certificates for HTTPS.

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2015 14:43:56 +0000

Speaking as co-chair, I think Yoav's summary is more accurate.  The consensus in the room at Yokohama was that there is not real support for other than 443, but that we need to discuss this on the list "one last time." I think closing discussion is a bit premature, but at this point there seems rough consensus to not require other than 443.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Dec 2015 10:17:47 -0500

I agree that we're converging on some rough consensus, but I would
frame it (again) slightly differently:

1. ACME needs to validate domain control, not domain+port control,
because (1) there is no current mechanism for issuing certificates for
domain+port (vs. just domain), and (2) the primary use cases for ACME
right now (DV certs, and possibly OV/EV) don't have any notion of
ports.

2. Thus the port used for validation needs to be one such that control
of the port is effectively control of the domain.

If you look at what CAs do today, that basically means the port is
80/443.  More generally, it means that the port needs to be specified
by the challenge mechanism and not by the client.

So that leaves us with 80/443 for the challenges we have today.  If
people want to define, say, a CalDAV challenge, they can argue for a
new challenge type, but ISTM it'll be a hard sell.

It's also worth noting that just because we define challenge types
doesn't mean any particular CA will support them (that's the point of
extensibility).  For example, Let's Encrypt doesn't support the
"dns-01" challenge.

--Richard

On Wed, Dec 2, 2015 at 9:43 AM, Salz, Rich <[email-masked]> wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Niklas Keller <[email-masked]>
Date: Wed, 02 Dec 2015 16:50:27 +0000

In order to validate domain ownership, we would have to have some DNS
record dictating the port. Otherwise there's no difference between 443 and
any other priviledged port.

Regards, Niklas

Richard Barnes <[email-masked]> schrieb am Mi., 2. Dez. 2015 16:17:

> > Speaking as co-chair, I think Yoav's summary is more accurate.  The
> consensus in the room at Yokohama was that there is not real support for
> other than 443, but that we need to discuss this on the list "one last
> time." I think closing discussion is a bit premature, but at this point
> there seems rough consensus to not require other than 443.
> >

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Dec 2015 08:51:54 -0800

> new challenge type, but ISTM it'll be a hard sell.
​There was discussion about registering a port specifically for ACME
challenges, so that a running server on 80/443 did not have to be changed
during ​the challenge.  That would be a privileged port, and we could
define the semantics for the challenges there to be similar to the 443
challenge (essentially a TLS-based challenge on a different, well-known
port).

I did not see consensus for this approach, but I also didn't detect the
same opposition to it that other approaches attracted.  If folks are
interested in supporting this approach, I'd suggesting writing a draft
which describes the challenge and proposes registration; that would give us
a more concrete understanding of whether the effort to support this would
be appropriate for the number of installations which would use it.

regards,

Ted

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2015 16:52:52 +0000

> Otherwise there's no difference between 443 and any other priviledged port.

What's a privileged port? :)  Clearly it's a local construct, at best.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2015 12:01:04 -0500

> right now (DV certs, and possibly OV/EV) don't have any notion of

Again, I think you are missing the real problem here. Let us say we have a
new protocol to run over port 666 that is actually a Web service under the
covers.

Hosting provider has a host that supports the following Web Sites that
belong to different parties:

example.com
malicious.com

The hosting provider allows any form of executable to run on the host
(10.6.6.6) that does not interfere with apache which has 80 & 443 reserved.
[This is typical]

Mallet controls malicious.com. He uploads an executable that opens a server
on port 666. Applies for a cert for example.com:666

CA tries to validate example.com:666

Resolves A record for example.com -> 10.6.6.6
Makes ACME validation request to http://example.com:666/

Mallet's server can ignore the HostName: field in the HTTP interaction
because it is his server. He can now get a cert for example.com:666

So the problem here is not merely that there is no such thing as a 'port
bound' certificate. The problem is that there is no way to validate a cert
for a single port.

My objection to this validation mechanism would stand even if there was a
port restriction option available in PKIX. And indeed we should have that
type of capability just for reasons of least privilege.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2015 12:25:55 -0500

> What's a privileged port? :)  Clearly it's a local construct, at best.
That is especially so in the new era of .NET Core and Raspberry Pi Zero.

One of the most powerful ways to run .NET Core is on bare metal on a
constrained device like a RaPi. I have a few RaPi's in the house that are
dedicated to one purpose.

If you are developing code for an embedded device there is no separation
between the 'root' and 'user' levels whatsoever. The closest you are likely
to come is that you may have a co-processor that will allow you to install
a public key pair in a secure partition so you can write to the private key
store and do private key operations but not a private key read operation.

These devices don't have an operating system. They just have the
application code running on a core library that is essentially just a BIOS
and some commonly used subroutines.

Oh and lots of these run Web Sites and you can put ASP on them. So they
behave like hosting services.

Assigning a well known port for ACME validation is a non starter because
there is no way that you are going to get all the half dozen suppliers of
sub $30 computers to all implement code to restrict the port.

What could work would be to assign a well known port for ACME and allow it
to be used PROVIDED THAT there is an indication in the DNS.

This could be an SRV record but I would prefer it to leverage CAA because
this would be an attribute designed to support certificate issue and CAA is
therefore the record to use.

So we might have a record of the form:

example.com  CAA  0 acmedv1 "port=666"

I prefer that over SRV because of separation of concerns. There might be
really good reasons to allow general access to the SRV record while CAA is
obviously a record that should be restricted because it is concerned with
cert issue. trying to use SRV would mean giving new semantics to an
existing record.

If we are going to use CAA however, why not just put a key/fingerprint into
a CAA record that specifies a key that can be used to validate requests?

---

From: Romain Fliedel <[email-masked]>
Date: Wed, 2 Dec 2015 18:52:48 +0100

> example.com  CAA  0 acmedv1 "port=666"
If you have to modify the dns to use a custom port, why not use the dns
validation method ? (once it's available)

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Dec 2015 09:57:02 -0800

> What's a privileged port? :)  Clearly it's a local construct, at best.

Under the name "system port" or "well-known port", it's been defined in
IANA-related RFCs for a long time; the current one is RFC 6335/BCP 165.  ​

The baseline expectation is that both a local system administrator and
remote parties know what service is running on a specific well-known port
because the port number is conventionally bound to that service.
​  If you are the administrator, you can, of course, ignore the
convention.

Speaking personally, I think the bar we're aiming for is that any challenge
should demonstrate effective control of the system currently bound to the
DNS name at issue or  effective control of the DNS.  Dynamic ports clearly
don't do that, and not all system ports do either (the experimental ports
clearly wouldn't).  To get agreement that a specific challenge does do
that, we kind have to have it written down and poked at; trying to reason
about the set in the abstract doesn't appear to me to be worth it.

No hats,

Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2015 12:57:07 -0500

> validation method ? (once it's available)

Well there is a slight difference. DNS validation is possibly encumbered
for a start.

If by DNS validation you mean 'put the response to the challenge in the
DNS' then that requires a lot more administrative connection to the DNS
than 'put the fingerprint of the validation key in the DNS'

---

From: Romain Fliedel <[email-masked]>
Date: Wed, 2 Dec 2015 19:09:57 +0100

> than 'put the fingerprint of the validation key in the DNS'

There was a discussion about dns validation that was suggesting using the
account public key hash as the DNS record value.
Thus it would be a relatively easy to provision the value correct value.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2015 15:00:39 -0500

On Wed, Dec 2, 2015 at 1:09 PM, Romain Fliedel <[email-masked]>
wrote:

>> On Wed, Dec 2, 2015 at 12:52 PM, Romain Fliedel <[email-masked]
>> > wrote:
>>
Well there is prior art on putting keys in the DNS.

The idea of using the DNS as a channel for a challenge-response mechanism
would make me nervous.

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 2 Dec 2015 14:03:02 -0800

> be appropriate for the number of installations which would use it.

I'm at present quite supportive of this approach for adding a single
specific port <1024 that is supported for DV challenges, and I thought that
in fact past discussions on this list had reached that as a likely
conclusion.  

Are there any strong arguments against having the protocol support this
use case for CAs that want to offer it?

-- 
Peter Eckersley                            [email-masked]
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 2 Dec 2015 14:06:03 -0800

> (10.6.6.6) that does not interfere with apache which has 80 & 443 reserved.

Are there any typical hosting environments in which such executables can
bind to port 666, while being unable to tear down and replace the
service that's bound of 443?  What are they?

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 2 Dec 2015 14:11:53 -0800

> service that's bound of 443?  What are they?

(And perhaps you were arguing elsewhere in this thread that .Net Core +
Raspberry Pi devices might be an example of this, but it would be an
interesting and surprising fact if ASP could bind :666 on such devices,
but not bind or reconfigure the server on :443)

---

From: James Cloos <[email-masked]>
Date: Wed, 02 Dec 2015 18:07:11 -0500

>>>>> "RB" == Richard Barnes <[email-masked]> writes:

RB> If you look at what CAs do today, that basically means the port is
RB> 80/443.  More generally, it means that the port needs to be specified
RB> by the challenge mechanism and not by the client.

What CAs do any kind of challenge over anything other than smtp?

Tcp port numbers have no significance to "control of a domain".

Or "control of a hostname", since the certs are issued for hostnames and
not for domain names.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Dec 2015 18:12:36 -0500

> What CAs do any kind of challenge over anything other than smtp?

Let's Encrypt and WoSign spring immediately to mind.  They both do
web-based validation.

SSLMate also supports HTTP-based validation, and their certs are
issued by real CAs.

So it's out there.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2015 19:11:57 -0500

> but not bind or reconfigure the server on :443)

The issue is that in a multi hosting environment, port 443 is managed by
the system and a hosted  Web service can only bind to a specific
port/hostname combination as a result. The hosted service gets a *share* of
port 443 while on any other port it gets the raw TCP/IP stream.

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 2 Dec 2015 16:29:06 -0800

> port 443 while on any other port it gets the raw TCP/IP stream.

This sounds theoretically for a VPS provider, though the host would
need a way to figure out what ports all the guest VMs were listening on.

Do we know of any specific hosting environments that operate this way?

---

From: James Cloos <[email-masked]>
Date: Wed, 02 Dec 2015 19:31:48 -0500

>>>>> "RB" == Richard Barnes <[email-masked]> writes:

JC>> What CAs do any kind of challenge over anything other than smtp?

RB> Let's Encrypt and WoSign spring immediately to mind.  They both do
RB> web-based validation.

RB> SSLMate also supports HTTP-based validation, and their certs are
RB> issued by real CAs.

Let's Encrypt is still a future CA, not a current one.

[Uttered with the hope that no-one misreads it as in any way negative
or criticizing.]

But given the others....

-JimC

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Dec 2015 16:41:31 -0800

> Let's Encrypt is still a future CA, not a current one.

In what way?

-Ekr

---

From: Niklas Keller <[email-masked]>
Date: Thu, 3 Dec 2015 01:48:42 +0100

> Let's Encrypt is still a future CA, not a current one.

Nope, it's not a future CA, it's a current one. It already issues trusted
certificates.

---

From: Randy Bush <[email-masked]>
Date: Thu, 03 Dec 2015 09:48:10 +0900

> Let's Encrypt is still a future CA, not a current one.

it's in my browser and i even managed to get the client-from-hell to get
a few certs for some sites.

randy

---

From: Eric Mill <[email-masked]>
Date: Wed, 2 Dec 2015 20:19:28 -0500

> SSLMate also supports HTTP-based validation, and their certs are

SSLMate also supports DNS-based validation (and since SSLMate is a
downstream provider of multiple upstream CAs, such as Comodo, each upstream
CA necessarily supports the same validation mechanism).

-- Eric

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Darren J Moffat <[email-masked]>
Date: Thu, 03 Dec 2015 09:31:50 +0000

> service that's bound of 443?  What are they?

While I don't know of any hosting environment, typical or otherwise, 
that does this it is possible to setup such an environment in Solaris 
and Linux.  In Linux you would do this using SELinux type enforcement 
policy to control which ports can be bound to.  In Solaris it is as 
simple as granting the process the privilege {net_privaddr}:666/tcp that 
process could then listen on port 666 tcp but not 443.

If anything it is more likely to be used to constrain the webserver to 
only be able to listen on 80 and 443 and not on other ports < 1024.

-- 
Darren J Moffat

---

From: Rob Stradling <[email-masked]>
Date: Thu, 3 Dec 2015 10:34:54 +0000

On 03/12/15 00:48, Niklas Keller wrote:
> Nope, it's not a future CA, it's a current one. It already issues
> trusted certificates.

https://crt.sh/?Identity=%25&iCAID=7395

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

---

From: Ángel González <[email-masked]>
Date: Fri, 04 Dec 2015 02:43:04 +0100

Ted Hardie wrote:
> There was discussion about registering a port specifically for ACME
> challenges, so that a running server on 80/443 did not have to be
> changed during the challenge.  That would be a privileged port, and
> we could define the semantics for the challenges there to be similar
> to the 443 challenge (essentially a TLS-based challenge on a
> different, well-known port).
> 
> I did not see consensus for this approach, but I also didn't detect
> the same opposition to it that other approaches attracted.  If folks
> are interested in supporting this approach, I'd suggesting writing a
> draft which describes the challenge and proposes registration; that
> would give us a more concrete understanding of whether the effort to
> support this would be appropriate for the number of installations
> which would use it.
> 
> regards,
> 
> Ted

This may not be required. Let's take a step back and look at the faced
problem:

- The ACME challenge (currently) requires the client to listen on 80 or
443
- On that server there is already a process listening there.
- The web server cannot be reconfigured to provide the file inside
.well-known
- The sysadmin doesn't want to stop the server while acquiring a
certificate.

Listening on another port solves it, albeit it raises the authorization
concern. Control of a port < 1024 will _probably_ be safe.

However, there's an even simpler way: redirect the request using the
firewall.

This way the client (or sysadmin manually following the steps) doesn't
need to edit the web folder, stop the service or even use that machine
if there's an intermediate box (such as a firewall or reverse proxy)
where it can be mapped.

The command to use is highly dependant on the underlying OS: iptables
on Linux, ipfw on Mac/Bsd, etc. but nothing that couldn't be checked by
the script or provided in a well-documented list for the network admin.

The only additional requisite to provide this on the client would be
for the CA to report the subnet (typically a /32 or /24) that from
which it will be verifying the challenge. AFAIK that's not currently
provided in the challenge. The CA would be asserting that it is in
control of that address space and the only connections from them to
$domain on the next $seconds will only be used for challenge
completion.

The actual command will be different for Linux, than Solaris, than
Cisco… but pretty much any decent box in front of a system that can't
have downtime will support this, even if it only has a limited web
interface.

The OS where this would be more problematic is Windows, as I don't
recall it having the ability to do that built-in (the most similar
feature seem to be netsh netproxy). However, it's also the OS where any
logged-in user can open any port, and thus wasn't properly addressed by
the “use a port < 1024” approach, either.

Best regards

---

From: Vincent Lynch <[email-masked]>
Date: Fri, 4 Dec 2015 02:10:44 -0500

Just to elaborate on what Eric Mill said:

Comodo allows validation of DV certs via the following methods:

1. Email based challenge
2. File based challenge: Upload a provided file with unique content to the
server. The file can be provided over HTTP or HTTPS.
3. DNS challenge: validation by adding a specified value via a CNAME record.

These challenges are evaluated automatically and the values generated are
based off hashes of the CSR.

RapidSSL, GeoTrust, and Thawte (all Symantec CAs) have similar mechanisms.
If anyone would like to test these methods, I can assist with providing
certificates and a medium through which these challenges are available.

On Wednesday, December 2, 2015, Eric Mill <[email-masked]> wrote:

>
> On Wed, Dec 2, 2015 at 6:12 PM, Richard Barnes <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> On Wed, Dec 2, 2015 at 6:07 PM, James Cloos <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> > James Cloos <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>         OpenPGP:
>> 0x997A9F17ED7DAEA6
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
Vincent Lynch