Extended Validation SSL, More Secure or Just a Racket?

Nalfeshnee writes "The Register is reporting on the new 'Extended Validation SSL' cert currently being touted by Verisign. Vista and IE7 will be using this but not, apparently, Firefox anytime soon. For this the Verisign Product Marketing Director Tim Callan squarely blames the Firefox dev team for 'not keeping up' with their new technology. However, the whole thing just seems to be a way for Verisign to enjoy ridiculous markup on selling 'more secure' certs."

Comments

Color coded?

[eric76]

Verisign say 99 per cent of sites will be get the "ok" and the address bar left white. Only outfits which fork out for an extended validation SSL will get the psychological filip of "green for go". Firms will have to stump up about 150 per cent of what they currently do for an SSL certificate.

I'm colorblind. Would I ever notice the difference?

Re:Color coded?

[Anonymous Coward]

Yes. Look at the screenshots and you'll see the organization name appears at the right of the address bar.

Re:Color coded?

[Zeinfeld]

I'm colorblind. Would I ever notice the difference?

yes, Microsoft has thought of that one, there are other, non colour cues.

Re:Color coded?

[interiot]

Don't worry. Once consumers realize that the new "super duper" certs are being given out to phishers as well, Verisign will come out with a 3rd level of verification ("extra super duper certificates") that cost 50% more, and they'll have to go to a numbering or lettering scheme ("1", "2", "3"). This will also facilitate the periodic addition of new levels whenever consumers realize Verisign still isn't doing the job they say they're getting paid to do.

Re:Color coded?

[midnighttoadstool]

Most color blind people are read/green colour blind, which only requires using distinct shades of red and green to cater for. Which kind of colour blindness have you?

Re:Color coded?

[Anonymous Coward]

I'm red-green colorblind. I also have trouble (so I've heard) with various shades of orange and brown. And the shades of red, green, orange, and brown that cater to me may not cater to someone else.

Here's an idea: rather than monkey around with shades of colors that are the most popular for colorblindness, why not use the colors that the greatest number can see. Hint: it isn't red/green.

Re:Color coded?

[Anonymous Coward]

Here's an idea: rather than monkey around with shades of colors that are the most popular for colorblindness, why not use the colors that the greatest number can see. Hint: it isn't red/green.

First, someone else said that they also use a different iconic representation, so you're not totally left out.

But to your point: you've said a number of shades that don't work. (And I admit it - I use red/yellow/green color-coding sometimes, although only in apps where I know the existing user population has no color-blind people.) What would you recommend instead? Something that many people can see, and ideally something colors that people associate with "bad", "neutral" and "good".

Re:Color coded?

[Anonymous Coward]

Who among the general public will even know what the difference is? Most of the sites I go to have white, but this one is green? oh-oh, better watch out, why is it different?

http://www.fbsolawyer.com/

Re:Color coded?

[yarbo]

black/gray/white

Re:Color coded?

[Anonymous Coward]

black/gray/white

Interesting idea, but it couldn't be used in quite the same way they did it - they used these colors as the background for the whole text box. You wouldn't be able to read the text with those three shades...

Secure?

[Kazrath]

Has anyone found an effective way of cracking regular SSL? Is not the whole point of SSL to just slow down the decryption to a point where even if decrypted the data is old enough to be useless?

I mean hell if SSL is weak encryption and we need stronger encryption should I not SUE verisign right now for providing a false sense of saftey?

Re:Secure?

[Anonymous Coward]

This isn't about the encryption itself, it's about identity. Certificates are not used for encryption, they are used for identifying a communications partner. The way this is done uses cryptography, but the actual connection is encrypted by a different process and with different keys than the ones from the certificate.

A certificate is a way of proving who you are by proving that someone whom the other person trusts has verified that you are who you say you are. There are two ways of attacking this concept: You can break the cryptography which is used in that process or you can get a certificate which says you are someone else by pretending to the trusted third that you are someone else. Extended Validation is a (misguided) attempt at preventing attacks of the latter kind. The only job of a CA is to verify identities. If a CA can't guarantee identities, the CA's certificate should no longer be trusted. Instead, EV adds "super trusted" certificates and leaves insufficiently checked identities in the trust hierarchy.

Re:Secure?

[Jahz]

Has anyone found an effective way of cracking regular SSL? Is not the whole point of SSL to just slow down the decryption to a point where even if decrypted the data is old enough to be useless?

I mean hell if SSL is weak encryption and we need stronger encryption should I not SUE verisign right now for providing a false sense of saftey?

1. You have clearly not read the article, or even the entire /. summary.
2. Who is talking about cracking SSL? Nobody... the underlying algorithm algorithms can be changed.
3. You should not sue VeriSign because they did not invent AES or 3DES or the SSL spec. Nor did VeriSign encrypt the data you get when using SSL. All they do is "guarantee" that the certificate you recieve is from a website belongs to that website and only that website. They basically sign certificates with their own super-secret private key.

You really should figure out what you're talking about before writing garbage like this.

Re:Secure?

[cortana]

If you read their terms of service you will see that they "guarantee" sweet fuck all.

On a related note, I was doing some poking around the other day and noticed this:

$ certtool -i < /etc/ssl/certs/Verisign_Class_1_Public_Primary_Cer tification_Authority.pem
 
X.509 certificate info:
 
Version: 1
Serial Number (hex): 00:CD:BA:7F:56:F0:DF:E4:BC:54:FE:22:AC:B3:72:AA:55
Subject: C=US,O=VeriSign\, Inc.,OU=Class 1 Public Primary Certification Authority
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 1 Public Primary Certification Authority
Signature Algorithm: RSA-MD2
Warning: certificate uses a broken signature algorithm that can be forged.
Validity:
        Not Before: Mon Jan 29 00:00:00 1996
        Not After: Wed Aug 2 00:59:59 2028
Subject Public Key Info:
        Public Key Algorithm: RSA (1024 bits)
modulus:
        e5:19:bf:6d:a3:56:61:2d:99:48:71:f6:67:de:b9:
        8d:eb:b7:9e:86:80:0a:91:0e:fa:38:25:af:46:88:
        82:e5:73:a8:a0:9b:24:5d:0d:1f:cc:65:6e:0c:b0:
        d0:56:84:18:87:9a:06:9b:10:a1:73:df:b4:58:39:
        6b:6e:c1:f6:15:d5:a8:a8:3f:aa:12:06:8d:31:ac:
        7f:b0:34:d7:8f:34:67:88:09:cd:14:11:e2:4e:45:
        56:69:1f:78:02:80:da:dc:47:91:29:bb:36:c9:63:
        5c:c5:e0:d7:2d:87:7b:a1:b7:32:b0:7b:30:ba:2a:
        2f:31:aa:ee:a3:67:da:db:
public exponent:
        01:00:01:
 
Other information:
        MD5 Fingerprint: 97:60:E8:57:5F:D3:50:47:E5:43:0C:94:36:8A:B0:62
          SHA1 Fingerprint: 90:AE:A2:69:85:FF:14:80:4C:43:49:52:EC:E9:60:84:77 :AF:55:6F
        Public Key ID: 79:6F:71:F0:F5:FD:FF:F7:50:86:F5:B6:5F:5B:D7:CD:7F :C0:A0:CD
 
-----BEGIN CERTIFICATE-----
MIICPTCCAaYCEQDNun9W8N/kvFT+Iqyz cqpVMA0GCSqGSIb3DQEBAgUAMF8xCzAJ
BgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xh
    c3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dG hvcml0eTAeFw05
NjAxMjkwMDAwMDBaFw0yODA4MDEyMzU5NT laMF8xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbi wgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJp
bW FyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG 9w0BAQEFAAOB
jQAwgYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3 noaACpEO+jglr0aIguVzqKCbJF0N
H8xlbgyw0FaEGIeaBpsQ oXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR
4k5F VmkfeAKA2txHkSm7NsljXMXg1y2He6G3MrB7MLoqLzGq7qNn2t sCAwEAATAN
BgkqhkiG9w0BAQIFAAOBgQBMP7iLxmjf7kMzDl 3ppssHhE16M/+SG/Q2rdiVIjZo
EWx8QszznC7EBz8UsA9P/5 CSdvnivErpj82ggAr3xSnxgiJduLHdgSOjeyUVRjB5
FvjqBU uUfx3CHMjjt/QQQDwTw18fU+hI5Ia0e6E1sHslurjTjqs/OJ0A NACY89Fx
lA==
-----END CERTIFICATE-----

Three things to be concerned about:

  1. It's only a 1024 bit RSA key. That is weak by today's standards.
  2. The signature algorithm is 'RSA-MD2'.
  3. Attacks against this certificate may only be theoretical today, but Verisign foresaw this, and saw fit to mark the certificate as valid until 2028!

Thank you, Verisign!

Re:Secure?

[tyler_larson]

Has anyone found an effective way of cracking regular SSL?

No.

Is not the whole point of SSL to just slow down the decryption to a point where even if decrypted the data is old enough to be useless?

No.

I mean hell if SSL is weak encryption and we need stronger encryption should I not SUE verisign right now for providing a false sense of saftey?

No.

SSL (and TLS) aren't encryption algorithms, they're protocol standards. These protocols make use of existing encryption algorithms to secure data. Many of these algorithms have a variable level of complexity, depending on things like key size. Since security (including encyrption) is always a tradeoff of resources versus security, the goal is to tweak the configuration parameters (again, such as key length) to find a level of security such that an attack against the cipher is less profitable an option than the next best choice, such as kidnapping the document's author. Those who require greater security can use turn up the complexity at the expense of using more resources.

As computation capability increases, the complexity of encryption system is increased to compensate, usually by increasing key length. If a flaw is discovered in a given encryption algorithm making it too easy to break, or if the algorithm isn't capable of being expanded to account for better decryption technology (such as DES) then that algorithm is discarded in favor of some stronger replacement. SSL remains the same.

Verisign's "Extended Validation" program has nothing to do with cipher strength, key length, or encryption. Instead, it's indicative of the vetting process that the company had to undergo to get the certificate. To get a certificate for citibank.net, I have to verify that I own that domain. I don't, necessarily, have to verify that I represent Citibank [1]. Under this High Assurance program, Verisign will vouch, not only for the validity of the domain, but also for the validity of the organization owning that domain.

This is a Good Thing, since there currently is only one tier of validation. An SSL certificate is designed to prevent man-in-the-middle attacks, which it does well. What it doesn't protect against (though we act as if it does) is forged identity attacks. Certificates used for financial transactions, for example, should go through a stronger vetting process than certificates used for securing a blog.

[1] In reality, almost all CAs do extended verification when the other party sounds like a high-profile company or financial institution. Nonetheless, Mistakes do happen.

Re:Secure?

[Anonymous Coward]

Thanks for that post. When I read the summary I was immediately feeling very cynical that this would be another MS conspiracy and marketing fluff. I agree 100% with your post. This sounds like a good thing for financial institutions. Now why can't Firefox support this? I would rather not be forced to use IE to connect to an online banking site. I suppose if I did find myself in that situation, then I'd install a VMware based XP virtual machine solely for that purpose and nothing else.

Re:Secure?

[silas_moeckel]

Actually all you need to do to get a cert is sign a piece of paper saying you will do all the checks and take the risk and they you can get a trusted cert for anything. Well you also need a valid D&B number with some history on it (couple years). Last I checked I am supposed to be able to get these new certs with the same technical level of protection, just more paperwork to promise to have but never get checked. So this really just sounds like another scam and maybe setting the bar marginally higher.

Re:Secure?

[mophab]

I believe you should keep the certificates secure and make sure that, in the case of SSL certificates, the certificate holder is the owner of the domain and that is it. If you want information about a domain, Black List, White List, or more involved reputation, that should be a separate service. The certificate policies should only involve enough rules to make sure the private key is not compromised. There are already several reputation services as it is; the browsers should support displaying info from reputation services about domains that are authenticated via the existing SSL process.

Re:Secure?

[Jahz]

...snip certificate...
    1. It's only a 1024 bit RSA key. That is weak by today's standards.

You use of the word "weak" implies that 1024-bit RSA can be cracked. As of today, I know of no method to efficiently crack a 1024-bit RSA key generated by a strong RSA implementation. There was a big uproar in 2002 when a paper was published claiming that 1024-bit RSA could be cracked with about a billion dollars worth of computing hardware. Maybe by now the costs have come down... but 1024-bit keys are still widely (safely) used. Banks and critical systems (and my keys) are now 2048-bit, just to be on the safe side.

2. The signature algorithm is 'RSA-MD2'.

