Re: User interface, security, and simplicity

2008-05-02 Thread James A. Donald

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]

SSL use

2008-05-02 Thread Anne Lynn Wheeler
I've periodically posted that certain assumptions were made about safe 
SSL deployment for electronic commerce that were almost immediately 

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]