openssh unix dev - May 2017 - Golang CertChecker hostname validation differs to OpenSSH

On Wed, May 17, 2017 at 2:46 AM, Damien Miller <djm at mindrot.org>
wrote:
> On Mon, 15 May 2017, Adam Eijdenberg wrote:
>> https://github.com/golang/go/issues/20273
>>
>> By default they are looking for a principal named "host:port"
inside
>> of the certificate presented by the server, instead of just looking
>> for the host as I believe OpenSSH does.
>
> Darren will know better, since IIRC he added the port specifier to
> known_hosts originally. But I believe the behaviour is:
>
> If the default port is in use then the host principal is just the hostname.
>
> If a non-default port, then the host principals is "[host]:port".
>
> If a non-default port is in use and "[host]:port" doesn't
match, then
> try the plain hostname.
Hi Damien,

I think we're still talking a bit at cross purposes. My question did
not relate to how the known_hosts file is processed (which from
examining code yesterday I think is roughly as you describe) but
rather how should we be validating that a certificate presented by a
host includes an appropriate principal for that host. OpenSSH checks
whether the hostname is a principal, whereas the Go library is instead
checking whether "host:port" is a principal.

Uri (earlier in this thread) does answer this question clearly (that
the principal should be the hostname only), and, now that I've found
PROTOCOL.certkeys, this seems to be spelt out unambiguously there too:

"valid principals" is a string containing zero or more principals as
strings packed inside it. These principals list the names for which this
certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and
usernames for SSH_CERT_TYPE_USER certificates. As a special case, a
zero-length "valid principals" field means the certificate is valid
for
any principal of the specified type.

Cheers, Adam

Adam Eijdenberg wrote:
> On Wed, May 17, 2017 at 2:46 AM, Damien Miller <djm at mindrot.org>
wrote:
>> On Mon, 15 May 2017, Adam Eijdenberg wrote:
>>> https://github.com/golang/go/issues/20273
>>>
>>> By default they are looking for a principal named
"host:port" inside
>>> of the certificate presented by the server, instead of just looking
>>> for the host as I believe OpenSSH does.
>>
>> Darren will know better, since IIRC he added the port specifier to
>> known_hosts originally. But I believe the behaviour is:
>>
>> If the default port is in use then the host principal is just the
hostname.
>>
>> If a non-default port, then the host principals is
"[host]:port".
>>
>> If a non-default port is in use and "[host]:port" doesn't
match, then
>> try the plain hostname.
> 
> I think we're still talking a bit at cross purposes. My question did
> not relate to how the known_hosts file is processed (which from
> examining code yesterday I think is roughly as you describe) but
> rather how should we be validating that a certificate presented by a
> host includes an appropriate principal for that host. OpenSSH checks
> whether the hostname is a principal, whereas the Go library is instead
> checking whether "host:port" is a principal.
> 
> Uri (earlier in this thread) does answer this question clearly (that
> the principal should be the hostname only), and, now that I've found
> PROTOCOL.certkeys, this seems to be spelt out unambiguously there too:
In turn this means:
One cannot expect several SSH services on a single host to be securely
distinguishable
from each other by their particular service key. So if one of the SSH services
gets
compromised all SSH services on this host are subject to MITM attacks with the
private
key of the compromised service.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170517/3bb91fed/attachment.bin>

> Uri (earlier in this thread) does answer this question clearly (that
    > the principal should be the hostname only), and, now that I've
found
    > PROTOCOL.certkeys, this seems to be spelt out unambiguously there too:
    
    In turn this means:
    One cannot expect several SSH services on a single host to be securely
distinguishable
    from each other by their particular service key. So if one of the SSH
services gets
    compromised all SSH services on this host are subject to MITM attacks with
the private
    key of the compromised service.
    

Yes and no. The standards wisely do not allow port numbers as a part of the DNS
identity.

On the other hand, nobody prevents you from having different key pairs for the
same host name, given to different servers that you insist should run on the
same host but on different ports (for example, I have one ?name?, but a pile of
certificates and corresponding key pairs for that name that I present to
different (appropriate) entities). You can even figure how to mix their port
numbers into their names (just don?t make it ?hostname? :).

I still think it?s not a very good idea to ?securely distinguish several SSH
services running on a single host?, but it seems entirely doable if you?re bent
on it.
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170517/168da314/attachment.bin>