Symantec To Buy VeriSign's Authentication Business 97
"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."
Symantec & information security (Score:4, Interesting)
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 (Score:3, Interesting)
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.
Re:Three models (Score:3, Interesting)
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:Symantec and the Feds (Score:1, Interesting)
Devil's advocate here: If a backdoor was found in PGP, (and so far none have been found, although there was the ADK issue about a decade ago), the company would be out of business immediately. People would ditch PGP for another solution in a heartbeat.
Already, PointSec, BestCrypt, or TrueCrypt offer hard disk encryption. Encryption of files can be done by gpg, and folders by tar or zip and gpg. Virtual hard disks can be created in BestCrypt, TrueCrypt, or FreeOTFE. Public/private keys can be handled by gpg. E-mail security can be handled by gpg and GUI tools. S/MIME can also do email security, assuming the root certificates are trustable.
If PGP is found to be untrustworthy, someone will step up to the plate and make a solution to replace it. However, I am sure in saying that this is not going to happen. PGP has had a great heritage since Zimmermann made it, with the commerical version coming from ViaCrypt. Symantec would not take the risk of ruining the goose that lays the golden eggs.
Re:Three models (Score:4, Interesting)
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.