So what? That is the signature algorithm that VeriSign used to create that certificate. As such, it is ONLY used by YOU when YOU want to validate YOUR copy of the certificate. That certificate is self-signing, which means that it is used to validate itself. The signature on that certificate was encrypted with Verisigns private key. Your computer pulls VeriSigns public key from their servers and decodes the signature. Then your computer MD2 hashes the non-signature part of the X.509 cert. If the hash that your computer generated matches the decoded signature bit for bit, then the certificate is presumed valid. So you see: the MD2 is only used as a basic hash. The real security comes from RSA. Additionally that MD2 hash is not used to validate any other certificate that Verisign signs.

So you see, forging that X.509 root certificate would accomplish nothing. For one thing, you would need verisign's private key, which is heavily guarded. However the best part is that you would need to implant that certificate on other people's machines and then exploit something else (like DNS poisoning) before anything malicious can be done. If you can do all that, then there are worse security holes exposed and forged root certs are really not the problem.

3. Attacks against this certificate may only be theoretical today, but Verisign foresaw this, and saw fit to mark the certificate as valid until 2028!

This is common practice for all CA's. Check your other certificates... Most of the certs on my box are valid for at least 10 more years. They are valid for a long time because having them expire is a security risk. When your certs go bad, you need to get new ones. That process would be a security nightmare for the common user. Its better to just rely on software vendors to provide up-to-date keys with their products as X.500 currently does not have a key update system (at least not one that has been implemented). Note that your key was probably generated 11 years ago.

Re:Secure?

[Anonymous Coward]

the goal is to [...] find a level of security such that an attack against the cipher is less profitable an option than the next best choice, such as kidnapping the document's author.

You're not selling it! Say that to too many document's authors (e.g., people who pay with credit cards online) and they'll campaign against SSL. And I sure hope kidnapping the document's author isn't the next best choice. Cracking the webserver, dumpster-diving, and various social engineering attacks are probably nearer the top of the list.

Re:Secure?

[nihaopaul]

can they bug fix the https implementation?
currently you connected to the https server and establish the encryption
send encrypted request headers
pull encrypted website

notice your session is already encrypted before the headers are sent? ya now think about vhosting on one ip address

--
ff2 spell checker really helps, shame it have don't grammar checker

Re:Secure?

[TheSpoom]

GoDaddy High Assurance SSL.
Comodo Trusted SSL.
GeoTrust True BusinessID.

Business identity validation SSL certificates have been around for a long time. The only thing different about VeriSign's offering is that they're partnering with Microsoft to have the bar turn green if their more expensive cert is detected, to the disadvantage of all other SSL providers. This is an attempt by VeriSign to make it effectively necessary for businesses to use their cert so customers won't think that their site is insecure.

There's so much wrong with this attempt to gain a monopoly without adding anything of value to the market... but par for the course for VeriSign.

Re:Secure?

[Beryllium Sphere(tm)]

>the certificate holder is the owner of the domain and that is it.

That's not enough for the practical requirements. Unless certs are tied to the actual identity of the organization which the domain claims to represent, there will be losses from people giving their credit card number to amaozn.com.

Re:Secure?

[jZnat]

But the bar is yellow in all other browsers for secure, so a green bar will just confuse users, right?

Re:Secure?

[Antique Geekmeister]

Not cryptographically. The theft of certificates from poorly secured servers, however, seems to be pretty common: and since registering a throwaway domain that looks at first glance like that of a legitimate domain (such as www.register-paypal.com) to obscure the fact that it's a phishing site means that the certificate itself is not very useful to prove that a site is legitimate.

SSL really needs to be thought of as only an encryption technology, not an authentication technology. The keys have never been managed well enough, and by now never will be managed well enough, to rely on them for authentication of servers. Too many people simply see that a key is automatically accepted because some scammer bought a Verisign signature with no noticeable difficulty, and go ahead and log in.

Re:Secure?

[UnderCoverPenguin]

Secure? I think I see a potential loophole in the protocol. The client receives the server's cert directly from the server, then authenticates it using a copy of the CA cert installed in the browser.

However, in, say, an internet cafe, where the client PCs are controled by someone other than the user, the management could install their own CA cert in the browser and have a proxy server generate forged server certs to provide to the client, which will accept said forgery as the real cert because it is signed with the cafe's cert.

Re:Secure?

[bensch128]

Probably because Mozilla corp wants to see a stable spec first and then implement it instead of implementing a half-assed implementation and then forcing everyone else to use it because it's the de-facto standard.

I guess M$ never gets tired of playing their games.

Or maybe firefox just moves too slowly for thier own good.

Time will tell,
Ben

Re:Secure?

[Aqualung812]

It might for the 5-15% that use something other than IE. However, yellow will be confusing at first for most of the people that use something other than IE, since yellow when used everywhere else is a warning.

For example, what would you think if someone said, "Your project has been yellow-lighted!"

Re:Secure?

[Ciarang]

I'm not sure you can consider that a loophole. If you're using a compromised box, you're already compromised.

It's called "open source"

[truthsearch]

Hey Verisign, it's called "open source". If you'd like the feature added submit a patch and they'll consider it. Until then the people working on it will finish when they can. Thanks.

Re:It's called "open source"

[Zeinfeld]

Hey Verisign, it's called "open source". If you'd like the feature added submit a patch and they'll consider it. Until then the people working on it will finish when they can. Thanks.

The Register was putting word's into Tim's mouth. They are the ones who used the phrase 'dragging their heels', not Tim.

The Mozilla team have been part of the EV development process from the start.

The real issue is that IE7 is harder to change once released. So the different deployment strategies make sense.

Re:It's called "open source"

[mikiN]

IE7 is harder to change once released

Say again?

Since when has there been any difficulty changing IE once released?
It's just a matter of releasing eleventy-one quadruple bazillion 'security updates' until it is deemed 'just barely functional'...

Has any major IE update been anything else but the last major version with the last bazillion security patches rolled into it, then dotted with fresh new bloat, eyecandy and bugs?

Re:It's called "open source"

[jacksonj04]

IE6 actually got rid of Active Channels, making it a step forwards in browser technology.

Re:It's called "open source"

[1310nm]

Oh, you're just a "technoanarchist". Easy to marginalize and write off.

"loose collection of technoanarchists"

Why do I keep hearing FUD like this lately regarding OSS?

Re:It's called "open source"

[AEton]

See, this is why nobody likes the Open Source community: they're so mean and unapproachable.

Geez, you go and create *one* exciting new technology -- which, sure, only your company supports, but that's a feature! -- and instead of gratefully implementing it for you, those damn longhaired hippies expect you to do the work!

Hmpf.

I don't get it

[Lord Grey]

I had never heard of "Extended Validation SSL" so I went to Google. Among the hits was something from Thawte, so I went there. It turned out to be a FAQ. This FAQ contained such gems as:

4. Why is High Assurance/Extended Validation SSL being implemented?

Answer:

Improved online identity assurance, and improved browser representation of online identities, will empower users to better protect themselves against malicious and suspicious activity, which has gradually been eroding user confidence in digital security, including online shopping and banking. thawte's commitment to establishing and implementing High Assurance/Extended Validation SSL standards, and to being one of the first to offer compliant product lines, underscores our commitment to enabling a secure digital environment for all.

And:

6. What is the difference between High Assurance/Extended Validation/Enhanced Validation SSL certificates and existing SSL certificates?

Answer:

The online identity assurance process is intended to be more comprehensive and standardized across the entire industry. Whereas currently online identity assurance processes vary from CA to CA, the new standards/processes under discussion by the CA Browser Forum, will have to be adhered to by all CAs if they wish to offer High Assurance/Extended Validation SSL certificates. This will encourage greater confidence in CAs as well as the processes that are used to vet and issue digital certificates. thawte's commitment to establishing and implementing High Assurance/Extended Validation SSL standards, and to being one of the first to offer compliant product lines, underscores our commitment to enabling a secure digital environment for all.

Is it my imagination, or is this new Extended Validation SSL thing, in the end, just a bunch of paperwork? I may simply be missing the point. If someone can point to a better description of this thing that makes sense, please do so.

Re:I don't get it

[hardburn]

It may solve some problems, like having a few guys claiming to be from Microsoft showing up at VeriSign's offices and walking off with a signed SSL key for MS.

This is only one of the many major problems that SSL has, though. I don't see how this can address the problems of international domain names (where glyphs for certain characters can look the same, but aren't). I also doubt that it gives assurances about the security practices of the company (why would a cracker sniff a few credit cards at a time off the wire if they can break into a database and get hundreds of credit cards at once?).

Overall, this seems like a way to make the customer pay again for the CA's own bad practices.

Re:I don't get it

[skiflyer]

Overall, this seems like a way to make the customer pay again for the CA's own bad practices.

That pretty much sums up this garbage. This is what SSL is supposed to already be, but as anyone who has filed for an SSL certificate already knows the whole thing pretty much works as a handshake... you're who, yes, ok, credit card with that name please, great, here you go.

And what about this "standardized across the industry"... I bought an SSL certificate from a 3rd party because they're in the Firefox/Opera/IE default trust lists, and because they cost $40 a year instead of $400, is this really a new industry standard or is this just Verisign's way of artificially creating a new market now that there's too much competition?

Re:I don't get it

[Anonymous Coward]

I used to work at a certain SSL place, so here's what I could gather.

Right now to get a cert it's a phone call verification or something else that can be done remotely.

For High Assurance CAs, the issuer has to fly a person out to the physical site, take pictures of the site, go inside, take pictures of at least two(?) employees, get names of workers, get signatures, and so on. At least that was the idea last I heard.

Rather than a remote validation, which I guess is easier to forge and easier to issue a mistake to by accident, this requires in person validation and lots of other crap you can't do without actually going there and checking it out. You decide if it's worth it. If not seeing that "special green color" stops just a few customers from using your site, it probably is.

Re:I don't get it

[not-enough-info]

I went to verisign to get some facts direct. They have a "live chat" feature that pops up when you go to the faq.
According to their customer rep "Doreen", there's really nothing special about this.
What I got out of the chat session:

• The encryption is the same, or possibly the same, but probably not better.
  
• So far other CAs are not onboard with this (but "expected to follow suit" whoopee.)
  
• The only informational resources they give their people are the faq page and the MS blog.
  
• Doreen freely admits to knowing less about her own product than me, some interested schmuck.
  
• There aren't white papers available for me to peruse. (presumably because there's no actual new technology involved)
  

Now, I understand that this is pretty low on the totem pole, but still I think it's indicative enough to start throwing around some assumptions.

<assumptions style="raging">
From a technical standpoint, "High Assurance SSL" is functionally the same as vanilla SSL. The only difference is that for supported browsers, the cert holder and issuer will be visible in the URL address bar. (Oh, and you can toggle between them by clicking, whoopee.) The main draw is that it's "more visible!!!".

So functionally, if the FF devs want to counter this ridiculous load of crap, all they have to do is stick the plain old vanilla certs into the URL bar and maybe highlight weird characters to show phishing attempts. Certainly, a whole lot more paperwork isn't going to stop the phishers if they're going to the trouble of getting a cert anyways.
</assumptions>

Smells like a turd, looks like a turd.

Re:I don't get it

[ocbwilg]

Is it my imagination, or is this new Extended Validation SSL thing, in the end, just a bunch of paperwork? I may simply be missing the point. If someone can point to a better description of this thing that makes sense, please do so.

No, you've got it about right. The only difference is the amount of verification being done on the back end.

Realistically, the SSL Certificate has very little to do with the encryption. All it is saying is that "some organization presented us with this public encryption key, said that it was for this server/site/organization, and at the time that we tried to verify it this was true." So if you wanted to set up a phishing site, there's nothing really to prevent you from buying a cheap cert from one of the CAs that is trusted by default in IE, setting up a server with it, and going to town. To the average web user, the site will look "safe" to them because it shows a key/padlock to indicate that communications is encrypted, regardless of the fact that the encrypted communications could be going to a criminal's web server.

