Hi, Michael Orlitzky wrote: >> If you are aware about any other know attacks, please share. > > Replay attacks, mentioned in the RFC (or Google). These could be > mitigated, but no one has bothered.
The OCSP response is signed. The signature contains a time stamp. If your clock is right, replay attacks are only possible for the expected lifespan of the response. But because it is expected that an OCSP response is valid for x hours, it is not a real problem. But sadly there are some CA which are serving pre-generated OCSP responses which are valid for 7 days (like their CRLs). 7 days can be very long... :( > This is a long way of saying "it sends the address of every website > you visit to a third party." See Alex's reply. I wanted to make it clear to everyone, that the address isn't the full URL. >> 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? :) > > Only two DNS servers are involved; mine and those of the domain I'm > visiting. Again, please see Alex's reply. Also, if you are using your *own* DNS server, you are *special*. But most people will use the DNS server from their ISP. And I wasn't talking about *special* people who are able to run everything in their own trusted environment. >> Also, you are trusting a CA to secure your connections, but you >> don't trust the same CA due to privacy concerns? > > You're conflating two things here. I trust AES to keep my connection > safe. I don't send my data to the CA. CAs not only issue certificates. They should also make sure that they only issue "secure" certificates: - Require a secure signing algorithm - Require a secure key size You could use the best algorithm available. But if the certificate's private key is shared with others, others are able to decrypt the captured secure traffic. The CAB forum for example says that no CA is allowed to create the key used for any issued customer certificate. So when you are using a pre-populated list of trusted CAs you are also expecting that these CAs are doing their jobs right. IF you don't do that, you shouldn't use them. >> If you don't trust any CA, we don't have to talk about things like >> OCSP or CRL and revocation... > > Well there we agree. Why would you trust the CAs? You don't know them > personally and you aren't their customer. > > Do you trust the governments of the USA and China? (Hint: you > shouldn't.) If the answer is no, then you don't trust the CA system. > So whether or not you trust them to revoke that authentication is a > moot point. Well, that's another discussion. As said before, we don't have to talk about these things if you don't trust a system called "Web of trust" :) But because most people "live" in this (broken) system (this is reality!), do you still think telling them they should disable OCSP, which will actually disable an important feature (again, without OCSP you are unable to check a certificate for revocation in Firefox) and make them vulnerable to a new threat is a good thing? -- Regards, Thomas
signature.asc
Description: OpenPGP digital signature
