User: Password:
|
|
Subscribe / Log in / New account

Default "secrets"

Default "secrets"

Posted Jan 7, 2011 0:15 UTC (Fri) by iabervon (subscriber, #722)
In reply to: Default "secrets" by adamgundy
Parent article: Default "secrets"

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.


(Log in to post comments)

Default "secrets"

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

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]

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 (subscriber, #313) [Link]

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]

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]

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds