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

[Stephen Farrell]

On 26/11/15 08:36, Eliot Lear wrote:
> Yes.  The real issue here is that the cert contains the hostname and not
> 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
> for what amounts to a privilege escalation attack.
> 
> On 11/26/15 4:18 AM, Phillip Hallam-Baker wrote:
>> 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.
> 
> 
> 
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> 



signature.asc
Description: OpenPGP digital signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Yoav Nir]

> On 26 Nov 2015, at 1:00 PM, Stephen Farrell  wrote:
> 
> 
> 
> On 26/11/15 08:36, Eliot Lear wrote:
>> Yes.  The real issue here is that the cert contains the hostname and not
>> 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;-)

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


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Stephen Farrell]

On 26/11/15 11:27, Yoav Nir wrote:
> 
>> On 26 Nov 2015, at 1:00 PM, Stephen Farrell
>>  wrote:
>> 
>> 
>> 
>> On 26/11/15 08:36, Eliot Lear wrote:
>>> Yes.  The real issue here is that the cert contains the hostname
>>> and not 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;-)
> 
> 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 
> Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Peter Eckersley]

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.

On Tue, Nov 24, 2015 at 11:37:36AM -0500, Kathleen Moriarty wrote:
> 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
> 
> On Tue, Nov 24, 2015 at 8:11 AM, Randy Bush  wrote:
> >> 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
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> 

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Phillip Hallam-Baker]

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.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Niklas Keller]

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

2015-11-24 17:49 GMT+01:00 Eliot Lear :

> Yes, thanks, Yoav.  Apologies to Randy and Kathleen for my terseness.
>
> Eliot
>
>
> On 11/24/15 5:46 PM, Yoav Nir wrote:
> > 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 <
> kathleen.moriarty.i...@gmail.com> wrote:
> >>
> >> 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
> >>
> >> On Tue, Nov 24, 2015 at 8:11 AM, Randy Bush  wrote:
>  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
> >>>
> >>> ___
> >>> Acme mailing list
> >>> Acme@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/acme
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >>
> >> ___
> >> Acme mailing list
> >> Acme@ietf.org
> >> https://www.ietf.org/mailman/listinfo/acme
> >
>
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Yoav Nir]

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 
>  wrote:
> 
> 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
> 
> On Tue, Nov 24, 2015 at 8:11 AM, Randy Bush  wrote:
>>> 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
>> 
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Eliot Lear]

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

Eliot


On 11/24/15 5:46 PM, Yoav Nir wrote:
> 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 
>>  wrote:
>>
>> 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
>>
>> On Tue, Nov 24, 2015 at 8:11 AM, Randy Bush  wrote:
 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
>>>
>>> ___
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
>> -- 
>>
>> Best regards,
>> Kathleen
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>




signature.asc
Description: OpenPGP digital signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Hugo Landau]

On Mon, Nov 23, 2015 at 09:52:07AM -0800, Martin Thomson wrote:
> 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.

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.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Randy Bush]

> 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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Douglas Calvert]

On Mon, Nov 23, 2015 at 12:52 PM, Martin Thomson 
wrote:

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



How does showing control over port 443 convey more information than showing
control over port 22, 80, 487, 1023?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Martin Thomson]

On 23 November 2015 at 10:09, Douglas Calvert
 wrote:
> How does showing control over port 443 convey more information than showing
> 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)

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Randy Bush]

which is easier, going through kink on 443 or getting the IT security
team to punch a hole for ?

randy

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Peter Eckersley]

+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?

On Mon, Nov 23, 2015 at 09:52:07AM -0800, Martin Thomson wrote:
> 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  wrote:
> > 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
> >
> >
> > On Nov 21, 2015, at 1:03 PM, Salz, Rich wrote:
> >
> >> Please see here for the background: 
> >> https://github.com/ietf-wg-acme/acme/issues/4
> >>
> >> But discuss this on the mailing list.
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> 

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Randy Bush]

>> which is easier, going through kink on 443 or getting the IT security
>> team to punch a hole for ?
> 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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Russ Housley]

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


On Nov 21, 2015, at 1:03 PM, Salz, Rich wrote:

> Please see here for the background: 
> https://github.com/ietf-wg-acme/acme/issues/4
> 
> But discuss this on the mailing list.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme