|
search / subscribe / upload / contact |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
| RSS-Feed Depeschen |  |
|
|
||
|
||
Date: 1999-08-17
Evaluation: Secure Freemail/services-.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- Freemail/services, die verschlüsselte E-Mail Services via WWW anbieten, nur so aus Boden. Bruce Schneier hat sich drei davon näher angesehen & bei allen mehr oder weniger grosse Sicherheitslücken entdeckt. Fazit: Lieber doch S/MIME oder das gute alte PGP -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- ... HushMail <http://www.hushmail.com> is basically a PGP or S/MIME- like e-mail application that uses Java (although oddly enough, HushMail is not compatible with either). The sender logs onto the HushMail Web site, and encrypts messages using a Java applet that is automatically downloaded onto his machine. Both the sender and receiver need to have HushMail accounts for this to work. Accounts can be anonymous. The algorithms are 1024-bit ElGamal for key exchange and signatures, and Blowfish for bulk encryption. But everyone's private key is stored on the HushMail server, protected in a passphrase. This means that one weak link is likely to be the passphrase; it's the only protection you have against someone who has legal or illegal access to the HushMail server. .. Another weak link is the Java applet. When you download it, you have no idea if it is the correct applet. Yes, the source code is public, but that doesn't help when you are at a public Internet terminal trying to encrypt or decrypt private e-mail. A Trojaned Java applet can do all sorts of damage, and there is no way to know. .. This is actually a major problem. The applet can be signed, but who signed it? Even if you check the certificate, the typical browser permits a dozen different PKI roots by default, and any one of them can issue a forged certificate. This means you have to trust them all. And you have to trust that a Trojan didn't drop a phony certificate into your browser. Note that a downloaded verifier can never solve this problem; it just turns the "how do I trust the applet" question into "how do I trust the verifier." .. All in all, though, HushMail seems like a reasonable implementation of the idea. The company seems clued; they have a reasonably informative Web site, and respond promptly to security questions. ZipLip <http://www.ziplip.com> is different. Both parties do not need an account to communicate. The sender logs onto the ZipLip Web site and, using SSL, sends a message to someone else. ZipLip then sends the recipient a message telling him that your message is waiting. The recipient then logs onto ZipLip to receive the message. Encryption, outside the two SSL connections, is completely optional. ZipLip won't identify the encryption algorithm used, which is enough to discount them without further analysis. But they do something even stupider; they allow the sender to create an encryption key and then give the recipient a "hint" so that he can guess it. ZipLip's own Web site suggests: "The name of the project we're working on," or "The restaurant where we had dinner last night." Maybe there are 100,000 restaurants, so that's a 17-bit key. The threats here are serious. Both the sender and receiver need to verify their SSL connections, otherwise there is no security. The ZipLip server is a major attack target, both because many messages will not be encrypted, and because those that are will have keys weakened by the requirement that both parties remember them. On the plus side, ZipLip claims a policy of deleting all mail 24 hours after delivery, which provides a level of lawyer-proofing that HushMail does not have...if they implement it properly. YNN-mail <http://www.ynnmail.com> is barely worth this paragraph. They encrypt stored messages with a 40-bit key, and don't use SSL when you sign up and send them a long-term password. Snake-oil if I've ever seen it. And I just heard of another, ZixMail <http://www.zixmail.com/>. I didn't have time to examine it in depth, but the FAQ -- look at their wishy-washy comments on encryption -- makes it sound like real snake oil, too. Web-based encrypted e-mail is less secure than PGP-encrypted e- mail (or S/MIME e-mail) for a few reasons. One, the constant interaction between the communicants and the server leaves more opportunity for man-in-the-middle attacks, Trojan horses, etc. Two, SSL-based authentication is more vulnerable to spoofing, since almost no one ever bothers to check the details of received certificates and there is no revocation mechanism in place. And three, there are some very attractive attack targets: servers with large collections of secret e-mail and potential decryption keys. Certainly Web-based encrypted e-mail is better than unencrypted e-mail, but I'd stick with PGP or S/MIME if possible. Source http://www.counterpane.com -.- -.-. --.- - -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- edited by Harkank published on: 1999-08-17 comments to office@quintessenz.at subscribe Newsletter - -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- 
|
|
|
 |
CURRENTLY RUNNING |
q/Talk 1.Juli: The Danger of Software Users Don't Control
|
|
|
!WATCH OUT! |
bits4free 14.Juli 2011: OpenStreetMap Erfinder Steve Coast live in Wien
|
|