Re: [Acme] Server on >= 1024 port

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Dec 2, 2015 at 10:17 AM, Richard Barnes <[e-mail]> wrote:

> 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.
>


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.