Symantec To Buy VeriSign's Authentication Business

overThruster writes "Security giant Symantec is taking another step toward global domination of the information security market with the purchase of VeriSign's authentication business. Back in April it purchased PGP Corporation and GuardianEdge. VeriSign is the best known Certificate Authority; they are virtually synonymous with certificates for SSL and PKI. It seems like this could dilute the trust value of their brand rather than enhance it. It is not clear yet what effects this will have on VeriSign customers but the cynic in me says it can't be good. In terms of putting all your eggs in one basket, this will sure make Symantec a juicy target for hackers (as if they weren't already). Imagine you could hack one company and control a large chunk of endpoint security software and the bulk of the Internet's public key infrastructure."

Comments

FP

[Obstin8]

Nothing good can come of this...

Re:FP

[MightyMartian]

Oh look, Darth Vader has switched allegiances... to Sauron!

Re:FP

[dgatwood]

Actually, I think it's great. Symantec builds lousy, overpriced products, Verisign sells insufficiently verified, overpriced EV certificates. It's a match made in heaven. Better yet, we only have to hate one company instead of two, because what's left of Verisign should be mostly harmless.

Surely they can't...

[dov_0]

Find a way to make SSL certification slow down your computer as well? Maybe they intend to slow down the whole internet?!?

Re:Surely they can't...

[MrEricSir]

And once you install an SSL certificate, you'll never be able to completely remove it.

Re:Surely they can't...

[ascari]

Your computer is at risk!

Your Symantec SSL subscription has expired. All your secrets are visible to all users on the Internet. Click HERE to renew your Symantec SSL subscription.

Better than hacking one company...

[Ryvar]

instead, imagine you were a government official with no interest in civil rights and could quietly "persuade" one company and have access to the Root Certificate Authority...

But surely they run antivirus

[Culture20]

Imagine you could hack [Symantec] and control a large chunk of endpoint security software and the bulk of the Internet's public key infrastructure.

I'm sure they buy anti-virus and firewall software from a reputable vendor.

Three models

[tepples]

If security is the problem, certificates are basically never a good answer.

How else should I be sure that I am communicating with the entity I think I am communicating with? I can think of three models: certificate authority, web of trust, and key continuity management. If you're referring to key continuity management, the approach used by SSH that makes sure that the key you're using matches the key you used last time, that doesn't work if you're behind an ISP that's all MITM all the time. (Yes, these exist in the wild; see bug 460374 at bugzilla.mozilla.org.) If you're referring to a web of trust based on the Bacon number of mutual face-to-face meetings at key signing parties between you and a company's CIO, that doesn't work for people who can't attend such parties in major-league cities.

Re:Three models

[Peach Rings]

It does (to a ridiculous degree of security, but not perfectly of course) guarantee that you're communicating with someone that VeriSign says is the entity you think you're communicating with. If you trust VeriSign (and essentially the entire internet does by default) then you can be sure.

Although Thawte is apparently a bit better, I've never had any reason to distrust VeriSign. But I definitely do not trust Symantec. Their "internet security suite" is what we in the biz like to call shitware.

Re:Three models

[bastion_xx]

You realize who owns Thawte????

Re:Three models

[icebraining]

That's all nice and dandy, but it's also completely unfeasible. The problem isn't "how can I communicate completely securely", it's "how can anyone using a computer communicate with another through the Internet in the most secure way possible?"

HTTPS may flawed, but it's the best solution we got. Yours isn't a solution to the given problem.

Re:Three models

[jd]

Doubly so given all the various articles posted here on flaws in SSL safety - starting, many years ago, with someone obtaining Microsoft's root certificates by, well, asking for them. The use of NULLs to produce fake certificates that seem valid, the breakage of MD5-secured SSL certificates -- there has been no shortage of problems for the approach.

The idea of webs of trust is that you can't go out and physically verify the path but you CAN ask others if they're confident that X really is X. In the event that you are on a system where there is a well-defined gateway that can establish a secure tunnel to a well-defined gateway adjacent to the end-point, you have two other points that you can verify. If you can be confident of getting to the gateway AND you are confident that the tunnel really is secure AND you are confident that the far end of the tunnel is who it is supposed to be, I really can't see you getting any safer than that.

The question, though, is how to be sure that the certificates are genuine and are issued to the person or organization they're supposed to be issued to and haven't been forwarded on to anyone else. The first part would seem to require that certificates use hashing schemes still regarded as "safe" AND to require that any tampering (before or after) using NULLs or anything else would foul up the fingerprint. You must be capable of being 100% certain that what you see is what the computer sees is ALL of what the certificate requester submitted as the public information.

The second part would seem to require that weak levels of trust be eliminated from the system. Digital certificates should inspire trust because they deserve it, not because 99% of people are either complacent sheep or suicidal lemmings. To do this, though, the trust must work both ways. The issuer of the certificate has to be just as trustworthy. That's doable. Tough, but doable. One option, borrowing from the idea of witnesses from legal frameworks, is that there must be a neutral third party that can countersign the signature as being between who the parties say they are.

This suggests you want two webs of trust. One, of total strangers who can countersign as witnesses, and one of "friends" who can actively vouch for one or both parties (the more traditional web of trust). But countersigning the key only tells you the key is valid, it doesn't tell you the private half of the key exists only where it claims it does.

