Default "secrets"

Posted Jan 6, 2011 5:31 UTC (Thu) by adamgundy (subscriber, #5418)
Parent article: Default "secrets"

the problem with generating the key on first use is that you get warnings from web browsers about 'invalid' (unsigned) certificates.

the reason all the embedded devices are shipped with hardcoded keys is that the vendors have paid for a signed cert...

to post comments

Default "secrets"

Posted Jan 6, 2011 10:54 UTC (Thu) by Fowl (subscriber, #65667) [Link] (2 responses)

Never seen that before. All I've seen have been self signed, or involve getting a subdomain and cert from the vendor. (ie. Windows Home Server)

Having thought about how else it could "worl" for a while, the only two ways I can think of are:

The vendor purchasing a FQDN. getting a CA signed cert for that domain, put that cert in the firmware image, then either:

* pointing it to a RFC 1918 address (internal, eg. 192.168.1.1)
* configuring the device to engage in some sort of dns spoofing.

All of which.. seems bad.

Am I close?

Default "secrets"

Posted Jan 6, 2011 17:35 UTC (Thu) by adamgundy (subscriber, #5418) [Link]

if I remember the Slashdot discussion correctly, I think they're shipping with signed keys for the default IP address, so eg https://192.168.0.1/ doesn't complain.

Default "secrets"

Posted Jan 7, 2011 11:48 UTC (Fri) by james (guest, #1325) [Link]

The domestic routers I've seen ship with DNS and DHCP servers enabled, and the DHCP tells clients to use the router as DNS server. That gives the router a clean way of resolving special domain names itself.

I imagine few users actually bother setting up static IP addresses, and many of those that do still use the router for DNS resolving (you don't know when your ISP is going to change their setup).

Shipping SSL enabled devices

Posted Jan 6, 2011 13:35 UTC (Thu) by alex (subscriber, #1355) [Link] (8 responses)

I have the same problem. We ship a pre-configured server that has a web-based component. Some users would like all that traffic to be encrypted via SSL but that will open a flood of support calls when they complain the browser says the connection is insecure.

We ship a USB with these systems for re-install, however I guess we'll have to make a custom key for every customer with their own unique signed certificates on them. I bet they won't keep the key secure either.

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.

Shipping SSL enabled devices

Posted Jan 6, 2011 17:40 UTC (Thu) by adamgundy (subscriber, #5418) [Link]

same problem here. we support SSL, but customers generally don't have the knowledge to self-sign, and don't want the cost (or more likely haven't got the skillz) to buy a signed cert from someone (also, it's more tricky to get a signed cert for a LAN only machine). end result is typically it doesn't get used.

Shipping SSL enabled devices

Posted Jan 7, 2011 8:26 UTC (Fri) by madhatter (subscriber, #4665) [Link] (6 responses)

There is, that's what "permanently store this certificate" is for. The sadness is that even browsers that allow you to do that make such a bloody song-and-dance about it, causing (as you say) support calls; whereas ssh accepts that this is a normal operational mode for self-signatures, pops up a simple text message that doesn't give a "sky is falling" impression, and gets on with it.

I agree that browsers handle this badly, but the better ones do handle it.

Shipping SSL enabled devices

Posted Jan 7, 2011 13:57 UTC (Fri) by ballombe (subscriber, #9523) [Link] (5 responses)

I do not think any browser associate the certificate with the IP address.
They only store the certificate, which is much less secure.

Shipping SSL enabled devices

Posted Jan 7, 2011 14:38 UTC (Fri) by madhatter (subscriber, #4665) [Link] (4 responses)

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.

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.

Default "secrets"

Posted Jan 6, 2011 23:13 UTC (Thu) by iabervon (subscriber, #722) [Link] (10 responses)

It's a good thing we have browsers to tell us that devices that are secure are insecure and devices that are insecure are secure.

The sensible thing for browsers to do with SSL connections to private IP addresses is to (a) insist that they be self-signed certificates, because no CA in their list signing them could possibly be trustworthy; (b) tell the user to refer to the documentation for the device to find out how to verify the certificate; (c) ignore the subject of the certificate, since it's got to be meaningless, and use the fingerprint instead to find it again; (d) store a user-chosen name which will be displayed differently from a PKI-certified name.

Of course, it's a bit unclear how the device should communicate the correct fingerprint to the user. Probably the right way would be to boot the device at the factory, get its fingerprint, and print it on a label.

Default "secrets"

Posted Jan 6, 2011 23:27 UTC (Thu) by adamgundy (subscriber, #5418) [Link] (9 responses)

and all of that means that 99% of users of the device are now either (a) on the phone to your support department because the link they were told to click has thrown up a scary warning, or (b) not using https at all.

how has that improved security?

this is the entire problem. there's a good (in some sense of the word) reason for having these hard-coded, signed keys. the problem is that now it's busted, and there's no clear solution.

there are many people out there that think the whole 'self signed cert' scary warnings are useless, and should be ditched entirely - maybe just don't change the URL bar color if the cert doesn't match - on the grounds that some encryption (without authentication) is a whole lot better than no encryption. that doesn't play well with commercial sites, though, who are paranoid someone's spoofed their DNS and want the browser to throw a scary warning.

Default "secrets"

Posted Jan 7, 2011 0:15 UTC (Fri) by iabervon (subscriber, #722) [Link] (8 responses)

Users are currently using an insecure method to connect to their devices, and being told it is secure. That's a security flaw that browsers are helping to cause. As a minimum, browsers should identify that a device is using a PKI-issued cert for a private identity, and simply tell users that this can't possibly provide any meaningful security.

Personally, I like the method that Chromium uses: if a site is using https in a way that the browser doesn't trust, it crosses out the "https" in the URL in red and acts like it's a normal unsecured connection. It's hard for commercial sites to complain about this, since they don't want the browser to give big scary warnings for their http URLs, which are obviously not protected. But the browser should similarly cross out the "https" in the case where it's a certificate signed by a CA for something that the browser knows the CA didn't verify.

Default "secrets"

Posted Jan 7, 2011 0:17 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

why do you say that a PKI cert for a private entity cannot possibly be valid? I have quite a few servers in my company that prove different.

Default "secrets"

Posted Jan 7, 2011 3:50 UTC (Fri) by foom (subscriber, #14868) [Link] (2 responses)

Your certs are probably for something like hostname.office.mycompany.com, which is perfectly fine.

A cert for the IP address "192.168.0.1" though, is *NOT* fine, there's no way a CA could possibly verify that you own that address (since, well, you don't).

Default "secrets"

Posted Jan 7, 2011 6:21 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

certs are generally not issued for IP addresses in the first place, be they public IP addresses or private IP addresses.

Default "secrets"

Posted Jan 7, 2011 6:28 UTC (Fri) by foom (subscriber, #14868) [Link]

Sure they are. Google finds me this, for example:
https://www.globalsign.com/digital_certificate/options/pu...

Default "secrets"

Posted Jan 7, 2011 0:28 UTC (Fri) by adamgundy (subscriber, #5418) [Link]

chrome(ium) also throws up a big red warning page that you have to accept before you can proceed. many (most) users will go no further.

as far as whether a CA verified the IP address.. I don't think it's conclusive that they *didn't* verify it. most of these certs are on (consumer) routers, which have a default IP address. it's not beyond the realm of possibility that a CA verified that the IP address they're signing is the one the router uses. that's just as valid as the 'certification' they do for a domain name by sending out an email to postmaster@... and hoping 'postmaster' doesn't just click the link because 'it looked official' (and yes, I've seen that happen).

this is one of two recent problems that really have no good solution (read: the solutions are very expensive). firesheep being the other one, making session surfing ridiculously easy.

the only real, cost effective solution to these problems is an SSH style 'seen it' key repo in the browsers. the first time you visit a site with a self signed cert (which is otherwise valid), you get a very *non scary* warning that this is the first time you've visited the site. after that, no warnings whatsoever unless the cert changes. the problem with this solution is: IE6, IE7, IE8, Firefox < 4, Chrome < 6, etc, etc will still be throwing fits about 'invalid certs'.

Default "secrets"

Posted Jan 7, 2011 1:11 UTC (Fri) by djao (guest, #4263) [Link] (2 responses)

As a minimum, browsers should identify that a device is using a PKI-issued cert for a private identity, and simply tell users that this can't possibly provide any meaningful security.

Your complaint, while valid, misses the biggest issue. It's a bit like ticketing a drunk driver for a seatbelt violation.

The biggest problem is that browsers are totally and utterly dependent on certificates for authentication. The widespread incorrect belief in the need for certificates represents the single biggest factor in perpetuating exactly the sort of insecure situations that this very article is about.

Do you trust SSH? As others here have pointed out, SSH (in its default configuration) uses no certificates. The program simply caches the key the first time it is used, and warns the user if the key ever changes. The SSH authentication model is nowadays called TOFU or "trust on first use." For someone setting up a wireless router, trust-on-first-use is perfectly fine. A user, even an unskilled one, is generally aware of the fact that they are setting up a router for the first time, and that they might have to click on boxes to accept a key.

There are many other wireless hardware devices with security implications (such as bluetooth keyboards) that already use TOFU authentication with great success. All the posters here who are complaining that it can't be done, that it would generate hundreds of support calls, are simply ignoring the fact that it not only can be done, but already is being done with no problems.

The fault in this case lies squarely with the browser manufacturers, for not supporting TOFU, and more generally for providing no authentication mechanisms whatsoever other than certificates. (Yes, a skilled user can achieve the equivalent of TOFU in Firefox. It takes five mouse clicks worth of scary dialog boxes. This doesn't count as support.) Secondary blame belongs to the companies that generate certificates, for lobbying browsers to require certificates in order to preserve their lucrative protection racket.

Default "secrets" and Trust On First Use

Posted Jan 7, 2011 17:49 UTC (Fri) by scripter (subscriber, #2654) [Link] (1 responses)

TOFU might be a step in the right direction, but it's not going to eliminate scary certificate warning support calls when someone changes out their router for a different model.

Default "secrets" and Trust On First Use

Posted Jan 7, 2011 19:05 UTC (Fri) by iabervon (subscriber, #722) [Link]

Depends; if the big warning is: "This is not your usual router!" the user is going to say, "Well, that's good, because I got a new one." Car companies don't get support calls when people buy new cars and their old car keys don't work any more. It comes back to the fact that browsers give misleading messages about security concerns, based on the assumption that your router is either a bank or someone pretending to be a bank. If they had suitable behavior for talking to network hardware, it would be easy to have a big warning that is either really scary or comforting depending on whether you know that you changed out your router. I mean, if someone else has swapped your router for a different one without your knowledge, your computer probably ought to give you a big scary warning; just because the attacker who has hijacked your connection to your router is using a router you might have bought doesn't make it any better.