I have only bought certs from Thawte in the past (they're as good as Verisign I think, and half the price, though there are undoubtedly cheaper CAs), and Thawte has offered several levels of SSL certificates in the past. I was reading on their FAQ page the other day when trying to decide which cert I wanted for a mail server, and they basically explained the difference between some of their levels of certificates as being the amount of verification done on the back end. Some had a turnaround time of a few hours. Some took a couple of days. Presumably this is no different. I remember when my organization bought our first cert, it did take a couple days for them to verify everything. After that, subsequent certs from the same domain name and admin mailbox/technical contact/admin contact went through much faster. Apparently because they know us now.

For my money, it doesn't really make a difference. If you're going to "Bob's Sneaker Store" online, it probably doesn't matter to you if Verisign did a 3 day audit to verify their identity because you don't know who "Bob" is anyway. If you're going to a Microsoft/Cisco/other major company web site, the degree of validation being done on the back end might make you feel safer, since you may already predisposed to trust that company more than some anonymous web merchant.

Re:I don't get it

[Beryllium Sphere(tm)]

They're not doing that for the "extra 50%" price mentioned in the article. They're either doing much less or charging much more.

Re:I don't get it

[Antique Geekmeister]

Either way, the certificates will remain easy to steal due to the poor system security of many websites. Having an expensive Verisign certificate with extra special verification, at 3 times the price, does no good if some cracker has a rootkit on your sales-people's machines and succeeds in ripping the certificates out of your improperly secured webserver that they had access to because they push changes to it regularly, or have access to the backup system to pull the keys off the backup tapes, or there's a known exploit in IIS that hasn't been addressed yet on a production server, etc., etc. It's especially bad if they steal an SSL key with key-signing permissions such as many large corporations require, in which case they can play all sorts of interesting games.

Expect SSL keys for defunct companies and domains to also increase in value, as the old domains can be purchased trivially and their old SSL keys used for all sorts of abuse. Given the growth right now in the web market, I'd expect to see another dot-bomb happen within 3 years and free up a lot of those.

Re:I don't get it

[trifish]

Just FYI, if you steal a certificate from say www.ebay.com and use it on www.e-day.com (or whatever), you'll get a warning from the browser that the certificate is potentially insecure (the domain name doesn't match).

Re:I don't get it

[trifish]

That pretty much sums up this garbage. This is what SSL is supposed to already be

Actually, no.

SSL certificates can have various purposes. The purposes for which a certificate is issued is stated in the certificate (see the "Properties" of the certificate in your browser). The purpose of the cheap site/domain certificate is the following (and I quote from the certificate info):
'Ensures the identity of a remote computer.'

Nothing more, nothing less.

Re:I don't get it

[skiflyer]

Excuse me for my loose wording, I assumed an audience familiar with the article, this is what SSL Certificates signed by Verisign and similar companies are already supposed to be.

Re:I don't get it

[julesh]

Well, yes, but you'd use it in combination with another kind of attack (e.g. DNS poisoning) to redirect people to your servers when they enter the correct domain name. Yes, it's harder than traditional phishing techniques, but I suspect it would be a lot more effective.

Re:I don't get it

[trifish]

Two rather difficult attacks would have to succeed at once. Not very probable. Maybe one, but not two.

They SHOULD be doing this for everyone...

[dolphinling]

I think I remember reading about this either on firefox dev blogs or mailinglists or IRC. IIRC, the upshot was that verisign should be doing "extended validation" type things on all their clients. The validation they have now is really pretty shoddy, shoddy enough that they'd be risking getting kicked out if they weren't so big and so many websites would break. But that's just my memory, which could be bad, you'd have to look into it yourself.

Racket

[AKAImBatman]

More Secure or Just a Racket?

Definitely sounds like a racket to me. If you get the green bar by paying Verisign 150%, how does that differ from today's security certificates? Other than having to pay more money, and only being able to be verified by Verisign, that is. (Doesn't sound racket-y at all. Or was that rickety?) While they make it sound like the Green Bar is an excellent method of knowing that Amazon is really Amazon, I think it's actually a reverse attempt. By getting Amazon to use this spiffy new green bar, Verisign is attempting to legitimize their new technology in the eyes of the consumer. Little will actually change for the consumer, as he already knows when he's surfing Amazon.

The only place it would supposedly help is with Phishing. But since Phishing sites can't get certificates anyway, what does this help? If the lock isn't good enough, just change the URL Bar green for every VERIFIED certificate received. That will have the EXACT same effect.

Re:Racket

[CerebusUS]

But since Phishing sites can't get certificates anyway, what does this help?

Actually, I don't think phishing sites have much trouble getting certs. Several SSL providers merely check that you own the domain the cert is registered to. If I'm the registrant of amaz0n.com, I'll approve the ssl purchase and have a cert. It tells you absolutely nothing about whether you can trust the person running the website you've connected to.

I'm guessing this is going to end up a lot like the "Made for Windows" certifications where each SSL vendor will be required to meet certain criteria before being able to offer these new certs.

It might work, but I'm guessing it won't really help.

Not firefox supported.

[lordShiva]

It just seems funny with the release of 2.0 and now here verisign is blaming the dev team at mozilla. Kind of odd you know fox or verisign didn't speak more closely.

Riiight.

[TubeSteak]

The padlock encryption symbol used by browsers has been effectively meaningless for some time, and consumer paranoia surrounding fraud remains a barrier to using online commerce for many.

In response, the verification industry in the form of the CA browser forum has come up with extended validation SSL, where the certificate really is a guarantee of kosher status. Honest.

Thank you The Register for saying what I was thinking.

Re:Riiight.

[Midnight Thunder]

The padlock encryption symbol used by browsers has been effectively meaningless for some time, and consumer paranoia surrounding fraud remains a barrier to using online commerce for many.

Silly us, we should haver been using two padlock symbols the whole time.

Re:STOP THE PRESS! ORACLE LINUX IS HERE!

[AKAImBatman]

1. That a commitment to Linux, not their own distro.

2. The story was already posted here.

Now go troll somewhere else.

Charging more to do what they should be doing.

[datajack]

The online identity assurance process is intended to be more comprehensive and standardized across the entire industry. Whereas currently online identity assurance processes vary from CA to CA, the new standards/processes under discussion by the CA Browser Forum, will have to be adhered to by all CAs if they wish to offer High Assurance/Extended Validation SSL certificates. This will encourage greater confidence in CAs as well as the processes that are used to vet and issue digital certificates. thawte's commitment to establishing and implementing High Assurance/Extended Validation SSL standards, and to being one of the first to offer compliant product lines, underscores our commitment to enabling a secure digital environment for all.

Err, excuse me.. isn't the verification of the identity of the applicant of the certificate exactly what the CAs are meant to be doing anyway?

I thought that that is why we had these 'trusted' third-parties, to vouch for the identity of the certificate owner - that is the fundamental basis of PKI and certificates. If they weren't doing that before (which they clearly weren't doing properly), what the hell were they doing?

So, we're paying them extra to get a 'fixed' version of something that they caused to be broken in the first place because they couldn't do their job properly. WHy should paying an extra 50% on top of their fees all of a sudden make us able to trust them now?

Re:Charging more to do what they should be doing.

[Anonymous Crowhead]

WHy should paying an extra 50% on top of their fees all of a sudden make us able to trust them now?

Because they want more money?

Re:Charging more to do what they should be doing.

[skiflyer]

Couldn't agree more, posted a similar concept a little higher up... but reading it in your words makes me wonder, is there a class action lawsuit in the near future for standard SSL users?

Re:Charging more to do what they should be doing.

[RAMMS EIN]

``Err, excuse me.. isn't the verification of the identity of the applicant of the certificate exactly what the CAs are meant to be doing anyway?''

Yes. And the fact that there is apparently a need for "more comprehensive" identity checking means Verisign haven't been doing their jobs.

``If they weren't doing that before (which they clearly weren't doing properly), what the hell were they doing?''

Playing monopolist. Charging ridiculous amounts of money for simple records in databases. Claiming to run a trustworthy authentication service. Answering queries for non-existant domain names with addresses of their own services. Generally running the DNS root servers in such a way that various alternatives have sprang up to correct their missteps. Probably filing the odd lawsuit and patent or two.

``WHy should paying an extra 50% on top of their fees all of a sudden make us able to trust them now?''

It shouldn't. They've wasted the trust that was put in them. We should abandon them, turn to alternatives, and try not to make the same mistakes again.

Re:Charging more to do what they should be doing.

[mod_critical]

What were the doing? Verifying identities of course! By means of making you enter a phone number and then enter the code on the screen when it's called, or making you scan and email a utility bill! YES! These are actually two different methods I've used buying certs before.

So you are indeed correct, there has been no reason to trust a cert before, but they haven't actually fixed anything either ;)

So the verification is crap, but who cares, Joe User never checks the certs anyway, and probably dosen't notice the padlock. In fact, Joe User (in my experience) will not check the cert, check the sitename, click the seal, and check the URL to make sure the verification page came from a CA. If Joe knows what a CA is ... or dosen't just jump under the desk and cry when he sees the cert's fingerprint presented to him in hex pairs after clicking the padlock.

Okay, so Joe dosen't know how to verify a site and dosen't give a rip, but who cares, no matter how well you can verify your own identity, someone can still impersonate you well enough to reel in the suckers.

Trusted third party identification only works if that trusted third party can identify EVERYONE, not just those who have opted for identification. The security companies probably all know this, but the current method hasn't exausted it's power to generate income.

The only way for trusted third party identification to actually work is to be able to identify every site within the browser's scope. Since verification is opt-in, then the only remaining way to do this is to limit the scope of the browser. Example: and this is a quick idea, it probably could be improved quite a bit, but for starters: Have a browser button to turn on secure browsing mode, and with it on you cannot visit any unidentified site. Across the top of every page you visit there is about a 100px tall banner displaying the legal name and address of the verified site owner. That is something Joe can understand.

Re:Charging more to do what they should be doing.

[Lord Ender]

It sounds to me like you all have it wrong.

No CA can be 100% sure you are who you say you are. But there are things they can do to increase their confidence in your identity. Doing these things costs more money of them (and so, of you, the SSL site owner).

It sounds like Verisign wants to use color codes to demonstrate SSL site users how confident Verisign is in the identitiy of the certificate holder.

I think this is a fantastic idea.

Re:Charging more to do what they should be doing.

[eraserewind]

Well, this is true, but don't most people don't treat the cert as anything other than an indication that the connection is encrypted? I mean, you could just put your self generated cert on your site, and most people would click "accept this cert permanently" just like they do when e.g. hotmail or other sites sometimes have the same problem.

If browsers prominently displayed

"Firefox considers Verisign reliable (ha!), and Verisign certifies that this site belongs to 'Joe Bloggs, 123 main St, sslville'"

or

"you yourself have decided to believe that this site belongs to 'J03 B100g5, 123 main st, fishtown', but firefox doesn't vouch for them in any way."

for every site, then there might be some point to it.

Re:Charging more to do what they should be doing.

[Kanasta]

just like how etrust merely certifies that the site has a privacy policy are not that it is good

I would guess that currently Verisign certificates merely verify that the site has an identity, not necessarily that it is who think it is...

Next I would propose a certification for certification companies to certify that they actually certify their certificates...

Re:Charging more to do what they should be doing.

[XorNand]

I remember years ago when NSI/Verisign was the only game in town and certs cost $300+. It was a *royal* PIA to buy one. It generally entailed several phone conversations with an account rep, faxing them reams of documentation verifying business identity.

When other CAs got into the game, the increased competition drove down the prices of the certs. Since Verisign wasn't making as much money on them, they couldn't afford the same level of verification and still expect to compete. Eventually the whole process became web-based and more streamlined (or less intensive, depending on how you look at it).

The reason this happened it because buyers' #1 concern (beyond is browser/server compatibility) is price. If Internet consumers would put more pressure on website owners to use certs from reputible CA's and demand a more through verification, both prices and levels of verification would increase again. Of course consumers don't demand this due to ignorance of 'net security. However, this is slowly changing as the technology matures and increased media exposure of identity theft, worms, etc.

This latest Verisign product is probably just a response to that upswing in market demand. However, IMHO, it's probably slightly ahead of its time to be a success. I doubt it's the conspiracy some /.er's are making it out to be though.

Re:Charging more to do what they should be doing.

[Burz]

Yes. And the fact that there is apparently a need for "more comprehensive" identity checking means Verisign haven't been doing their jobs.

Verisign suffered a blow to their credibility a couple years back when it was discovered they were handing out certs to phishers. This new "technology" looks like a ploy for them to repair their reputation by giving them the opportunity to slag everyone else who does not adopt their new scheme; And in Mozilla they found a juicy target.

I'm sure MS is happy to go along with it, seeing how its own reputation vis-a-vis phishing and general security is worse than Verisign's.

Re:Charging more to do what they should be doing.

[Chief Camel Breeder]

Right now, all they offer to validate is that the applicant for the certificate owns the domain to which the certificate applies. If a business, e.g. a bank, fails to buy up all the domains that could be mistaken for the bank's proper domain then I, were I a fraudster, could buy that domain and get a certificate. E.g., I might try to get citybank.com if I wanted to phish for citibank.com customers. The fact that I can do this doesn't mean that the certificate authority is negligent. They're correctly binding certificates to domains and only issuing to the domain owners. That's what they've always claimed to do.

The new kind of validation (I think) would eliminate this combination of domain squatting and certification for phishing attacks. It could be a reasonable approach for merchants if the validation is done well. However, many sites have accidentally-similar names, especially where the same organization initials have been used in different TLDs like .com and .net. In this case, neither organization would be able to get extended validation.

Are you really surprised?

[Rosco P. Coltrane]

So, a product is proposed by Verisign (the guys who tried to shove their shoddy SiteFinder search engine down your throat by abusing their monopoly) and Microsoft (the guys who have been shoving their shoddy DOS and Windows down your throat for decades by abusing their monopoly).

You know what? I'm quite sure it's a shoddy product they're trying to shove down people's throat for some reason...

Re:Are you really surprised?

[Anonymous Coward]

Not only that, but the PR guy...talk about pissing in the wind. Badmouthing any team that would lead to implementation of your proposed feature set is just stupid. To badmouth a fairly up there open source project, hell, that just invites the question why doesn't Verisign just put up the code themselves then instead of taking public swipes at the project?

I don't know if this is at all possible, but any competitor to Verisign that may exist with a similar but hopefully superior scheme could now undermind Verisign by working closely with and supporting the Firefox team.

more info

[Anonymous Coward]

Verisign used to call "Extended Validation SSL" "High Assurance SSL". A little more info here:

http://www.verisign.com/ssl/ssl-information-center /faq/high-assurance-ssl.html

This seems to be composed of two parts:

1. Some higher-level of SSL certificate for which Verisign will somehow verify the legitimacy of the company rather than just their domain, and for which they will presumably charge more $$$.
2. Visual indication in browsers that a site has such a certificate, and displaying who validated the certificate (i.e. Verisign.)

Re:more info

[DragonWriter]

So, Verisign realizest that their practices are insecure and broken, but instead of fixing their practices and being a good CA, they are instead creating a new kind of "we actually did our job" certificate that requires new code for browsers to recognize?

I mean, wouldn't it make more sense for Verisign to do the same thing (if they wanted to get some money for insecure certs but still have a more secure cert) to create a new Certification Authority name also run by Verisign that actually does their job, and not require any browser code changes? Or are they just afraid that if they did that, browser vendors might delist Verisign's main CA from their default list of trusted CA's, since that would be admitting that, well, basic Verisign certificates can't be trusted.

Seems to me this is an unnecessary technical change to a business practices problem at Verisign.

Re:more info

[ebyrob]

I mean, wouldn't it make more sense for Verisign to do the same thing (if they wanted to get some money for insecure certs but still have a more secure cert) to create a new Certification Authority name also run by Verisign that actually does their job, and not require any browser code changes?

But then how would you tell the old CA apart from the new CA? It isn't like your browser loudly proclaims which CA is validating a particular domain. Or are you suggesting they revoke their own current CA status?

Re:more info

[Anonymous Coward]

Or are you suggesting they revoke their own current CA status?

That's the idea, yes. A certificate says that the CA which issued the certificate has checked that the person or webserver which is named in the certificate is or belongs to the person to whom the certificate was issued. If the CA didn't really check that, because the supplicant didn't spring for the "extended validation", then the certificate should not be trusted. All information in a certificate must be verified. If a CA is known to put information in certificates without verifying the validity of the information, the only sane consequence is to delist the CA.

Browsers could react differently to certificates which certify just the server domain or the server domain and responsible person/company. Putting unvalidated information into certificates on the other hand is a big no-no and can not be tolerated by instituting "super trust" certificates.

Scam...

[tomstdenis]

This is coming from the people who stole DNS, and sell certificates for hundreds of dollars which take milliseconds to make....

Now we're supposed to get a more "trustworthy" cert and make our address bar green?

Fuck you Verisign.

Tom

Re:Scam...

[Anonymous Coward]

Posting AC since Apple Mail just decided to re-download 3492 emails.

This is why this is happening.


VeriSign - the company most known for using cartoons to trick 12 year old children into buying ring tone subscriptions trough paid spamming on MTV and youth oriented websites and for creating the phishing inspired SiteFinder now owns GeoTrust. Signature schemes (SSL, signed code) are now more fragile than ever since VeriSign, Thawte and GeoTrust is now VeriSign, VeriSign and VeriSign.

Re:Scam...

[trifish]

sell certificates for hundreds of dollars which take milliseconds to make....

To be fair, the price is not for the actual making of the certificate (that obviously costs them something close to zero). The fee is mainly for the financial liability which they undertake, and for the verification process. This involves making calls to verify the validity and authenticity of provided documents, etc. It should be something like a detective work. If they do the job, they deserve the money.

Anti-Phishing Technology will make it moot

[Anonymous Coward]

Nobody uses SSL to verify that a site is who they say it is - when was the last time 99% of users looked at a website's certificate?

SSL is still good for keeping the data encrypted between client and server. You don't need some super-duper certificate for that.

Anti-phishing blacklists will be what works well for end-users. Being told explicitly that they're on a dangerous website is far more effective than 'hmm, well the location bar is in green!'. They won't even look.

Re:Anti-Phishing Technology will make it moot

[cholasz]

I fail to see how a anti-phishing blacklist is going to solve the problem. Who is going to manage the blacklist? Am I supposed to trust any unlisted site with my credit card details even if the SSL cert they're using is self-signed and completely bogus?

Looks like two sides of the same problem. You have to have a system of managing trust (CA's) or distrust (blacklists), but either way you will be running into problems if the maintainer is not doing a proper job (either because of greed, incompetence, incompability, market constraints etc)

Yes.

[khasim]

IE 7 will have different icons on the location bar to indicate that a site has the "higher" level of "security" (translation: "bought the new certificate").

Re:Yes.

[sharkey]

Perhapsthe icon could be a person caught up in religious ecstasy drinking a cup of Flavor-Aid?

I'm going to guess

[tkrotchko]

I'm guessing the certificate security itself isn't changed. What they're saying is they're just going to do more research on a company before they hand out certificates. Right now you fill in a form, fax it in, and *presto* you get certs. Now, I guess someone will actually call and check before issuing.

They could do this now with regular SSL, but they couldn't charge more money... too much competition out there.

The thing is, the encryption of SSL is not at issue; it's just a new product to market.

Re:I'm going to guess

[Anonymous Coward]

They couldn't do this with SSL because the user wouldn't know if a certificate comes from a CA which has really checked the identity of the certified company. With Extended Validation, the certificate will contain the information that the CA actually checked, and standardization makes sure that nobody issues such a certificate without checking.

I don't think anybody believes that. It was the CA's job all along to verify the identity before certifying the identity. If the CAs can't do their job for the kind of money that they are asking, who thinks the CAs can and will do it for 150%?

A personal view from someone at Mozilla

[Anonymous Coward]

See this blog post from about a year ago on this topic.

Do disreputable sites get them?

[iabervon]

The only way to judge whether this is legitimate is to see whether sites that do fraudulent things (get traffic from mistyped domain names, send out "renewal" requests to non-customers, etc) are able to get these certificates. If Verisign is able to make sure that sites that do these things or have a history of doing them can't get certificates, then maybe they'll mean more than current SSL certificates.

Of course, there are technical issues with a PKI system without trusted root certificates, so it might not work even then.

Re:Do disreputable sites get them?

[Kelson]

The only way to judge whether this is legitimate is to see whether sites that do fraudulent things (get traffic from mistyped domain names, send out "renewal" requests to non-customers, etc) are able to get these certificates.

I think you're being too subtle for this site...

Re:Do disreputable sites get them?

[Sloppy]

SSL certs are about guaranteeing identities, not guaranteeing good behavior. Disreputable websites should be able to get these, they just shouldn't be able to represent themselves as someone they're not.

Re:Do disreputable sites get them?

[Beryllium Sphere(tm)]

>Of course, there are technical issues with a PKI system without trusted root certificates

This has always bugged me. It's bugged everyone who's thought about it analytically. Bruce Schneier went and investigated a little, and found interesting things.

Why do Verisign and others (check your browser's list, see how many names you recognize) get to decide who's been verified and who hasn't? Basically, because their certs are installed in the browser when it ships. Browser makers are supposed to check for audits before they list a CA as trusted.

But, as Schneier pointed out, what about the integrity of the browser's list of trusted CAs? Can someone sneak in a new CA cert? The answer is yes, and trivially so. That's how an "SSL proxy" works, a beastie that should have been impossible because SSL is supposed to make man-in-the-middle attacks impossible. See also MarketScore.

Not to mention the entire revocation fiasco. Checking revocation lists is usually off by default!

Ian Griggs and others have suggested making the CA more visible in the UI, so the user gets used to CA brand names and learns which ones do things like issuing certs to visa-security.com, paypa1.com, and other classics of phishing history.

Easier and more practical would be another popular suggestion, which is to make the UI work like ssh. Simply keep quiet unless and until amazon.com or etrade.com suddenly starts presenting a different public key.

If there's an alternative out there that doesn't have more holes than Swiss cheese I hope someone will post it.

Re:Do disreputable sites get them?

[iabervon]

Yeah, I ought to have included those links. Ah, well, at least a few people got the joke.

Uh, what was the middle choice again?

[Medievalist]

"More secure or just a racket?"

C'mon, ScuttleMonkey, are you trying to get a job as a pollster for Karl Rove?

"Would you be more likely or less likely to vote for John McCain for president if you knew he had fathered an illegitimate black child?"

All the brower teams and SSL CAs agreed to this

[miller60]

The article is, not surprisingly, VeriSign's version of events. The Extended Validation standard emerged from talks among a consortium of browser makers (the IE team, Mozilla, Opera and Konqueror) and a ghroup of SSL certificate authorities, which includes not only VeriSign but also geoTurst (since bought by VeriSign), Comodo, Entrust and Go Daddy. The group is known as the The CA/Browser Forum, the group of certificate authorities and browser developers that is working with the American Bar Association's Information Security Committee on finalizing an open standard for the validation process, which is to be followed by all participating CAs. So this isn't just a VeriSign issue, but the culmination of an 18-month process.

The plan was for all the browsers to implement the color bar scheme, based on IE's implementation. There were optimistic announcements by all involved, but no final standard has emerged. VeriSign and other SSL certificate authorities are preparing to start selling these in January. It's not clear to me if Firefox/Mozilla has actually opted out or is just moving more slowly than MSFT in incorporating the changes in the browser. Mozilla tends to be deliberate about SSL-related changes in the browser.

Re:All the brower teams and SSL CAs agreed to this

[Zeinfeld]

The article is, not surprisingly, VeriSign's version of events. The Extended Validation standard emerged from talks among a consortium of browser makers (the IE team, Mozilla, Opera and Konqueror) and a ghroup of SSL certificate authorities, which includes not only VeriSign but also geoTurst (since bought by VeriSign), Comodo, Entrust and Go Daddy.

No the article is the Register's version. Its hard to tell but there is actually a panel session on this at RSA Europe and the other vendors are on the panel.

Re:All the brower teams and SSL CAs agreed to this

[pvanheus]

An open standard for the validation process sounds like a really good thing. Who would police compliance with the process though? The reason I wonder about this is that if CAcert.org could adhere to some well known standard for validation, it would make its certificates much more believable.

Peter

Re:All the brower teams and SSL CAs agreed to this

[hitchgoat]

Ok, so what's the technical means by which a browser distinguishes an Extended Validation certificate from any other? Some sort of information associated with the root in your local store? A certificate policy OID present in the certification path? An extension in the CA or end-entity certificate? There has to be something, right? What prevents another SSL certificate vendor from simply including this indicator in their certificates, regardless of the registration procedures that they follow? I suppose if they did so they might get blacklisted by MS, which would be a pretty big blow to their business. SSL, when used for identify verification and not simply for confidentiality, really is the only way to defeat this type of scamming on the web. As everyone else has pointed out, the SSL certificate vendors have effectively nullified the value of SSL for identity verification by following weak registration procedures. It does make sense, given where we are now, to (a) continue allowing SSL for confidentiality without complicated registration, and to (b) offer some sort of enhanced service under which the SSL certificate vendors actually perform their due diligence. What remains to be seen is how effective they'll be.

Re:All the brower teams and SSL CAs agreed to this

[miller60]

I believe they're using a certificate extension. The proposed validation process would involve the applicant providing proof that they control the domain, proof of a bank account (whic by itself requires another layer of checks on the bank side), documentation that the applicant has authority to act on behalf of their company, and a site visit to confirm a physical address. The process is designed to be thorough enough to prevent spoofing. But then again, the standard hasn't been finalized either.

Re:All the brower teams and SSL CAs agreed to this

[ebyrob]

Mozilla tends to be deliberate about SSL-related changes in the browser.

Translation: MS is rushing something into IE before the standard is even set. Verisign wants to start charging for "Extended Validation" right away whether it actually meets the emerging standard well or not, and whether this has a positive effect on user security or not.

Turning an address bar green is a long ways from actually providing security to end-users. All parties involved in the standards process must know this by now. (Users need to be able to give and receive strong referrals as well as have a facility for locally mapping their own personal trust relationships to and from secure keys if there's any chance of stopping phish attacks. Knowledge about which CA signed a specific certificate can also be important, but probably shouldn't be all that important after initial referral and creation of a trust relationship.)

Microsoft trusting something != me trusting something

However I doubt Microsoft will ever truly get that concept. (This goes for a lot of large corporations, verisign included...)

Re:All the brower teams and SSL CAs agreed to this

[miller60]

That's all true. But in reality, Microsoft owns 85 percent of the browser market and VeriSign, having acquired GeoTrust, owns 70 percent of the SSL certificate market. If their only goal was to take advantage of their dominance, why even sit down with Kongueror, Firefox, etc? This effort sprung from a broader industry concern about phishing and unsophisticated users. The end users who know what they're doing and actually examine certificates don't need the green address bar. But the color coding may help a small number of users who would otherwise get taken for a ride by phishers. It's a slight improvement for the end users. And, yes, it's a sales opportunity for the CAs.

Spinal Tap Syndrome...

[pandrijeczko]

..."but our Verisign certificate goes up to 11!"

The new certificates are double plus super good.

[khasim]

#1. In order to issue the new certificates, the Certificate Authorities (CA's) will be "required" to follow "industry standard" practices in "verifying" whomever applies for a new certificate.

#2. This additional "verification" is what will cost the additional money.

#3. Any business that does not pay the additional fees to be "verified" by "industry standard" practices will be ... the same as they are today.

#4. Phishing depends upon a person making a single error in judgment, one time. This will not stop phishing.

This will not stop anything. This is stupid. You're paying EXTRA to have someone do the verification they were supposed to be doing already. Imagine trying to run a business like that.

Boss - "I paid you last week, but you barely did any work. I'm going to fire you."

Employee - "If you give me a 50% raise, I'll perform the work to industry standards."

Boss - "Okay, that sounds like a good deal to me."

What about this paragraph?

[skiflyer]

One snarl-up for Mozilla may have been working out an alternative to the rest of Microsoft's site-rating system. As well as getting dishing out green address bars, servers at Redmond will blacklist dodgy and suspect sites, which can look forward to red and amber flashing up.

I don't feel all paranoid about this, and I think the technology is a good concept, but dang, do we want any for profit company to be the one in charge of maintaining these lists? And what's the appeal process, if my online store got listed red or amber for even a couple weeks at the wrong time, that's a serious hit to my business. Now, like I said, I'm not really concerned that MS is going to go off and start red flagging sites they have a grudge against, I generally trust them, but do we even want to give any for-profit the temptation? (I wouldn't want to take this responsibility on as part of my company, I'd much rather start a specific organization for it which was completely transparent and accountable)

Re:What about this paragraph?

[indigest]

Don't worry. Chances are most users will ignore the address bar no matter what color it is.

racket?

[nosferatu-man]

Verison is involved.
Everything Verisign does is a racket.
Therefore, it's a racket.
Q.E.D.

Gaah! Please skip the revisionism.

[ScentCone]

shoving their shoddy DOS ... down your throat ... abusing their monopoly

Right! Because DOS was definitely the only O/S upon which big business was doing business, say, back in the 1980's.

And then there were those enormous numbers of consumers using DOS instead of Apple II machines or Ataris or Amigas... Shoved down their throats? Come on. If you're going to rant about MS market share, at least skip over the part when it was anything but a sure thing, before all of the other platform makers wheezed and missed the opportunity to take over the business desktop market (when they already owned the back office corporate computing market!) when it was anything but settled in one popular direction.

Certs are a joke

[rs79]

In a world where even PayPal can't get it right (and nobody cares) what does it matter?

"Oh, it's an https site. It's encrypted. Cool". Next.

Some time when you're really bored look at the low level ssl stuff (with openssl or something) and notice all the errors. The browsers ignore so many of these I think it's all a big joke.

Re:Certs are a joke

[Fulcrum of Evil]

In a world where even PayPal can't get it right (and nobody cares) what does it matter?

Aside from their lack of care with your money, paypal gets a lot right - all their communication refers to paypal.com, not somerandomurl.com like a lot of real banks do. This single thing is probably worth way more than any fancy SSL hokum.

Re:Certs are a joke

[rs79]

"paypal gets a lot right"

I have a screen shot on a computer around here someplace of a browser alert window pointing out the cert domain doesn't match the domain. It was about 2-3 years ago. I can't remember for sure but I think it was www.paypal.com (the cert) didn't match paypal.com (which is what I type in).

The points remain:
1) People don't care if the cert is valid or not or in many cases if it's even signed by a root auhority the browser knows about
2) There are lots of errors in certs the browsers ignore; if they didn't damn few, if any would work.