Requiring that three points produce valid countersigned certificates would boost the confidence of that, as it requires two independent private keys be compromised. That is less likely than one private key being compromised. Certainly possible, but less likely. If the network ran IPv6 and the IETF doesn't remove any more of the security built into the protocol (and maybe adds a bit of it back), the odds of a stolen key passing inspection would be considerably reduced.

The only thing I can suggest beyond that is that client-side authentication be imposed. Yes, it reduces anonymity, but you cannot both be sure the end-point is who they are supposed to be AND be sure the end-point is 100% anonymous. That doesn't work. Passwords and/or other user authentication verifies the user, but you also want to be sure that the machine the user is talking to is also the machine the server is talking to. Easiest way to do that is have the machine counter-sign the user's authentication data and then have the server query the client machine's certificate to ensure that the certificate matches the counter-signature. There are probably superior methods, but it's better to have a starting point than never start at all.

As for the SSL protocol itself, it uses public-key cryptography. Far as I know, this is perfectly respectable. I'm not keen on the use of HMAC - T-TMAC is considered the most secure, from what I understand, although it's only really good for short messages. Which is fine, since you want the most security on the authentication section. If T-TMAC is used onl

Re:Three models

[mlts]

Certificates are good and bad. If used in a smart WOT, they are great because if you have multiple people trusting someone, you know you are almost certain that that key belongs to that person.

The bad is just blindly trusting root certificates, especially certs from countries who are hostile to the West, and who would be happy to certify with their CA a key belonging to a known bank, then occasionally poisoning DNS or routing queries to the fake site, so they don't get immediately caught.

The best might be a combination all three. You have a "security cache" of keys or signed keys of places and people you have previously interacted with, which is crucial for ssh for the most secure communications. Next, you have a WOT with people you know trusting or not. Finally, you have a CA which may actually be valid, or not. CAs are really a part of WOT, and should be considered with little or no trust, compared to someone coming with (to continue the parent's example) a high Bacon number to yours. The only problem is someone who isn't familar with a WOT giving a key too high a trust that it deserves, but infiltration happens in every network, and with PGP or gpg, it is easy to mark a person's signatures as untrustworthy.

This reminds me of something different: Maybe it is time to get people and start doing PGP/gpg keysigning parties [1] again. This way,

[1]: Of course, there is the proper way of doing the key stuff. Send a list of public keys to the host, host prints out a list for everyone. Everyone then brings a copy of their key ID and hashes. Then go around matching the keys to the individual, perhaps asking for IDs, then circling the ones which pass the validity test. This way, no computers are used, and it is much harder to "compromise" someone's piece of paper showing vetted keys in the length of time it takes for them to leave the party and get home to sign everyone's keys and push the signatures to keyservers.

Symantec & information security

[Zedrick]

ha ha ha.

Not related to SSL and stuff like that, but anyway: a few years ago I got a job working doing technical support for Symantec. During training, I was first embedded with the customer service-people, and watched them sit talk to customers, while they took down credit card numbers and other details on paper, which were later thrown out the the general office-trash.

A few days later I was supposed to do "technical training" with the so-called 2nd line support... The day I had to explain to one of them how to unlock the taskbar on Windows XP was the day I quit - after a total of 6 or 7 days of employment.

And who buys their stuff anyway? I haven't touched any of it since then so I don't know if anything has improved, but I remember how the Norton Security-packages idea of protecting the computer was to slow it down to a crawl and basically block everything. Not to mention what a mess it is (was?) to remove it from the system...

Re:Symantec & information security

[fusiongyro]

Most people make most of their purchases based on a blend of emotion and awareness. Computers are ubiquitous, computer skills are not. Therefore, there's a thriving market for products whose advertising makes you afraid of something and then they sell you the solution. It's the same in every industry. Symantec has a big name and they have lots of ads and people are afraid of the things their products pretend to protect them from. So it's a business model. And it doesn't matter if it's a shitty product if 95% of people think they need it and buying it makes them feel better, they'll do it. That's just life.

the end is nigh

[bloodhawk]

Fantastic, now when you install an SSL Cert your computer will slow to a crawl, to uninstall the cert will require a complete rebuilt/reimage.

Symantec, as the guardian of 'net security?

[ibsteve2u]

Might as well put your keyboard at the bottom of a six foot-deep vat of molasses...cold, cold molasses...and start training.

it's business

[fusiongyro]

This is called diversification. Anti-virus is their flagship product, but the "benefit of the benefit" as they say in marketing is the warm fuzzy feeling of being secure. Well, certificates make people feel secure the same way AV does, so it fits the brand, so they're going to sell them. It's a great investment for them, I'm sure they'll make money on this deal.

All the time here on Slashdot I see people trying to read a technological message in a business decision or action. If you're puzzled or outraged by whatever Apple or Symantec or whoever are up to, just follow the dollar signs. This makes business sense and there's nothing more outrageous about Symantec selling certs than anyone else. Really. It's just business. There's no meaning here.

Symantec gives me headaches

[LoudMusic]

The two Symantec products I use are the AV client / server line and Backup Exec. Both of which cause me nothing but trouble. This is going to be bad for everyone.

Symantec and the Feds

[AHuxley]

Thinking back to the feds getting their keystroke logging software whitelisted.
http://en.wikipedia.org/wiki/Magic_Lantern_(software)#Symantec
Then you have Symantec wanting to acquire the encryption companies PGP and GuardianEdge.
Soon many PC's will run to end Symantec solutions for all their data security.
Symantec: "The FBI's most trusted antiprivacy solution"