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 [email protected] skype: 1-703-879-3176 _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