Re:Certs are a joke

[PhYrE2k2]

Microsoft's live Web site gets that all the time. https://postmaster.live.com/ is even under the wrong cert name.

-M

Where's the specification?

[Animats]

Has anyone actually been able to find the specification for "high assurance" certificates? Apparently this is being closely held. The spec comes from something called the "CA Browser Forum", which is invitation-only and doesn't seem to have a web site. A standard was supposed to be issued in August, but apparently agreement wasn't reached until a meeting in September. There are many press releases, but no hard data.

So that's why it's not in Mozilla.

It's actually a good idea. Early in the history of SSL, getting a certificate required presenting appropriate business identification info to the certificate issuer. The problem is that some issuers (GoDaddy comes to mind) started issuing "domain only" SSL certificates; the only verification is that the domain can get email. Then, instead of revoking GoDaddy's root certificate for this, the other cert issuers copied GoDaddy's approach. Now anybody can get a meaningless certificate with a meaningless Relying Party Agreement.

The way it's supposed to work is that the certificate issuer bears financial responsibility for misidentification of the certificate owner. Some certificates from Verisign have a Relying Party Agreement that does provide a financial guarantee to the party relying on the certificate - $100 for a class 1 cert, $5000 for a class 2 cert, and $100,000 for a class 3 cert. Most of the other issuers have relying party agreements which promise nothing and deliver less.

So what's happening is that, soon, you'll be able to tell the difference between the crap certificates and the good ones. Before you buy. The idea is that if you put your credit card into a site that showed a green toolbar in IE, and it wasn't really the company it should have been, you can collect from the certificate issuer. This puts certificate issuers on the hook for phishing losses.

Unfortunately, the rules and the Relying Party Agreements for the new certificates haven't yet appeared, so we can't tell if the rules are tough enough to make this work. Since they're being drafted by the certificate issuers, there will probably be some loophole that lets them off the hook.

Re:Where's the specification?

[Anonymous Coward]

Your reply assumes that identity validation is integral to SSL certificates. It isn't. Many websites need CA-signed certificates to protect data in transmission, and nothing more.

Identity validation and reputation verification are useful features, but need to be separated from the certificate itself. Let the certificate vouch for the transaction-layer security, and a separate site seal vouch for the reputation of the business. Combining multiple distinct and separate functions into one product only inconveniences all users of the product not in need of all features.

Re:Where's the specification?

[Anonymous Coward]

Encryption without identification is useless. Look up "MITD, man in the middle". Computers don't need a certificate to "vouch for transaction-layer security": Each computer simply generates a keypair on the fly and sends the public key to the other computer. If that looks secure enough to you, you need to shut the hell up and make a trip to the library. The whole point of certificates is to verify identity so that you know you actually got the public key of the computer that you want to talk to and not the public key of some impersonator.

Re:Where's the specification?

[LordLucless]

It's actually a good idea. Early in the history of SSL, getting a certificate required presenting appropriate business identification info to the certificate issuer. The problem is that some issuers (GoDaddy comes to mind) started issuing "domain only" SSL certificates; the only verification is that the domain can get email. Then, instead of revoking GoDaddy's root certificate for this, the other cert issuers copied GoDaddy's approach. Now anybody can get a meaningless certificate with a meaningless Relying Party Agreement.

So what you're saying is it's a good idea, because they're talking about extorting more money to do what they should have been doing from the get-go? I don't buy that. There should be a mechanism for encrypting web data that doesn't rely on paying a third party for a service only tangentially related to encryption, which they don't provide properly anyway. The only reason certs are being sold is that they're required to encrypt web data without a big warning box popping up. They aren't sold for their actual purpose - conclusively indentifying the holder - because they actually don't fulfil that purpose. This new cert is a racket, but then, so is the whole cert system.

Re:Where's the specification?

[starfishsystems]

Has anyone actually been able to find the specification for "high assurance" certificates?

I have not, and it strikes me as conspicuous by its absence. Especially since the X.509 standard already contains provisions for a Policy OID for exactly this purpose.

In fact the Policy extension provides for for a much richer set of purposes than EV has conceived. It would be quite acceptable, for example, to define an "anonymizing" policy or a "voting" policy in which the Certificate Authority has assured that certificate identity is unique but not traceable.

Possibly Mozilla is holding out for a more generalized solution in which users can decide the conditions under which the URL bar turns green, by matching against a qualifying set of Policy OIDs as just one example.

Re:Where's the specification?

[trifish]

The problem is that some issuers (GoDaddy comes to mind) started issuing "domain only" SSL certificates;

What problem are you exactly talking about? If a visitor only needs to be sure that he or she is communicating with the real and correct server and not some phishing site, he/she just needs to verify a site certificate. The email address in the WHOIS record (via which the CA verifies that the recipient of the certificate is the site owner or admin) is absolutely sufficient. Anyone who controls the email account can transfer the domain name or point it to other DNS servers, etc. So the email address does matter and is crucial security-wise.

The bottom line is, these certificates are perfectly secure and they are not intended to prove the identity of a business but they prove that you communicate with the correct server/site (and not with a phishing scammer). That's all.

Monopoly ?

[Anonymous Coward]

What do you bet the implementation is designed so that the browser will only accept 'enhanced SSL' certificates that have been signed by Verisign ?

Does anyone believe that a system designed by Microsoft and Verisign will be inclusive ?

Has anybody seen a RFC for this yet ?

SSL and Extended SSL

[Kazrael]

Honestly, I believe that there should be a WC3 conference to contribute a single CA that makes its way onto all browsers. Give the WC3 CA site an automated system for generating certs, including an open API and then combine DNS registration protocals with the CA gen protocals. Publicly open the API, and charge small, if anything. This service is an easy one to implement. The real issue is getting browsers to add it to its automatically trusted CA list. I can create SSL at home, but I can't get browsers to add my home web onto the trusted CA list by default.

Re:SSL and Extended SSL

[Anonymous Coward]

Check out http://www.cacert.org/. You can join for free, create your own certificates, and it tells you how to add cacert.org to your CA cert authority.

Re:SSL and Extended SSL

[Anonymous Coward]

You're missing the point of what a trusted CA is supposed to do. The point is that the browser makes trusts this CA to verify that a domain name has a legitimate owner. More precisely, the browser maker trusts the CR to verify that the person who applied for the certificate represents the owner of the domain name. If you create a CA that does no verification, how would you trust them? It would be a huge security hole for such a CA to be in Mozilla's list of trusted CAs. Somebody could register with this free CA as citibank.com, hijack DNS, and impersonate https://www.citibank.com with the users none the wiser.

Microsoft

[nurb432]

"See only we are secure"

phffft

The problem with CAs...

[Anonymous Coward]

... is that they are a commercial venture. They will sign just about anything as long as they are paid. I have seen more than one piece of malware signed by Thawte. The whole model of third party commercial CAs is badly flawed in concept. One only needs to pay a CA like Verisign or Thawte to appear legitimate to the average user and then proceed with whatever nefarious purpose one desires.

I trust a self-signed certificate more than one signed by Thawte or Verisign. (I do trust Entrust though, as they are Canadian)

Extended Validation SSL? Is it 256 bit? I think not (what would be the point?). 128 bit SSL is 128 bit SSL regardless of who signs it and how. You must trust the server you are dealing with in the first place, SSL is merely there to make your cummunications with that server private (all the more so if self-signed).

I expect that this "Extended Validation" is an implicit admission that up till now they have been signing pretty much anything as long as they get paid. Even so, it is not up to a CA to assure users that a particular site or application is not nefarious in purpose.

The signing CA model is flawed and very misleading to the average user. I say it does more harm than good.

Current system is already a racket

[rhaas]

I mean... since they don't do any verification anyway... and the customer service is terrible... why does it cost hundreds of dollars?

Re:Current system is already a racket

[itwerx]

I mean... since they don't do any verification anyway... and the customer service is terrible... why does it cost hundreds of dollars?

Because their business plan looks like this:

Step 1 - Profit!

OT: A heads up on your .sig

[Zero__Kelvin]

From your .sig:

There are 11 types of people in the world: those who can count in binary, and those who can't.

... and the 3rd type would be? ... it would appear that you are a member of the latter set. You see 11 binary is 3. You want to say: there are 10 types of people in the world ...

Peace ...

Free Certs are Evil

[Anonymous Coward]

Conducting business on the Internet in a secure manner requires two things, trust and privacy. Certificates were SUPPOSED to provide both of these, however free certs have really undermined this because companies offering free certs certainly cannot afford to do a good job of verifying the identity of the applicant. Extended Validation SSL means that the CA agrees to abide very stringent identity verification regulations before issuing a certificate to an individual/company. Guess what? Abiding by these regulations is going to cost money, therefore the cert is going to cost more. Duh.

