Re: following on from today's discussion

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Roger Dingledine (arma@xxxxxxx):

> Correct. Woe is the day when a malicious Tor exit node also has a stolen
> or purchased copy of a trusted CA's key.

Eeep.

> The next thing we need to do is continue to work on interfaces and
> usability for end-user applications like Firefox. What does that
> lock mean really? If I do (or don't) see the lock, what should I
> trust?  How can we make use of the plethora of anti-phishing schemes
> currently under research?
> 
> And lastly, there's the issue of advocacy for authentication,
> integrity, and confidentiality on the Internet in general.
> Translation: we need to get everybody using SSL for everything.

Time for a nice tinfoil-amplified SSL rant..

Is anyone in the world actively watching and tracking SSL certs beyond
simply verifying CA key signatures?  By looking at teh OCSP RFC
(http://rfc.sunsite.dk/rfc/rfc2560.html) it appears as if you are hard
pressed to tell if a cert is a dup or not:

'The "good" state indicates a positive response to the status inquiry.
At a minimum, this positive response indicates that the certificate is
not revoked, but does not necessarily mean that the certificate was
ever issued or that the time at which the response was produced is
within the certificate's validity interval.'

I mean good goddess. So even if you are watching for revokations, you
are only handling half of the SSL threat model... Some form of
ssh-like fingerprint tracking really needs to be coupled with
CRL-style checks so that you only accept a different cert than normal
for citibank.com if a revocation has been actually issued by them.
Especially when we have over 100 root certs spanning multiple
countries trusted by most browsers now.

To add insult to injury, the only public OCSP server I can find seems
completely broken. Everything comes back with 'unknown' with bad
timestamps. Yes, even their demo key.

http://www.openvalidation.org/en/info/openssl.html


This client seems to be somehow issuing correct queries to verisign's
OCSP according to ethereal (even though it is configured to use
openvalidation.org), but the UI reports the same 'unknown' status as
'openssl ocsp' did:

http://www.openvalidation.org/ValWorks.html

Madness. 

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs