Hi, Michael Orlitzky wrote: > You should disable OCSP anyway. In Firefox, it's under, > > Edit -> Preferences -> Advanced -> Encryption -> Validation > > The OCSP protocol is itself is vulnerable to MITM attacks, which is cute > when you consider its purpose. > > Moreover, it sends the address of every website you visit to a third > party, which is the real reason to disable it IMO.
This is going OT but I cannot leave this statement uncommented, because from my knowledge this is wrong/you are hiding important information everyone should know about: First, if you tell people they should disable OCSP you should also tell these people the consequences: When you disable OCSP in Firefox, there is *no* other way to know if a certificate was revoked or not. This is because Firefox *never* downloaded any CRLs. Furthermore, they removed the possibility to do that [1,2]. If you don't have the possibility to check a certificate for revocation, the whole trust system cannot work because there is no way to tell someone "Yes, it is nice that you trust me (=you trust the CA) and I said you can trust this certificate (=the CA you trust has signed the certificate in question) but now I changed my mind (=the CA has revoked the certificate) so please don't trust this certificate anymore." Please read "Would you knowingly trust an irrevocable SSL certificate?" [3]. And yes, this is a *real* problem, see [7]. Yes, there is a known MITM attacks against OCSP, see [4]. But this is only possible due to bad default settings: Just change your OCSP setting to *require* a valid answer. In Firefox: Edit -> Preferences -> Advanced -> Certificates -> Validation Make sure When an OCSP server connection fails, treat the certificate as invalid is checked (or you can just set "security.OCSP.require" to "TRUE"). If you are aware about any other know attacks, please share. Regarding your privacy concerns: No, your OCSP-enabled browser won't share the address (URL) with the OCSP responder. Your browser will use the site's certificate serial number to ask the OCSP responder if the certificate is still valid. Yes, the company who is running the OCSP responder is able to log "You [IP, UA...] requested status for certificates with the serial number 0x1, 0x2, 0x3" and because the OCSP responder needs some basic knowledge about the certificates it should provide answers for, the operator may know that the certificate with the serial number 0x1 has the Common Name (CN) "www.mysecretsite.invalid" and 0x2 was issued for "www.mydarksecrets.invalid" or 0x3 was for "www.facebook.com", but the operator doesn't know the URL you visited. I don't say OCSP is perfect. For example an OCSP check will delay the initial SSL handshake, because your browser has to connect to the OCSP responder when it has received the certificate from the server you are connecting to. Depending on your connection and the OCSP responder, this may take some time [5]. But the CRL system doesn't work anymore (and was never working in Firefox, unless you manually added all the CRL distribution points for your CA and Sub CAs...), because VerSign and other big SSL companies are providing >20 MB CRLs. Imagine you would use your phone to visit a website using some kind of mobile connection and it would have to fetch 50+ MBs in CRLs before the website will open... Google for example decided some time ago to disable CRL checks too. They will download CRLs for you and are planing to release these centralized CRLs with normal updates. See [6]. They are improving OCSP. The next big thing is OCSP stapling [8,9] which is now supported by all major browsers and patches are available for most web servers. OCSP stapling was developed to save the extra round trip to the OCSP responder, but OCSP stapling-enabled websites will also "increase" your privacy, because you don't longer have to tell the OCSP responder the certificate (CN) you want to check. If you are still really concerned about what OCSP may do to your privacy, may I ask if you are also concerned about DNS servers? If not, what's the difference between an OCSP responder which you ask for a serial number, which can be resolved to a CN and a DNS server which you ask for a ... CN? :) Also, you are trusting a CA to secure your connections, but you don't trust the same CA due to privacy concerns? So please, don't just tell anybody to turn off OCSP. Tell them why you may think they should do that. But also tell them about the new risks they have to deal with so that they are able to decide on their own if they want to disable OCSP or not. PS: As long as you are trusting CAs and don't manage the trust of any certificate you are using on your own I recommend to enable OCSP in all your browsers and to treat any kind of invalid OCSP responses as a hard failure, because I want to know if I can trust the certificate used to secure my communication or not. If you don't trust any CA, we don't have to talk about things like OCSP or CRL and revocation... See also: ========= [1] http://thread.gmane.org/gmane.comp.mozilla.firefox.devel/290 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=867465 [3] http://news.netcraft.com/archives/2013/05/23/would-you-knowingly-trust-an-irrevocable-ssl-certificate.html [4] http://www.thoughtcrime.org/papers/ocsp-attack.pdf [5] http://uptime.netcraft.com/perf/reports/OCSP [6] https://isc.sans.edu/diary/Chrome+to+stop+checking+Certificate+Revocation+List+%28CRL%29%3F/12556 [7] http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html [8] https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ [9] https://casecurity.org/2013/02/14/certificate-revocation-and-ocsp-stapling/ -- Regards, Thomas
signature.asc
Description: OpenPGP digital signature