I look forward to my browser (come on Firefox devs!) distinguishing between Extended Validation certs and "traditional" certs.

Re:Free Certs are Evil

[Anonymous Coward]

Its VERY rare to find a customer who cares who signs the cert. They just want to see that little lock icon light up. Beyond that, there is no reason why a free cert would be less secure then one from Verisign.

Re:Free Certs are Evil

[Anonymous Coward]

Free certs are DEFINITELY less secure than Extended/For-Pay certs. There is really no way you can argue this. Security means privacy (encryption) AND trust (identity).

I agree that users normally just look for the lock, and they feel secure when they see it. However, if the identity of the certificate holder (person/company running the web server) cannot be vouched for, the only thing the user is getting is encryption. So yeah, the data is secure on the wire but they have no idea who's on the other end.

So I say again, you need BOTH (trust and privacy) and I applaud browsers' and CA's attempts to solve that problem. This CANNOT be solved by open source / free CA's.

Re:Free Certs are Evil

[geminidomino]

If you're going to astroturf, you might want to make a snazzy new account instead of posting AC. Something like "geekgrrrl69" would at least catch the dumber denizens of the site.

Re:Free Certs are Evil

[Anonymous Coward]

No kidding, I really should come up with an alter ego to entice readers. At least this time I tried to come up with a subject that would piss off the "only free things are good" crowd.

I mean, free things are usually good, but commercial things can be good as well.

Sincerely,

B1gB00bi3s

Re:Free Certs are Evil

[Achromatic1978]

That's really irrelevant for the most part - I'm yet to find (though I'd love to be proved wrong!) free certs that have appropriate root certs in IE and Firefox, etc.

Re:Free Certs are Evil

[Anonymous Coward]

Certificates as used by businesses are all about feel good for end users and making money for the CAs and kickbacks to the browser manufacturers. If it was really about security the end user interface would be different. In particular there would be a difference between the first and subsequent visits to the same site.
Free (in particular self signed) certificates are nice for upping the anti for people trying to monitor internet traffic. And as such provide a useful service. (And in my opinion a more valuable one than the one the CA companies claim they are supposed to provide.)

Re:Free Certs are Evil

[Anonymous Coward]

You can add CA certs to your browser. You can also remove them. I have removed all of the CA certs from my browser since I have no special trust relationship with any of them and only use certs from them for encryption, not validation.

Re:Free Certs are Evil

[Anonymous Coward]

Yes it can. (At least to a better extent than it is now.) You can let the users save certificate information after interacting with a site and letting them know if the certificate changes later and have a warning the first time they visit a site. This does not require third party CAs.

Re:Free Certs are Evil

[Anonymous Coward]

If you're going to astroturf, you might want to make a snazzy new account instead of posting AC. Something like "geekgrrrl69" would at least catch the dumber denizens of the site.

If you're going to reply to an invisible post buried by the asinine moderation system you might want to quote it so that we have some idea of what the fuck you are talking about.

Most colorblind people can tell white from green

[wsanders]

However, they feel just as dumb as everyone else after they've been suckered into paying an extra $1000 for a Verisign Super-duper Whiz-Bang Mega-Ultra Cert.

To be honest there is a difference between a cert from a real CA and some $10 cert from some outfit that doesn't care anything more about your true identity than whether your credit card payment goes through. Google for "high assurance" vs "low assurance".

Re:OT: A heads up on your .sig

[geminidomino]

Wooosh!

Fund raising idea for firefox

[NaCh0]

Mozilla.org should get into the SSL certificate reselling business and set the location bar to green when one of the mozilla signed certs is present. Verisign could then have the option of paying a royalty to mozilla.org for each extended certificate if they want green URL bars too.

SSL is worthless anyway

[cortana]

Have you audited any of the dozens of CA certificated that ship with your OS?

Do you fetch a new CRL for each of them whenever you access a site using SSL?

Re:SSL is worthless anyway

[Sloppy]

Yeah, that's what's so funny. Almost nobody knows jack-shit about any of the CAs. And who knows the least? Exactly the kind of non-nerds/non-paranoids who trust the padlock icon the most.

Re:SSL is worthless anyway

[Anonymous Coward]

I just deleted them all. The only CA I trust is me.

Re:SSL is worthless anyway

[Anonymous Coward]

SSL is worthless anyway

So you can effectively decrypt 128 bit encrypted data? How many online banking passwords have you sniffed and decrypted this week? Hoo boy are you gonna be rich and fast. It will be tricky not to get caught tho, and I think its probably a bad idea to blab on slashdot that you can effectively decrypt SSL.

OK now that we've dealt with the inflammatory and just plain wrong subject of your post...

Have you audited any of the dozens of CA certificated that ship with your OS?

Yup, the only one I trust is Entrust, I take all the others with a grain of salt. Thawte signs malware, Verisign hijacks domains...

I think you missed the point of SSL. It's not about trust, its about encryption. The whole certificates thing is an afterthought. Ever since the first time I set up an apache SSL server, I never could understand the point of CAs... totally flawed concept. As mentioned above I will always trust a self signed certificate more, as it means there is no third party being notified of the encrypted transaction. SSL is not meant to assure trust, only privacy. It is up to you to determine if you trust the server you are dealing with. Only a fool would assume a third party CA) that is being paid by the certified bodies can honestly determine that for you.

Re:OT: A heads up on your .sig

[Anonymous Coward]

whooosh! :)
welcome to the world of the meta-joke

StartSSL and FireFox 2.0

[Anonymous Coward]

Perhaps this is also an answer to the efforts of the StartCom CA. At this article there is a nice explanation about this...Which doesn't mean, that StartCom can't provide the necessary extensions in the future. With 43 % of market share in Germany and other European countries, Firefox is far away from suffering on the hands of Verisign and MS!

Re:OT: A heads up on your .sig

[Anonymous Coward]

The third type would be those built so low to the ground that the jokes go whizzing over their heads at near-supersonic speeds...

Re:OT: A heads up on your .sig

[Zero__Kelvin]

Presumably you are saying that something just flew over my head? Or are you saying it flew over the head of the parent? If you are saying something flew over my head, then I would love to hear what it is supposed to be that I missed.

Re:Most colorblind people can tell white from gree

[pboulang]

Yeah, the "real" CA's require that you fax in something on, wait for it, letterhead. oooooh safety......

Re:OT: A heads up on your .sig

[ezzzD55J]

I'm wondering that too. Maybe the joke is that the author can't count in binary either.

Re:OT: A heads up on your .sig

[Zero__Kelvin]

I'm wondering that too. Maybe the joke is that the author can't count in binary either.

I think you are right. That was the only thing I could think of as well. Of course, it isn't funny if you have to point out that it is a joke. Claiming that the "joke" (as it were) went over my head is just plain absurd. Of course, I laughed my ass off either way :-)

Re:Most colorblind people can tell white from gree

[TheRaven64]

On the otherhand, CACert, which is free, requires to see two forms of government issued ID, one of which must have a photograph.

Sadly, CACert's root certificate is still not included with Mozilla, although a number of distributions include it.

mod parent up!

[element-o.p.]

Nuts...I'm out of mod points!

The first paragraph of the parent post is, IMHO, both +5 Funny and +5 Insightful.

It is Verisign's job

[rhythmx]

...as a Certificate Authority to ensure that any sites they issue certificates to are trustworthy. All PKI systems are based on this kind of trust model. If there is any lack of trust/confidence in online ssl-encrypted commerce, it is their fault. Merely because they have been ignoring their role as a trust arbitrator and giving out certs to anyone, they decide now to actually do their part, charge more, and have Microsoft put a flashy "green for go" interface on it.

Then, of course, you must slam Firefox for "losing the browser war" by not keeping up by making their URLs turn green. You know, (speculation alert) you can probably bet Microsoft patented the green url indicator anyway, locking Firefox out.

CardSpace anyone?

[monkeybrain]

So far nobody has mentioned InfoCard/CardSpace. I think you will find that one of the major pushes for the new extended certificates is to improve the user experience with respect to security. Presently anyone can get an ordinary SSL certificate - a phishing site can easily obtain an existing SSL certificate that will allow them to fool more average joe users that no certificate at all. With an extended certificate a company's name, location and logo are also included as part of the certificate so it should be much easier for uneducated users to make the connection between the certificate and the organization whose site they are visiting and more difficult for the phishing sites to do so. So the new certificates provide a better way for websites to prove their identity to users and aim to provide a consistent way of presenting this information to users so that they can make a choice as to whether or not they trust a site.

For details see the section titled Improved User Confidence in the Identity of Web Applications in Introducing Windows CardSpace: http://msdn.microsoft.com/library/en-us/dnlong/htm l/introinfocard.asp/

CardSpace is a Good Thing. Check out Kim Cameron's blog http://www.identityblog.com/ for ongoing coverage. Microsoft is doing everyone a big favor in the identity space - they fully acknowledge their mistakes of the past (e.g. Passport) and are very open in terms of what they are doing and how they are doing it. Further, the specifications behind all of this are unencumbered (see http://www.identityblog.com/?p=574/.

A better reputation system needs to be adopted

[Anonymous Coward]

It has nothing at all to do with cracking SSL. It has to do with easily getting a certificate bound to an identity and making sure that the user doesn't compromise his private keys thereafter.

You can change procedures for verifying the identity of a person before issuing a cert, that will make it certain that less certificates get issued by the highly trusted CAs. It will help cut down on simple phishing schemes. But it will also turn a lot of businesses to using certs with less stringent requirements, with businesses turning to the CA that has the least hassle and customers getting used to accepting them. For an admin, a tree structured heirarchy gets you into central planning and breadlines when you are trying to get a suite of servers up and running. You may have 15 days to setup 100 servers, and a CA with a 30 day turnaround. This can make things so painful, that the only thing you use a "real certified cert" for is for your external IP addresses.

A good reputation system that understands that reputation can be context dependent and tweaked by the community might be a better fit for the internet.

The technical problems with X509 certs run so much deeper than any of this however.

1) There are no ultimate roots that all users can trust, making a universal set of root CAs problematic. Do you trust the root CA of every country you deal with? As an example: The DoD won't accept anything other than a highly cleared US Government entity, while those outside the US might not trust such an entity for any purposes whatsoever. One of the first acts of setting up a web browser in some military environments is to remove all of the civilian CAs from the "trusted" list.

2) SSL certificates are generally issued as software files, servers generally need to be rebooted unattended, it is bad to have passwords on the filesystem, and finally if a web server gets compromised there is a chance that the software certificate store (with private key material) is now floating around on the internet. These things conspire to ensure that no matter how carefully you identified the identity of the certificate owner, that over the lifetime of the certificate it's very likely that the private key information has been made available to somebody other than the owner. (Ex: import your client software cert into IE at a workstation that you login to, but somebody else administers).

3) Using the common name in the certificate to map to the issued DNS name is a bad hack that attempts to fix the insecurity of the DNS system. Assuming the approach of requiring the hostname to match is used, the certificate securely binds the DNS name to an endorsement from the signing entity; assuming that the owner manages to keep the private key material a secret. A passphrase wont really stand up to a long offline attack once the software cert (PKCS12 or JKS file) ends up in a hacker's database of "certificates that somebody would trust". Using an email address in the common name for client certs has similar problems.

4) You REALLY NEED TO GO TO HARDWARE TOKENS (like smartcards) if you want X509 certs to have anything resembling security. This is ESPECIALLY true with client side certificates. This is because it prevents the user from accidentally spilling the beans - over a period of years over which the cert will be valid. In this case, the hardware token has a set of root CAs that it trusts, with the user generally being limited in managing these trusts for himself. And the user cannot have the private key material permanently compromised because the key material is never exported out of the hardware token to perform computations (into the server's memory, etc.).

5) Certificate Revocation: I have yet to see many using it correctly on a large scale. If you trust ALL of the certificates issued by a CA, then you should check the CRL to make sure that the certificate you are accepting is not revoked (in spite of being valid and not yet expired). A lot of people don't bother keeping updated CRLs

CACert

[Kadin2048]

Does anyone know why CACert's root isn't included in Firefox?

Seems like that would be a no-brainer; I can't believe Firefox is really interested in perpetuating the Verisign monopoly. (Or is Verisign a donor?)

Re:CACert

[TheRaven64]

The Mozilla foundation did not have a good set of criteria for including a cert. Originally they pretty much just used the same ones as IE (pay a big heap of money). Now they do have a set of rules, and the CACert people are trying to prove that they comply with them. It should be done Real Soon Now(TM).

Inform author

[kahrytan]

A Firefox implementation of extended validation can only be a matter of time, since the Mozilla Foundation knows in order to compete it cannot afford for its browser to be just as good as IE7; it has to be better.

Will someone please inform the author and Verisign that Firefox is BETTER then IE7.

How often is sensitive information is stolen during transmission? I always hear about hackers stealing information of past customers. So, what does the new SSL has to do with better security?

My money's an a new OID.

[Ayanami Rei]

Or a seperate certificate store, if they're worried about interoperability issues.

Re:My money's an a new OID.

[Anonymous Coward]

They put a new OID on the cert. The OID is specified in a property attached to the root in the Cert store.

You want TECHNOLOGY? Ok, here's some.

[Sloppy]

"Technology?" Give me a break. They're looking at what authority signed the cert, and if the web browser has been told to dogmatically trust that authority more than others, then it turns something green.

Actually, it's not a bad idea. There are degrees of trust, and showing it to the user is fine. But you bet your ass this is mostly just a cashgrab from Verisign.

A Firefox implementation of extended validation can only be a matter of time, since the Mozilla Foundation knows in order to compete it cannot afford for its browser to be just as good as IE7; it has to be better.

Good news. There's a way to do this, that will absolutely embarrass MSIE, making its version of https look completely insecure by comparison, and screw Verisign over, in the process.

Support an OpenPGP-based cert model (perhaps using GNU TLS library, perhaps not). Suddenly, you can have certs that are signed by multiple authorities, including users themselves, and display a whole spectrum of trust metrics. Equifax can make mistakes and issue an incorrect cert to a bank, but can three CAs all make the same mistake, without a conspiracy? And what if you get the bank's fingerprint on your snailmail statements, or there's a sign showing the fingerprint when you walk into it, and thus you can cert it yourself? What if you haven't ever been to the bank (ok, I can't imagine that) but you have 3 friends who have, and you have certified them, and told your computer they are each marginally trusted, and they all certify the bank? Three friends are sure as hell a lot more trustworthy than some faceless corporation named Verisign, whose identification policies you don't even know, whose private key storage policy you don't even know, and in fact doesn't have a single employee you have even met, assuming they have any employees at all and aren't a robot in the basement of a building at the NSA.

The basic question: are you

[Animats]

There should be a mechanism for encrypting web data that doesn't rely on paying a third party for a service only tangentially related to encryption.

There is. You can still get cheap SSL certificates. But if you're accepting payments, plan on getting one that clearly identifies who you are.

If you accept payments through a web site without disclosing who you are, you're a criminal. (California Business and Professions code section 17538, other provisions in other jurisdictions.) And soon, browsers are going to put up a big red flag that will make your customers go away.

Re:The basic question: are you

[LordLucless]

There is. You can still get cheap SSL certificates.

Bzzzt. Wrong answer. I shouldn't need to pay anyone to encrypt my traffic, even "cheaply". There is no technical reason why I need to.

If you accept payments through a web site without disclosing who you are, you're a criminal.

Wrong again. Two out of two, you aren't doing too good here.

Firstly, I can disclose who I am without paying for a certificate. "Disclosing" does not equal "proving", and even if it did, these certificates prove nothing anyway, because Verisign et al aren't doing their job properly. The only thing having a certificate proves is that you had enough money to pay for it. Cert companies don't check to make sure you are who you say you are. They should, but they don't.

Secondly, there are uses for encryption that aren't related to payment processing (*gasp*). I could be running a forum, and want to protect my users login details, for example.

And soon, browsers are going to put up a big red flag that will make your customers go away.

Exactly. That is why this is a racket. It's a protection racket. "Pay us money or we'll make your customers go away".

Re:The basic question: are you

[Animats]

If you accept payments through a web site without disclosing who you are, you're a criminal.

That's the law in California, or if you sell in Calfornia. California Business and Professions code section 17538 provides that:

(d) A vendor conducting business through the Internet or any other electronic means of communication shall do all of the following when the transaction involves a buyer located in this state:

(1) Before accepting any payment or processing any debit or credit charge or funds transfer, the vendor shall disclose to the buyer in writing or by electronic means of communication, such as e-mail or an on-screen notice, the vendor's return and refund policy, the legal name under which the business is conducted and, except as provided in paragraph (3), the complete street address from which the business is actually conducted.
(2) If the disclosure of the vendor's legal name and address information required by this subdivision is made by on-screen notice, all of the following shall apply: (A) The disclosure of the legal name and address information shall appear on any of the following: (i) the first screen displayed when the vendor's electronic site is accessed, (ii) on the screen on which goods or services are first offered, (iii) on the screen on which a buyer may place the order for goods or services, (iv) on the screen on which the buyer may enter payment information, such as a credit card account number, or (v) for nonbrowser-based technologies, in a manner that gives the user a reasonable opportunity to review that information. The communication of that disclosure shall not be structured to be smaller or less legible than the text of the offer of the goods or services. ...

(g) Any violation of the provisions of this section is a misdemeanor punishable by imprisonment in the county jail not exceeding six months, by a fine not exceeding one thousand dollars ($1,000), or by both that imprisonment and fine.

Yes, running a business anonymously is a criminal offense. You can incorporate, if you like, but you can't just use a psuedonym.

Re:The basic question: are you

[hublan]

Bzzzt. Wrong answer. I shouldn't need to pay anyone to encrypt my traffic, even "cheaply". There is no technical reason why I need to.

You can issue yourself self-signed certs using any of the fine crypto packages out there. The difference is that the browser isn't simply going to accept it on faith since you're not in its list of automatically trusted certificate authorities. The user will have to manually accept your certificate. If this is strictly to provide encryption for your forum website, they shouldn't have a problem with it.

Re:The basic question: are you

[LordLucless]

None of which requires an SSL cert, and so isn't germane to this conversation. This conversation isn't about requiring you to disclose your identity, this conversation is about requiring you to purchase an SSL cert. The "disclose your identity" thing was a strawman setup by the grandparent.

Re:The basic question: are you

[LordLucless]

You can issue yourself self-signed certs using any of the fine crypto packages out there. The difference is that the browser isn't simply going to accept it on faith since you're not in its list of automatically trusted certificate authorities.

Exactly. But I don't want the browser to tell the user that it's sure I am who I say I am. I want the browser to encrypt the damn data. SSL incorporates two mechanisms, one for authentication (proving you are who you say you are) and one for encryption (making sure nobody but the two parties involced can understand the data exchanged). Authentication requires a cert signed by a trusted authority. Encryption doesn't. But because the two are bundled, I can't encrypt anything without paying an organisation to sign a cert. I don't want a cert, I don't want any of the features the cert offers me, as they are related to authentication, not encryption. But I have to pay for it anyway, unless I want a big flashing warning sign on my page.

That's ignoring the fact that none of the trusted authorities are actually trustworthy. The original idea was that you'd pay them to investigate your application and vouch for your identity. They don't do that now, they just take your money, and hand over a cert. This makes the cert absolutely useless for what it's intended for.

Re:The basic question: are you

[hublan]

But I don't want the browser to tell the user that it's sure I am who I say I am. I want the browser to encrypt the damn data.

But that's the whole point. Encryption is about trust. Trusting that only the two endpoints agreed upon are actually talking and no-one is listening in on it. The certificates (to a certain extent) enable that level of trust. Otherwise anyone can simply insert themselves into the stream (man in the middle attack) and neither you nor the user would be any wiser, since no credentials are being displayed and acknowledged. At this point you're no better off than having no encryption at all.

Re:The basic question: are you

[LordLucless]

No, Authentication is about trust. Authentication is supposed to guarantee that the person who you are talking to is who they say they are. Encryption is all about stopping any third parties from eavesdropping on your conversation.

Certificates don't even claim to stop man-in-the-middle attacks. Certificates attempt to stop "spoofing" attacks. When you click on a spammy link, and you go to www.eebay.com, they are not supposed to be able to have a certificate unless they can prove to the issuing agency that they really are eebay.com. In practice, they don't, they just take their money and grant a certificate. The absolute most a modern certificate can prove is that the recipient of the certificate can get mail through that domain.

Man-in-the-middle attacks are prevented by encryption - there's no point in standing between two people listening to their conversation if you don't understand what they're saying.

The problem with this is that I cannot defend me or my users against man-in-the-middle attacks without also buying one of their snake-oil certificates. Not for any technical reason, mind you. Not because I actually need their services. Just because the SSL protocol is engineered such that you can't have one without the other unless you want warning boxes popping up all over your site.

Re:The basic question: are you

[Anonymous Coward]

Man-in-the-middle attacks are prevented by encryption - there's no point in standing between two people listening to their conversation if you don't understand what they're saying.

There is if both people unwittingly negotiate session keys with you rather than each other. Avoiding that is the very essence of authentication.

Re:The basic question: are you

[AnyoneEB]

I think you have it backwards. www.eebay.com can get a cert saying they really are www.eebay.com because, well, they are. On the other hand, if you are connecting to www.eebay.com, and your computer gets a signed cert saying the computer you are connecting to is really owned by www.ebay.com according to whatever trusted CA (because www.ebay.com intercepted your communication attempting a man-in-the-middle attack), then you will get a warning pop-up in your browser.

Re:The basic question: are you

[LordLucless]

There is if both people unwittingly negotiate session keys with you rather than each other. Avoiding that is the very essence of authentication.

Exactly. Of authentication, not encryption.

It's purely a money-making scam for Verisign

[(Score.5, Interestin]

It's purely a money-making scam by Verisign (and other CAs). The only thing high-assurance about "high-assurance" certs is the assurance that you'll be charged more money for them. See the Defcon talk Phishing Tips and Techniques - Tackle, Rigging, and How and When to Phish for a discussion of why "high-assurance" certs are worthless except to the companies issuing them.

I don't know if I would trust this article.

[Anonymous Coward]

My address bar was WHITE when I read this article. I don't think ./ is a very secure site for firefox to be going to. Actually though, if verisign wanted you to only trust websites that are green, what could this be saying about them. I think that they're leprichauns (green people) that only want you to trust leprichauns instead of trusting the white people who use firefox. They're teaching racism against color, I tell you. We'd better watch out for them. But don't trust what I'm saying, after all, I'm white, not green. And besides, I use Mozilla products. Horrible person I am.

Enough centralized control - where's mod_pgp?

[Dr.Dubious DDQ]

Okay, I admittedly have a relatively limited understanding of the technical details, but it's my understanding that the OpenPGP standard does essentially the same thing as the SSL encryption and authentication, but with an explicit "web of trust" model rather than a centralized "Verisign says they're okay" sort of model used by SSL.

Since Verisign et al don't seem to REALLY be verifying identities any more (unless now you pay extra for the "special" certificates), why keep paying them at all? Wouldn't it be possible to do a mod_pgp (or "mod_gnupg" or whatever) modules for Apache and an extension for firefox to use OpenPGP encryption instead of (or in addition to) SSL?

Anybody with better technical understanding want to comment?...

Re:Enough centralized control - where's mod_pgp?

[ratboy666]

It won't work. A "web of trust" model is good -- within a small group.

However, people should NOT rate trust relationships for businesses. And why should we? Indeed, the correct trust relationship is "I can't/don't trust you". Any company that has let unencrypted backup data out the door, that has sold customer information, etc. would be "don't trust". How are the other companies (could trust) enter a trust relationship? Their process in handling information would need to be audited. By the person contemplating the trust relationship. Which won't happen (or shouldn't happen).

For business I have to use the "military" meaning of trust -- I can't avoid giving trust to the business. They *could* fuck me over; the only choice I have is not to do business with them.

YMMV
Ratboy

Re:OT: A heads up on your .sig

[Dr.Dubious DDQ]

The (binary) 11 types of people are: Those who can count, and those who can't.

Re:The new certificates are double plus super good

[JonathanR]

Hey, there's got to be a...

[n-x]. ????

...in there before the...

[n]. Profit!!!

The employee just can't be allowed to get away with that sloppy approach!

Phishers can and do get certs

[Beryllium Sphere(tm)]

Phishing sites with SSL certs

In-depth look at one SSL phishing attack

Re:Phishers can and do get certs

[AKAImBatman]

In the first link, they're self-signed certs that trigger the "Stop the World, something's wrong!" message. If consumers are ignoring this already, I'm afraid that a "green bar" isn't going to be much more effective.

The second link is more problematic, but the solution is simple. If a cert authority can't do proper due dillegence, then remove them from the browser's trusted list until they correct their procedures. They're obviously not trustworthy. Giving Verisign an artificial monopoly on something they should already be doing is not the way to solve the problem!

The really correct crypto-ish way to do it

[Beryllium Sphere(tm)]

I've never had the nerve to try this but the phone call would make a really funny transcript.

The right way to verify a cert is to phone the establishment the cert is supposed to be for, and have them verify the thumbprint.

Imagine trying that. Just imagine it.

Sadly its commonplace....

[woolio]

