The only difference between what they're doing and what every other SSL issuer is doing already is 20 bucks. A cheap-o certificate from GoDaddy or your favorite reseller does no more than validate ___domain ownership by e-mail as this freebie does.
SSL is a messed up protocol, relying on trust in central authorities. SSH did it right: it only ensures that the server you connect with today is the same one you connected with yesterday, and it does not aim to do anything more.
An SSL certificate "verified by King George" does not mean that you can trust the vendor with your money or your data. I have to decide to trust the vendor that much, and nobody else can do it for me. All I want the crypto to do is verify that I am now talking with the same vendor I talked with yesterday.
I don't mind using a certified signed by someone not crowned as a king, for example https://secure.loom.cc. Or I could use this one https://loom.cc/ "verified by Equifax" which means nothing special to me.
I don't care that someone else decreed that "this is the One True loom.cc site." All I care is that the site I initially decided to trust is the same site I'm connecting with now.
This is more of an emotional argument than a pragmatic one. "Avoidance of central authority" isn't a meaningful engineering principle. If you look under the covers almost anywhere on the Internet, there are central authorities hiding: in the DNS, in routing and IP registries, and so on.
But that's not an interesting response to you. A more meaningful response goes:
This is the first time you've connected to bankofamerica.com.
The authenticity of this host can't be established.
The RSA modulus provided is
00:ce:fd:f1:ba:7b:84:6f:08:fb:fe:86:bc:57:dc:
97:51:23:f0:7f:d7:4c:ea:49:5e:54:78:c5:d6:8e:
68:8c:76:20:24:52:f6:d6:60:0a:c5:79:ec:03:7d:
1f:4d:d2:e9:ca:ec:f5:72:93:57:87:7d:75:b6:e8:
9d:b3:33:b7:8d:b7:9b:0f:4b:0e:4f:51:ba:fd:d7:
88:63:44:53:bd:50:cc:c3:bf:1b:ca:98:d8:d2:35:
a8:10:62:4a:05:a2:d8:54:1e:e1:40:b2:be:cf:69:
80:ba:ed:63:ab:d1:74:32:48:5f:19:a1:82:86:d1:
cd:89:16:be:d6:0a:f2:61:97
Are you sure you want to give this key access to your
bank account? (yes/no)
SSL (anchored keys) works better than SSH (key continuity) for the problems SSL needs to solve, because:
* The first connection made in a key-continuity system is essentially unsecured, which creates an unacceptable window for opportunistic attackers --- none of whom care which 5% of connections they snag, and
* There are vastly more SSL connections than SSH connections, meaning not only that browsers would have store many many many times as much security state, but that users would be constantly exposed to alerts when sites regenerated keys, and
* The anchor keys in your browser, while not particularly well reported, are at least feasible to audit by hand; on the other hand, hundreds or thousands of per-site keys would be impossible to inspect or verify, likely meaning that any program that runs on your machine could replace your bank's key.
The scheme you've proposed is not only impracticable, it's demonstrably less secure (anchored keys leave no simple window in which attackers can seize control of a relationship).
Interesting observations. How then would you suggest improving security against phishing? For example Grandma gets an email saying "You have initiated a large wire transfer from your Building and Loan account. Please log in to confirm this transfer." The email includes a helpful link to building-and-loan.ru, which Grandma clicks and her woes begin. I should add that the building-and-loan.ru site is "verified by Equifax".
Yes, it's pretty close. However where SSH warns you whenever you encounter a new server, the SSL in your browser only warns you when you encounter a new CA (Certificate Authority).
For the browser to behave more like SSH, it would have to maintain a list of individual sites which you have accepted as genuine. Then if you get a phishing email asking you to click a fake link such as https://lo0m.cc, you will get a warning even if the lo0m.cc site has a certificate "verified by Equifax" or whomever. This is a good example of where the current SSL protocol utterly fails.
When you visit the real loom.cc site which you originally trusted, you should see a happy warm reassurance in the browser bar, maybe including a pet name or avatar. But when you visit lo0m.cc, you should see the entire browser framed in red with a warning that this is the first time you have ever visited this site and you could be the victim of a phishing expedition. Something like that. I'm hand-waving a bit now. And it may get annoying for people at first, as they establish trust in their first 20 banking, gaming, or social networking sites. Kind of like installing a new CA root 20 times right? You don't want it to be too easy or people might just "click through" unconsciously. But personally I don't find this to be a great difficulty with SSH.
Indeed the building blocks are all there in SSL, namely (1) the verification of digital signatures, and (2) the negotiation of a symmetric encryption key. Some may carp about the protocol or the code being a mess, but as a black box it works just fine.
I think browser writers could phight phishing more effectively by thinking outside the box of implicit trust in central authority.
That is precisely why I criticize SSL. One of the primary goals of SSL is to authenticate a site so that Grandma can rest assured she is not being scammed. "Phishing" represents a catastrophically expensive failure to achieve that goal.
Trusted root CAs have "verified" millions of SSL certificates to one degree or another, from simple checks for ___domain control all the way up to brick and mortar audits. The problem is, any one of those millions of certificates can be used to phish customers of building-and-loan.com and steal massive amounts of their money.
A scammer simply sends Grandma an official looking email saying "We have recently received a request to wire money out of your Building and Loan account. Please log in here to confirm or deny this request. This extra level of precaution is for your safety. Sincerely, [insert signature of CEO here]."
Now when Grandma clicks the link, she is taken to an SSL-protected site called "building-and-loan-confirmation.com", which to Grandma's delight and comfort is "verified by Equifax". This misplaced trust costs Grandma $25,700.
I am thinking the very least browser writers can do is give Grandma a simple way to "confirm" a site which she has visited. Once she has confirmed it, and maybe given it a "pet name", her browser will display an especially reassuring theme any time she visits that site again (e.g. green border, friendly picture, familiar name, whatever).
Grandma still needs to know that she should only log in when she sees that reassuring theme. Any time she visits a non-confirmed site, she will only see a plain looking neutral theme. (Note: NOT alarming red, because then she'd be see red constantly as she browses around. Just neutral.)
Note that the suggestion I just made actually has nothing to do with SSL. Keep in mind that a phisher could easily send Grandma an unsecured link in an email -- no HTTPs at all. If Grandma clicks that link, she will only see a neutral theme, and if she remembers her lesson, she will NOT log in because she does not see the reassuring theme.
Of course, you could also say that Grandma should remember this lesson: don't click links in emails. Only visit sites by (1) typing in the name yourself or (2) using a bookmark. But I'm just trying to suggest a way to help Grandma after she has forgotten that primary lesson.
Here's another idea. You know how Firefox remembers passphrases for you, protected by a master security passphrase. That could help here. If Grandma visits the real building-and-loan.com site, her user name and password will be filled out for her automatically. If she visits a phishing site, it won't. That is another "hook" where browser writers might do something to help dear Grandma protect her property from predators. Something along the lines of: "This site is asking you to log in, but you have never logged into this site before. Are you sure you want to do this?"
Yeah, but you can't remove all the CA certs from your users' browsers, which is the issue. www.bank-of-america.ru will not display anything out of the ordinary to real users.
IMHO, OpenPGP did it right. And there is an effort to use OpenPGP to authenticate hosts and users on the web. It already works for SSH: http://web.monkeysphere.info
That's a great concept which I need to try. The challenge will be extending it to SSL and making it friendly to Grandma.
That said, when Grandma first signed up at building-and-loan.com, she probably went to the correct site. Now that she has trusted that site, she won't be fooled by phishing sites asking her to enter her building-and-loan.com password. Her browser will play a message from Wilford Brimley warning her about the new site.
Of course when she first went to the building-and-loan.com site, she also got the warning from Wilford Brimley, which might have alarmed her. I suppose the warning would have to say "If you are signing up at this site for the first time, just make sure you came here by clicking a link that you trust." Grandma then thinks "well gee, I just clicked here from the Association for Golden Girls web site, so I should be fine."
I welcome your suggestions on how browsers can help protect Grandma from the phishing on the computer she already uses.
Using someone else's computer for secure access is always problematic, for reasons far deeper than we're discussing. I will think more on what happens when changing computers though. I don't think the "initial intercept" you're talking about is as dangerous as you suggest. If Grandma gets a brand new computer and types in "building-and-loan.com", she'll reach the correct site. She will trust it once on her new computer and forever after be invulnerable to phishing attacks for that site. That is the ongoing, routine, every day, incredibly expensive problem I want to see solved, not the relatively remote possibility that she'll type "building-and-loan.ru" on a brand spanking new computer.
"That said, when Grandma first signed up at building-and-loan.com, she probably went to the correct site."
When I first followed this thread, I had this same thought. And it's true for this scenario. Maybe it's even true for most bank customers.
But it does depend on that scenario, a user typing in the address on her own. What gave me doubt was an equally (more?) likely scenario, clicking on an affiliate link. People trust links, and most probably don't look at their status bar on hover.
Huh? Since when does a CA need your private key/passphrase? Any time I've gotten a commercial certificate, I've only had to provide a Certificate Signing Request (CSR). Ahh, it seems the author didn't follow all of the instructions on the page he referenced (http://www.h-online.com/security/features/SSL-for-free-step-...):
'After that, StartSSL kindly offers to generate a pair of keys for the certificate. However, since the private key for protecting one's own server should never be given away or generated by someone else, the "Skip" option should be chosen and the Certificate Signing Request generated earlier should be uploaded onto the server.'
This is a bit creepy. StartSSL is providing a "free" certificate using a process where they also generate the private key & passphrase (unless you're smart enough to realize what a terrible idea this is). That's like the hardware store keeping a copy of every key they cut.
This is a great service as it allows me to setup secure IMAP, SMTP, Jabber, etc. without having to pay a third party money for this extra security, and without having to bother my users with installing my self-signed root certificate (StartSSL’s certificate is known to OS X and browsers except IE and Opera).
I don’t see how free class 1 certificates help scammers, phishers, and similar.
It seems they are now supported by IE judging from this page http://www.startssl.com/?app=40 which show icons of all the major browsers incl. IE but excl. Opera, and this page http://www.startssl.com/?app=22 which has the following text redacted (overstrike): Startcom’s certificate isn’t trusted by the Microsoft Internet Explorer.
So I think that it is now supported by IE, question is, which version of IE and/or Windows. I can’t find any details about this on the StartSSL’s pages (there used to be a FAQ entry iirc with browsers supported which included version and OS).
It is known to more recent versions of IE, IE8 if I remember correctly? I'm using StartSSL on my service because my users are iPhone developers and you need a Mac for that.
I tried to get a certificate for my own ___domain name, but I was not allowed to create an account "pending verification". So really, maybe this is not as easy as the article suggests.
I ran into the same problem when I first used StartSSL a few months ago. It seemed like there were some cases where automatic verification would work and other cases where verification was deferred to a human. I believe StartSSL is a small, possibly one man, operation, so you might have to wait a few hours for human verification. Once my account was verified, everything after that was pretty easy and quick.
