On 06/11/13 08:00 PM, Michael Orlitzky wrote:
> On 11/06/2013 02:11 PM, Thomas D. wrote:
> 
>> 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:
> 
> I figure everyone here is smart enough to google "OCSP" before
> unchecking the box. This isn't the place to argue that the CA system
> is broken, but I will respond to a few points.

I figure everyone here is smart enough not to spread knowingly-incorrect
propaganda.

> 
>> 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:
> 
>> ...
> 
>> 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.
> 
> 
> 
>> 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.
> 
> This is a long way of saying "it sends the address of every website
> you visit to a third party."

Addresses, in the context of web browsing, are commonly understood to
mean URLs, which include protocol, name, port, and path.

OCSP only sends the "name" portion. Thus, the statement was a long way
of saying "you are wrong.".

> 
> 
>> 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.
> 
> That's cool, but it doesn't exist now and won't for years. And as a
> visitor you have no way of knowing whether the server supports it (==
> your privacy will be kept).

DH3, and incorrect. Firefox, Apache, and nginx all support OCSP stapling
RIGHT NOW.

> 
>> 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.

Not necessarily. "Your" name server may in fact not be a recursive name
server, but delegate some portion to a recursive name server.

> 
>> 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.

You're conflating two things here. If you trust the CA, you trust them
not to perform a MitM attack.

> 
>> 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.
> 

False dichotomy.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to