On 11/26/15 11:50, Yoav Nir wrote:
On 26 Nov 2015, at 1:43 PM, Rob Stradling <[email protected]> wrote:
On 26/11/15 11:37, Stephen Farrell wrote:
<snip>
True. A port-specific cert would only work with updated browsers
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?
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.
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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
