Shipping SSL enabled devices

Posted Jan 7, 2011 14:38 UTC (Fri) by madhatter (subscriber, #4665)
In reply to: Shipping SSL enabled devices by ballombe
Parent article: Default "secrets"

Im not sure I accept that ssh does either. If you access a remote host by FQDN, then the host name is what's stored in known_hosts, along with the public key (at least, this seems to be so for my ssh, which is OpenSSH_5.5p1). ssh *can* cache an IP address, to be sure, but for people making use of the DNS, I'm not sure it does.

Similarly, once you tell the browser to cache a certificate, the certificate has the FQDN for which it's valid embedded inside itself (as the CN). That certificate, cached in a trusted cache though it be, can't be used to authenticate another site, even one using the same keypair (which shouldn't happen).

The two situations seem remarkably similar to me.

to post comments

Shipping SSL enabled devices

Posted Jan 7, 2011 15:04 UTC (Fri) by rfunk (subscriber, #4054) [Link] (3 responses)

SSH stores both the name and address. When the address changes but the name and key remain the same, I get an alert about it.

Shipping SSL enabled devices

Posted Jan 7, 2011 15:31 UTC (Fri) by madhatter (subscriber, #4665) [Link] (2 responses)

I beg to differ, at least partly. "foo" is a disposable /etc/hosts entry for my laptop; risby is my desktop.

[madhatta@risby madhatta]$ ping foo -c 1
PING foo (192.168.3.202) 56(84) bytes of data.
64 bytes from foo (192.168.3.202): icmp_req=1 ttl=64 time=0.290 ms
[...]
[madhatta@risby madhatta]$ ssh foo
madhatta@foo's password:
Last login: Fri Jan 7 15:16:47 2011 from risby.home.teaparty.net
[madhatta@anni ~]$

log out, reIP foo to 192.168.3.203, update risby's /etc/hosts, and try again:

[madhatta@risby madhatta]$ ping foo -c 1
PING foo (192.168.3.203) 56(84) bytes of data.
64 bytes from foo (192.168.3.203): icmp_req=1 ttl=64 time=1.50 ms
[...]
[madhatta@risby madhatta]$ ssh foo
Warning: Permanently added the RSA host key for IP address '192.168.3.203' to the list of known hosts.
madhatta@foo's password:
Last login: Fri Jan 7 15:16:58 2011 from risby.home.teaparty.net
[madhatta@anni ~]$

I see no alert. I do see a warning that a key has been cached against a new IP address, but when I repeated this test (with that key then cached against the name and both IP addresses) I saw no message whatsoever.

I accept that keys are stored against ip addresses as well as against names, but I don't accept a general assertion that when "the address changes but the name and key remain the same, I get an alert about it". When the address is novel for that name, yes; other times, no.

Cacheing an SSL certificate in a browser creates an entity that links a public key and a domain name. SSH goes further than this, I accept, but it doesn't go all the way.

Remember that the original comment that started me off was

> I wish their was a way to do it the SSH way, i.e. you've seen this
> machine once before so you can be sure it's the same machine.

I am not yet convinced that "permanently store this certificate" is not such a mechanism.

Shipping SSL enabled devices

Posted Jan 7, 2011 17:21 UTC (Fri) by giraffedata (guest, #1954) [Link] (1 responses)

Warning: Permanently added the RSA host key for IP address '192.168.3.203' to the list of known hosts.
...
I see no alert. I do see a warning that a key has been cached against a new IP address,

You don't mean cached. The list of known hosts is not a cache. A cache is a local copy you keep to accelerate future lookups; the list of known hosts has an entirely different purpose.

It's interesting to see the detail that you can switch back to a previously seen IP address and SSH won't issue a scary message, but I'm not sure that affects any of this discussion, because the scary message on the original change is enough to trigger all the concerns.

SSH is wrong to do this, by the way. The whole point of SSL is that you don't trust the IP network routing, so you authenticate an identity that is independent of that. And the whole point of DNS is that you can move a server to another IP address (as you often must to change its physical location) and users don't see a change in identity.

And even if SSH is concerned the public key encryption could be broken and wants to offer the additional security of telling you the name resolution changed, it shouldn't associate the IP address with the key, but rather with the FQDN, resulting in the message, "Warning: adding IP address 192.168.3.203 to the list of IP locations for foo".

Shipping SSL enabled devices

Posted Jan 7, 2011 19:11 UTC (Fri) by madhatter (subscriber, #4665) [Link]

According to wikipedia, you are right, I don't mean cache. I hadn't been aware that I was misusing that term, and will try to avoid doing so in future - thanks for that! - though now I need a word to describe what ssh is doing.

In fairness to ssh, as I demonstrated above, it is doing exactly what you asked it to: putting up a message when it associates a new IP address with a known host name. But I agree the message could be more helpful.

I think this thread is rather separating those like ballombe, who do want to know when the IP of a server offering a service they use changes, from those who don't, like yourself.

I've found this thread most stimulating, and I now find myself having to sit down and think harder about what I want from an authentication service in a world where DNS is not trustworthy.