Re: User interface, security, and "simplicity"
Thor Lancelot Simon wrote: It's fashionable in some circles (including, it seems, this one) to bash IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what are basically user interface grounds. I cannot help repeatedly noting that -- I believe more so than with actual IPsec deployments, whether with or without IKE -- OpenVPN deployments are often configured in hideously insecure ways. This is no more the fault of OpenVPN's designers, of course, than the ghastly configuration interfaces imposed by many IKE impledmentations are the fault of IPsec's designers. We are dropping on end users, sysadmins and nno crypto programmers decisions that seasoned cryptographers tend to screw up, and that end users and sysadmins are never going to comprehend. The way programmers approach modularity and code locality tends to leave the end user outside the cryptographic boundary. The cryptography module is very carefully made entirely independent of the user interface, merely sending up arcane errors from time to time. Consider, for example, the recent cookie stealing security failure in Wordpress, fixed just a few days ago. It seems that for a very long time, there was very straightforward, indeed in retrospect glaringly obvious, security hole that allowed anyone on the internet to take control of any host running Wordpress - which most hosts do run. You can take control from Nigeria, you don't need to tap any lines. Anyone anywhere in the world could have exercised any power over one's server that one's Wordpress application can exercise, which is usually near total power. The defenders of SSL will quite correctly point out that the security hole had absolutely nothing to do with SSL. The hole exists whether one uses SSL or not, and almost no one uses SSL with Wordpress. And that was exactly the problem. The writers of Wordpress, like the writers of every other application, had to handroll their own authentication, and of course fucked up. SSL sessions are not user sessions, thus SSL authentication does not authenticate that user "admin" is the same entity (or even has the same IP address) as the entity that correctly logged in as user admin, does not, cannot, attempt to provide such authentication, that being a higher layer issue - indeed, SSL authentication is pretty much irrelevant to authenticating anything that the attackers or defenders are likely to care about, which is why user admin on a Wordpress application does not use SSL. SSL is so wonderfully localized that attackers just stroll around it. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SSL and Malicious Hardware/Software
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Phillips Sent: 28 April 2008 23:13 To: Cryptography Subject: SSL and Malicious Hardware/Software I can't think of a great way of alerting the user, I would be alerted immediately, because I'm using the Petname Tool Firefox plugin. For an unproxied site, I get a small green window with my own choice of text in it (e.g. "Gmail" if I'm visiting https://mail.google.com). If a proxy were to insert itself in the middle, that window would turn yellow, and the message would change to "(untrusted)". - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Microsoft COFEE
Arshad Noor wrote on 30 April 2008 20:36: > It can be "ordered to decrypt system passwords"??? So, I wonder > what attackers can do with this... They can run pwdump, lsadump, samdump, dump the pstore, snarf the SAM, all that kind of stuff that is completely routine and everyday. See here for a very similar device that's a couple of years old: http://wiki.hak5.org/wiki/USB_Switchblade Honestly, this is nothing extraordinary or even new. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
SSL use
I've periodically posted that certain assumptions were made about "safe" SSL deployment for electronic commerce that were almost immediately invalidated. The original assumptions assumed that the enduser knew the binding between the webserve that they thot they were talking to and the corresponding URL ... which they would then type into the browser. Then SSL would provide the assurance that the webserver that was actually being talked to corresponding URL. The two pieces together than provided that the enduser thot they were talking to was, in fact, the webserve that they were talking to. Almost immediately merchants invalidated the assumptions when they found that SSL represeted 4-5 times degradation in webserver thruput ... and dropped back to just using SSL for payment/checkout portion of the electronic commerce. Now a web "button" was clicked, providing an URL. Now the only thing going on was that SSL would verify that whatever webserver, the webserver claimed to be, was the webserver it claimed. This button clicking operation invalidated the original safety assumptions regarding the use of SSL for electronic commerce. The URL supplied by the button can be anything. Some amount of 3rd party payment processing outsources appeared to have taken advantage of this feature. A lot of phishing email also takes advantage of the paradigm also. I was recently invited to resister at a website with a non-US country domain. My registration would not even closely work since it appeared to require IE ... and since I don't have any windows machines ... I also don't have any IE browser. However in the process I thot I would poke around a little. I prefixed the URL with https (instead) of http. This got me a warning that the certificate was not for the indicated domain. When i looked at the certificate, it came from a certification authority that my browser recognized but was for a ".com" domain associated with some NIGERIAN payment processing operation. I then check the ip-address of the original (non-US country) domain and found it mapped to some US-based webhosting company. I then check the ip-address of the NIGERIAN payment processing operation and found it mapped to some other US-based webhosting company. I can only speculate that the first webhosting operation has some sort of default configuration for electronic commerce ... where SSL gets mapped to payment processing operation of this NIGERIAN payment processing operation. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]