Re: once more, with feeling.

2008-09-18 Thread Peter Gutmann
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:

As to technical options to accomplish this

The mechanisms for this actually already exist, they're just not used.  First
of all, you need to admit that you have a problem: SSL certs by themselves are
more or less useless in providing assurance, the phishers are buying genuine
CA-issued certs for soundalike domains using stolen credit cards just as
easily as legit sites are buying certs for genuine domains, and no amount of
signature checking and CRLs and other PKI paraphernalia will fix that.  As
Matt Blaze once said, A commercial CA will protect you from fraud by anyone
whose money it refuses to accept, which was meant tongue-in-cheek at the time
but given current practice by phishers that's exactly what a commercial CA
will do, and no more.

It's only once developers have accepted this that you can start looking for a
real solution:

- Use TLS-PSK, which performs mutual auth of client and server without ever
  communicating the password.  This vastly complicated phishing since the
  phisher has to prove advance knowledge of your credentials in order to
  obtain your credentials (there are a pile of nitpicks that people will come
  up with for this, I can send you a link to a longer writeup that addresses
  them if you insist, I just don't want to type in pages of stuff here).

- Implement key-continuity at the client, i.e. warn if submitting a password
  or credit card number to a site you've never visited before; display the
  password in cleartext if submitting over a non-SSL connection (this is
  better than any explicit warning); (insert standard list, I have a whole
  pile of these, including responses to objections).

- Use a service like Perspectives,
  http://www.cs.cmu.edu/~perspectives/index.html, to catch here-today-gone-
  tomorrow phishing sites (this is actually a service that someone like Google
  could provide, they crawl the web anyway so keeping track of how long a
  server key's been in use should be a relatively minor change to the existing
  process.  Anyone from Google security reading this list?).

- ... and many more, I won't list them all here.

So it's a two-step process, the first of which is to admit that you have a
problem.  As EV certs have shown, we haven't really even reached that first
step yet.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Cookie Monster

2008-09-18 Thread EMC IMAP

Yet another web attack:

http://www.theregister.co.uk/2008/09/11/cookiemonstor_rampage/

Apparently, this one was found and described over a year ago by Mike  
Perry, who decided to release all the details when there was no  
significant followup.  (Sidejacking was announced at about the same  
time, and people apparently think the two attacks are the same; but  
they aren't, and mechanisms to prevent sidejacking generally don't  
block Cookie Monster.)


As I understand the attack, it's this:  Cookies can be marked Secure.   
A Secure cookie can only be returned over an HTTPS session.  An cookie  
not marked Secure can be returned over any session.  So:  If a site  
puts security-sensitive data into a non-Secure cookie, an attacker who  
can spoof DNS or otherwise grab sessions can send a HTTP page  
allegedly from the site that set the cookie asking that it be returned  
- and it will be.


It turns out hardly anyone bothers to mark their cookies secure.  In  
Firefox, if you list your cookies, you can sort on the Secure field.   
I only found a couple of cookies marked - mainly from American  
Express, one of the few sites that gets this right.  (Bank of America,  
for example, doesn't; Gmail with the new HTTPS-only setting does, but  
other Google services don't.)


My own conclusion from this:  This is yet another indication that the  
whole browser authentication model is irretrievably broken.  It's just  
way too complex, with way too many moving parts which can interact in  
dangerous ways.  The list of requirements for a safe Web application  
- even just based on attacks known today - is so long that no one can  
remember them all, much less check any substantial Web application to  
see if it follows them.


We need a better approach.
-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: once more, with feeling.

2008-09-18 Thread Darren J Moffat

Dirk-Willem van Gulik wrote:

  ... discussion on CA/cert acceptance hurdles in the UI 

I am just wondering if we need a dose of PGP-style reality here.

We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst
they all appear use the same technology - the assurances, UI, operational
regimen, 'investment' and user expectations are way different:

^^^
I seriously doubt that even a single digit percentage of end users out 
on the internet know anything about the different types of certificates 
used in SSL/TLS and what they mean.   I know none of my family (other 
than my wife: but given she worked for a large CA doing authentication 
and verification) knows what SSL really means never mind what the 
different types of cert are supposed to indicate and what to do about 
them, yet they buy stuff on the internet.  It doesn't mean they are 
ignorant it is just the normal case.



So my take is that it is pretty much impossible to get the UI to do
the right thing - until it has this information* - and even then
you have a fair chunk of education left to do :). 


Even if you got the UI to do the right thing it still doesn't mean 
anything real about trust all it really means is how much money was 
invested in getting the cert and setting up the correct information 
about the company identity behind it.



--
Darren J Moffat

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]