This is stupid. You're paying EXTRA to have someone do the verification they were supposed to be doing already.

ROTFL...

You mean like pay a mailing/shipping company insurance for them to do their own job?

Or paying extra for an extended warranty? (To guard against stuff that shouldn't be crappy in the first place)

Or paying a credit card company EXTRA MONEY for them to taken YOUR PAYMENT "express" ?

Or paying extra money for a "Service Plan" to get "updates" to bug-ridden software?

Or paying a monthly fee for ambulance service? WTF?!?!!

Sadly, we do live in interesting times... And its only getting more and more "interesting"!

Default to Green

[Anonymous Coward]

Why not just set firefox to have the green color for any site with any certificate?

Joe Computer User will then wonder why Internet Explorer doesn't have the green bar when he logs into his favorite porn site.

Sorry, I forgot Joe only uses what comes installed by default, and has no idea what's going on.
Firefox users are at least computer literate enough to download and install a new browser, perhaps not enough to understand why they don't get that purdy green url color. so... disregard this.

Re:OT: A heads up on your .sig

[Zero__Kelvin]

The (binary) 11 types of people are: Those who can count, and those who can't.

... and again ... NO , that would be the binary 10 types of people. You did identify the third type for me inadvertantly however. There are those who think they can count in binary, but just cannot quite pull it off :-)

DRM All Over Again?

[Jane Q. Public]

(1) There are few if any perfect encryption systems; security is based on the estimated computing (i.e., time) cost to break.

(2) Realistically we should only be interested in encryption that is "good enough" for our purposes. That is to say, systems that give us reasonable security in proportion to the risk involved. Expecting perfection is not realistic.

(3) "Good enough" keeps shifting, but it is possible to create systems that will be reasonably good enough for, say, about 5 years.

(4) Systems that use too much or unnecessary encryption are resource hogs, which in turn means they cost you unnecessary money and time.

(5) Thanks for nothing Verisign, you greedy bastards.

Re:Gaah! Please skip the revisionism.

[edwdig]

The DOS / Windows 3.x days were when MS was at its worst. DOS and Windows each had much better alternatives, but the licensing from MS made it financial suicide to ship a PC with anything else. If a computer manufacturer wanted to ship 1 computer with DOS and/or Windows on it, it had to pay licensing fees for *every* computer they made. There was no negotiating over those terms, it was take it or leave it. That didn't change until the government got involved, at which point all the other players had already been wiped out (well, Apple was still alive, but barely).

Re:Most colorblind people can tell white from gree

[UnderCoverPenguin]

I know a few people who have Red/Green color blindness. They have trouble distinguishing between red, yellow and green.

The website http://colorfilter.wickline.org/ claims to provide representations of how websites will look to various forms of color blindness.

what's the price structure?

[epine]

If the extra up-front validation is the main thing, Verisign should be charging a high one-time-fee for undertaking those steps, then charging a low low monthly rate to rest on their laurels and do nothing further. Somehow I doubt that's the price structure they adopted here.

same with "pipes"

[hany]

You're paying EXTRA to have someone do the verification they were supposed to be doing already.

Same as with those "tubes" err "pipes" - telcos want you to pay more so that they can actualy deliver the speeds they alredy sold you.

Sorry for bringing this subject up again. :)

Just a Racket ..

[rs232]

"The system is implemented in IE7 by turning the address green for sites holding a extended validation certificate"

Any bets on how soon will someone come up with a piece of code that turns the address green on bogus sites. Any security device that relies on the user having to do something or in this case not doing something, is bound to fail. How about a cert built into the DNS system that way when the browser queries a domain name the DNS server returns an 'invalid' code and nothing pops up in the browser. I here by put this in the public domain.

"Callan puts Mozilla's apparent heel-dragging on the new security technology down to the character of its development community"

fud injection: the inneficient Open Source process as compared to the professional commercial product.

"Firms will have to stump up about 150 per cent of what they currently do for an SSL certificate."

How about you get fined each time a phishing site is registered with Verisign.

was Extended Validation SSL, More Secure or Just a Racket?

Re:Just a Racket ..

[Anonymous Coward]

How about you get fined each time a phishing site is registered with Verisign.

I'm assuming you mean that Verisign should be fined significantly every time it is deiscovered they have signed a certificate for a phishing site or a piece of malware... if so, that is a brilliant solution. Normally I'm against technology legislation and regulation but this would be very simple and worthwhile in my opinion, it would change things so that a CA could be held accountable and would therefore mean something, in contrast to the current situation.

So, yes Firefox is a chaotic open source software

[Ilgaz]

If Firefox (Mozilla) is not keeping up with technology fast, where is the OS X support? E.g. will there be a Safari update to support that thing? Why not? There, Apple.com, traditional business with "security department", will they ship it?

If Verisign loses the "compatibility", there won't be any Verisign in matter of couple of years. Remember I said it.

SSL'es power comes from Compatibility. When you implement a SSL site with Verisign, you know your clients,even the ones using Opera on their Symbian PDA's will have no problem accessing it,with same security standard.

Oh, what about Symbian support Verisign? They don't keep up with technology too I guess :) I am nearly sure that it will be implemented on Windows CE next.

I remember first days when Outlook Express came with S/MIME support. When you wanted it, a IE page opened with huge Verisign icon asking for $$$ for a full feature certificate. It took years for some to figure there is Thawte.com which gives them for FREE.

Speaking about Thawte, look at that:
http://www.thawte.com/ssl-digital-certificates/hig h-assurance/index.html

"To this end, and through our involvement with the CA Browser Forum, we are working with the American Bar Association Information Security Committee, browser manufacturers such as Mozilla, KDE, Microsoft and Opera as well as leading CAs to define industry standard online identity assurance processes that will serve to reassure all our customers of our dedication to building a trusted digital future that instills confidence and trust in all internet users."

So, there is a open technology which will be supported by ALL browsers (Read KDE as Apple). You know what to install from who.

I don't agree....

[Anonymous Coward]

SSL means that at least my credit card number and
address aren't going across the internet in the clear.
That's important to me.

It also provides SOME assurance that I'm talking to
the site I think I am. What happens to my credit card
number after it's unpacked in the web server is another
story entirely.

-- ac at home

Freudian Slip?

[Anonymous Coward]

Let me guess, you don't like Verizon, either.

Re:Freudian Slip?

[nosferatu-man]

Too true. I even previewed that stupid post.

Re:Most colorblind people can tell white from gree

[The Conductor]

The Gimp can also display (instructions) images to simulate the various forms of colorblindness (though in that case you would have to do a static screen capture of your stuff). For much more ./ style prattling on developing for colorblindness, an ask ./ item was posted on this topic a while back.

If you're really good, hack your xorg.conf to simulate colorblindness. But don't ask me how to do it.

Time for Firefox to simply bypass the cert cartel

[DamnStupidElf]

The thing is, no one is going to care whether an address comes up green or white. If they ever start caring, no one is going to buy the cheap certificates anyway. This is just a mandated price increase by Verisign, or a moot point. Why not just stick CAcert's root certificate in Firefox and be done with it?

Verisign = evil

[Anonymous Coward]

You don't need to look any further than who is on the board of Verisign, what they have done so far, and what entities they are connected to and you get the picture of how evil this company is. It is scary and obviously they are up to no good but seizing even more control and filling their pockets with peoples' money.

Vote with feet

[Anonymous Coward]

If I remove VeriSign from my browser's list of trusted CAs, will I still be able to do online shopping?

Stupid design

[sjames]

I don't see why this required a change to SSL. CAs already have multiple root certs, one for each level of verification they support. All that was really needed was a configuration to set the bar color on a root by root basis. Then it would "Just Work" with no further changes.

That would be a much better model of how trust is supposed to work. It's not a question of how much Verisign trusts that X is really X, what matters is how much *I* trust Verisign to be right. If I believe that "Snake Oil Limited" is more trustworthy than Verisign, that's my business (or problem) and the color bar should reflect that belief. If *I* believe that Verisign's double sooper secret cert means something, then my color bar will reflect that.

I suppose they didn't do that because then people might decide they don't really trust Verisign that much and configure them to show up as the warning color. Either that or they were hoping to slow their competition down by making them jump through a few extra hoops.

The only software changes that are REALLY needed is a simple way to support virtual sites using https without assigning each site a port and proper support for a web of trust system.

No tinfoil hat needed, Verisign is not monopoly

[wsanders]

No tinfoil hat needed, Verizon simply sucks and people know to take their business elsewhere. For example, Thawte is almost as widely used as Verisign, enrolled in ALMOST every browser as a root CA, and their high assurance certs cost half as much as Verisign's.

There are lots of others, just as reasonably priced. These root CAs WILL call you back after you fax in your letterhead.

There is also evident competition, because dealing with Verisign is much less the exercise in frustration it was several years ago, although you are still well advised to take a tranqilizer or two to take the edge off the occasional rage you will experience when dealing with them. Their online documentation is quite good.

The problem is that there are still a few lame-ass browsers, like the ones in my cell phone, only accept a small number of root CAs and won't allow cert importation, and have smoked the crack pipe of peace with Verizon. So I can't reach half the SSL sites on the web with my phone. And so on.

So you perpetuate the factionalization of root CAs at your own risk, to some extent.

Clarification

[wsanders]

>> The problem is that there are still a few lame-ass browsers, like the ones in my cell phone, only accept a small number of root CAs and won't allow cert importation, and have smoked the crack pipe of peace with Verizon.

Sorry, that came out wrong. My phone's browser only accepts Verisign and GTE as root CAs and doesn't allow me to import certs. So it's mostly useless. This is not Openwave's fault, the cert management is under the control of Verizon. Most likely they were just trying to make the phone idiot proof so they could sell their overpriced gansta ringtones with a minimum of hassle. That could be its own potential level of Hell: trying to explain PKI in a conversation between your average cell phone tech support and your average cell phone customer.

Re:OT: A heads up on your .sig

[AnyoneEB]

I don't know about you, but I heard the joke as "There are three types of people in the world: those who can count and those what can't." long before I every saw "There are 10 types of people in the world: those who know binary and those who don't." The .sig line is simply a combination of the two.

Re:You want TECHNOLOGY? Ok, here's some.

[AnyoneEB]

That would be a cool idea, especially because that could be used to sign your small personal website by asking all of your friends to sign it and having it propogate via the six-degrees principle.

Actually, if I connect to a site via HTTPS that has no certs and no signatures, then I have no way of knowing whether there is a man-in-the-middle attack going on, so there must be some initial signatures by the creator and his friends and/or employees of the company, who would be within your web of trust, but maybe far away. That would be reasonable. Then, say, once you buy something from the company and actually get something for your money, you could sign it yourself, so people close to you would get a higher trust rating for the site.

The problem is getting people to actually use web of trust systems. Currently they are pretty well limited to a subset of geeks. (I confess that I do not use GPG on my e-mail.) The problem is that some sort of out-of-band communication is needed for verifying keys. For example, OTR (IM encryption, no web of trust) shows a hex digit string that it recommends reading over a phone connection if you want to ensure security.

Maybe you could make a set-up where public keys could be stored on USB mass storage devices (read: iPods) and automatically scanned for when such a device is plugged in. Then sharing public keys requires plugging your iPod into your friends' computers.

Although, that still has a problem (for the common user) that spyware could silently modify the trusted keys to include. On top of that, the common user would have to trust at least one person who had a reasonable idea of what sites were trustworthy. You could get sub-webs of people who are already clicking on phishing links distributing signatures saying those phishing sites are good.

VeriSign Offers Clarification, Apology

[miller60]

Tim Callan of VeriSign has written a blog post clarifying and adding context to the statements in the Register that launched this thread. In the post, he offers an apology for the criticism of Mozilla. An excerpt:

"Let me start by stating that the story as written is very much not in keeping with the tenor of the actual conversation I had with the reporter in question. Among other things, the story makes it sound like VeriSign is critical of the Mozilla Foundation for not having announced support for the Extended Validation SSL standard at this time. Quite the opposite, in fact. Several members of the FireFox community have been key contributors to the Extended Validation effort and are active participants in the CA/Browser Forum. I never characterized Mozilla as heel-dragging in any sense of the word, and it was my effort to defend Mozilla's method of operation that led to the most regrettable moment in the article."

Re:You want TECHNOLOGY? Ok, here's some.

[julesh]

that still has a problem (for the common user) that spyware could silently modify the trusted keys to include

You should have to sign keys yourself to add them to the trusted list. So when it detected a key on removable media, this system would pop up a dialog asking for you to re-enter your password to verify you wanted to add the keys to your list.

Re:You want TECHNOLOGY? Ok, here's some.

[AnyoneEB]

That makes sense, but if you have malware installed on the computer doing the signing, you are still in trouble no matter how the system is implemented. The real solution is to bundle the web-of-trust app with Ad-Aware. ;)