Subject: [Acme] Issue: Allow ports other than 443

From: "Salz, Rich" <[email-masked]>
Date: Sat, 21 Nov 2015 18:03:16 +0000

Please see here for the background: https://github.com/ietf-wg-acme/acme/issues/4

But discuss this on the mailing list.

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Nov 2015 11:55:16 -0500

Allowing the Web server to continue running on 443 while validation takes place on another port seems like a straightforward resolution to the issue that is raised.

Russ

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 09:52:07 -0800

The problem is that it the ACME server needs some sort of assurance
that the client controls the server.  Showing control over the server
on port 443 is probably the best signal possible.

Showing control over a server on ports < 1024 might be OK.  Some
operating systems require additional privileges to serve on those
ports.  That said, it's not universal, though I'm not sure whether it
matters for those cases where <1024 is available without access
controls.

Could we ask IANA for a reserved system port (<1024)?  Then it would
be possible for an ACME client to operate without disturbing running
services.

On 23 November 2015 at 08:55, Russ Housley <[email-masked]> wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Douglas Calvert <[email-masked]>
Date: Mon, 23 Nov 2015 13:09:37 -0500

> matters for those cases where <1024 is available without access

How does showing control over port 443 convey more information than showing
control over port 22, 80, 487, 1023?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 10:23:07 -0800

> control over port 22, 80, 487, 1023?

Basic information theory:
p(control over 443) < p(control over any port under 1024) < p(control
over arbitrary port)

---

From: Randy Bush <[email-masked]>
Date: Tue, 24 Nov 2015 04:13:54 +0100

which is easier, going through kink on 443 or getting the IT security
team to punch a hole for <iana-assigned-acme>?

randy

---

From: Peter Eckersley <[email-masked]>
Date: Mon, 23 Nov 2015 19:33:25 -0800

+1 on both Rich's request and the IANA suggestion. 

I think something that would help for this purpose would be an
Internet-wide zmap scan of some plausible ports, to ensure there isn't
anything in widespread use on them that could be a relevant attack
surface for the challenge protocols.

Anyone interested in volunteering to do some scans?

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 20:45:52 -0800

> team to punch a hole for <iana-assigned-acme>?

A very good question.  Would it help if you could choose the option
that sucked least for your particular situation?  That was what I was
thinking.

---

From: Randy Bush <[email-masked]>
Date: Tue, 24 Nov 2015 08:40:32 +0100

> Would it help if you could choose the option that sucked least for
> your particular situation?  That was what I was thinking.

yes, it would help

i admit to thinking of it as turning off a magic feature that wants to
get you in trouble with IT security.  we're talking about the kind of
folk who scan all internal address space and whack you if you have an
ssh port that allows password based access (i actually appreciate this
one).

randy

---

From: Hugo Landau <[email-masked]>
Date: Tue, 24 Nov 2015 10:17:18 +0000

> be possible for an ACME client to operate without disturbing running

I wrote this on the github issue, but should have posted it here:

It seems like there is a clear roadmap for doing this securely:

  - Register a new port <1024 with IANA, exclusively for the purposes of
    ACME challenge. The semantics of this port is that control of it is
    deemed to constitute control of the system.

  - Might want to require that TLS be used on this port; otherwise you
    have the possibility that either HTTP or TLS (either for HTTP or
    DVSNI) is running on the port. These sorts of ambiguities should be
    avoided. It also allows this "hostmaster" port to be extended for
    other purposes at a later time via ALPN.

  - Allow either port 443 or that port to be used.

  - Arguably, one should not even allow the use of port 443 if this port
    is open. Note that use of 443 has already proven a problem once with
    the vulnerabilities in the dvsni challenge mechanism w.r.t. common
    hosting configurations.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Nov 2015 13:42:52 +0100

Isn't this precisely what .well-known was meant to address?

Eliot

---

From: Randy Bush <[email-masked]>
Date: Tue, 24 Nov 2015 14:11:31 +0100

> Isn't this precisely what .well-known was meant to address?

