Adam Eijdenberg wrote: > On Wed, May 17, 2017 at 2:46 AM, Damien Miller <djm@xxxxxxxxxxx> 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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
