Certificate Authority provides free certificates
disog.org
disog.org
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.
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)
* 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).
What about that?
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.
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?"
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."
* overtly exposed to attackers because no key has been remembered, or
* at the mercy of whoever used the machine before her.
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.
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.
So basically that's the same that's CAcert.org has been doing - providing people the free alternative to expensive ones.
'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.
That is a deal killer..
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).