fun small research project.  what percentage of well-known ports can
you connect to from the outside to a machine inside cisco?  hell, to
what percentage of well-known ports outside cisco can you reach from
inside?

well-known does not correlate well with open to access by IT security
departments.

randy

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Nov 2015 11:37:36 -0500

I agree with Eliot, I don't think a scan is needed to make a decision
here.  Having managed several networks that would not have allowed you
access from some random scanner, I don't think you'll get all the data
you are looking for.  In a well managed network, the IDS/IPS should
detect that it is a scan and block all future probes once you hit a
small number of ports/IPs.  So you may get a small sample with
everything else failing within an address block.  Granted, not all
networks are managed well and you may get a good amount of data.

If this connection was expected to a few servers, then a network
manager might just allow those only on the assigned port.

Without any hat on, I agree that a port + 443 as an alternate is a good plan.

Kathleen

-- 

Best regards,
Kathleen

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Nov 2015 18:46:23 +0200

I think Eliot meant RFC 5785 /.well-known/ locations, rather than well known ports

Yoav

> On 24 Nov 2015, at 6:37 PM, Kathleen Moriarty <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Nov 2015 17:49:36 +0100

Yes, thanks, Yoav.  Apologies to Randy and Kathleen for my terseness.

Eliot

---

From: Niklas Keller <[email-masked]>
Date: Wed, 25 Nov 2015 20:18:25 +0100

It's an issue with shared hosting where users have shell access but no root
access.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Nov 2015 20:25:58 +0100

On 11/25/15 8:18 PM, Niklas Keller wrote:
> It's an issue with shared hosting where users have shell access but no
> root access.
>
Sure. I presume we're expecting port 443 w/ SNI.  Users would write into
their root for their /.well-known, right?  Or do I have the flow wrong?

Eliot

---

From: Niklas Keller <[email-masked]>
Date: Wed, 25 Nov 2015 20:31:51 +0100

Oops, wrong thread, sorry. Was meant to be in response to the any port
(also >1024) thread.

---

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

> It's an issue with shared hosting where users have shell access but no root

If a user isn't able to write to the web server, or stand up any a
server on any "privileged" port, can they really be said to exercise
"control" over that server?  I certainly wouldn't consider that to be
a strong enough signal.

I think that these users will have to rely on access to the
.well-known tree if they are genuinely admins, but limited in their
access to the metal.  That might be more disruptive to their ongoing
operations, but I don't see any alternative that would satisfy me that
this isn't just some guy who happened to get shell access to a
machine.

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 25 Nov 2015 18:03:28 -0800

The argument for a scan is not that it will be comprehensive.

There's a huge amount of software out there that has started using
various ports in standard and non-standard ways; the more software
happens to use a given port, the more risk of remote attacks on ACME DV
via quirks or bugs in that software. So it would be best do a scan to
pick a port that is comparatively unused in the wild.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Nov 2015 22:18:53 -0500

I am getting really nervous about allowing any port other than 443.

I just did a scan of a very recent clean install of Windows and there are a
*TON* of Web servers running for apps that didn't mention they had one.

The thing is that if I am running a process on any sort of shared host, I
can pretty easily spawn a server and start applying for certs for other
domains. Not only can I get .well-known, I can have any host name I like.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Nov 2015 09:36:46 +0100

Yes.  The real issue here is that the cert contains the hostname and not
the port.  And so running the test on on other than 443 would provide
for what amounts to a privilege escalation attack.

On 11/26/15 4:18 AM, Phillip Hallam-Baker wrote:
> I just did a scan of a very recent clean install of Windows and there
> are a *TON* of Web servers running for apps that didn't mention they
> had one.
>
> The thing is that if I am running a process on any sort of shared
> host, I can pretty easily spawn a server and start applying for certs
> for other domains. Not only can I get .well-known, I can have any host
> name I like.

---

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

On 26/11/15 08:36, Eliot Lear wrote:
> the port. 

