[security] SL comprimise

[Kurt Seifried]

My concern with this is two fold:

1) Unintentional denial of service, if we support strict SSL checks
then anytime the CA goes down we can't do anything. If we don't do
strict SSL then really, what's the point? Any attacker that can insert
their stolen/improper/etc. SSL certificate can most likely also block
our traffic to the CRL/OCSP server. Ugh.

2) Privacy. Every time I go to an SSL enabled website that CA gets to
record that I went there, what time, my IP, etc. Since I don't have a
real choice in say which SSL CA a large service like Google uses I
have to give up privacy in order to use Google services. This is
especially true for internal services that are security sensitive.
Ugh. OCSP stapling may help here.

There are some other major issues but as far as I can tell SSL is so
fundamentally broken at the design and operational level it can't be
fixed, I wrote some articles last year but gave up tilting at
windmills because it was largely having no effect.

We could do some clever things like
http://www.networknotary.org/firefox.html which help, but even as a
highly technical user even I have a tough time assigning trust/etc. to
SSL certificates presented to me because I have no idea how securely
the CA is run or how well they truly do verification (and as evidenced
by this week and articles like https://blog.startcom.org/?p=152 it's
obvious that there are some very bad worst case scenarios happening).

My one thought was rating CA's and including an indication of how
trustworthy the CA issuing the cert for a site is but that I think
just leads to information overload and people clicking "Ok".

-- 
Kurt Seifried
kurt at seifried.org
skype: 1-703-879-3176