So one could define a new always-critical certificate extension
saying that the cert is only for use with some set of ports. (Or
maybe someone's already defined it, I forget;-)

That might enable automation in some situations that'd otherwise
be tricky.

If folks figured that'd be deployed by browsers, it'd be worth
doing. It might be worth doing even if only some other kinds
of application benefited, but the web (so just-443) would I
guess be the most-used value.

(Don't worry about whether that's in scope for acme, if it's
a dumb idea it won't be done anywhere and if it's not we'll
find a venue.)

S.

> And so running the test on on other than 443 would provide

---

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

> On 26 Nov 2015, at 1:00 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

An extension - not that I know of, but as was mentioned in the other thread, there’s the URI subject alternate name. However, no current browsers look at this field, so the URI SAN provides no security from the privilege escalation. OTOH a critical extension would block *all* existing browsers from relying on such a certificate, with the only remedy being “Let’s Not Encrypt”.

It might be OK if the extension was added only to certificates issued to those who could not meet the challenge on port 443, but I still prefer to not go there.

Yoav

---

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

On 26/11/15 11:27, Yoav Nir wrote:
>>> Yes.  The real issue here is that the cert contains the hostname
>>> and not the port.
>> 
> An extension - not that I know of, but as was mentioned in the other
> thread, there’s the URI subject alternate name. However, no current
> browsers look at this field, so the URI SAN provides no security from
> the privilege escalation. OTOH a critical extension would block *all*
> existing browsers from relying on such a certificate, with the only
> remedy being “Let’s Not Encrypt”.

True. A port-specific cert would only work with updated browsers
which I guess is a fairly fatal objection to the idea. Ah well.

S

> 
> It might be OK if the extension was added only to certificates issued
> to those who could not meet the challenge on port 443, but I still
> prefer to not go there.
> 
> Yoav
> 
> 
> _______________________________________________ Acme mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/acme
>

---

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

On 26/11/15 11:37, Stephen Farrell wrote:
<snip>
> which I guess is a fairly fatal objection to the idea. Ah well.

Is it worth considering requiring proof of control of (some particular 
combination of) _multiple_ ports rather than just a single port?  Would 
that strengthen the validation in any meaningful way?

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

---

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

> On 26 Nov 2015, at 1:43 PM, Rob Stradling <[email-masked]> wrote:
> 
> Is it worth considering requiring proof of control of (some particular combination of) _multiple_ ports rather than just a single port?  Would that strengthen the validation in any meaningful way?

Not really. I have user access (with shell) to the a bunch of Linux servers where I work. I can run programs and open any high port I want, but I can’t open ports below 1024. 

Running some script to run a web server on a bunch of high ports is trivial in a case like that. Of course “proper” environments won’t let anyone other than an administrator get shell access to a computer running a public-facing web server, but we can’t rely on all environments being properly run.

Yoav

---

From: Darren J Moffat <[email-masked]>
Date: Thu, 26 Nov 2015 12:04:47 +0000

> Running some script to run a web server on a bunch of high ports is trivial in a case like that. Of course “proper” environments won’t let anyone other than an administrator get shell access to a c…

Nor can you rely on "properly run" environments all enforcing the 
traditional UNIX privileged port concept of < 1024.  The whole idea that 
< 1024 is special is pretty close to pointless in the modern world if 
you are looking from the outside of the machine.

There are also plenty of cases I can think of where I need a single 
certificate for TLS but port 443 is only one of the possible ports that 
certificate will be used on.  I also have use cases for the TLS server 
sometimes being a TLS client of another TLS server and it is very 
desirable to use the same certificate when being the client or server.

-- 
Darren J Moffat

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Nov 2015 13:30:07 +0100

Hi,

> Running some script to run a web server on a bunch of high ports is trivial in a case like that. Of course “proper” environments won’t let anyone other than an administrator get shell access to a c…

I'd go further: requiring proof on multiple different ports requires
more code complexity and more network complexity wrt firewalls.  That
sounds like more trouble than it is worth for a DV cert.

Eliot