Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts
On Wed, Nov 6, 2013 at 7:36 PM, Alex Xu wrote: > 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. >>> 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.". A bit of additional consideration: Given the above statement and RFC 2560, OCSP sends the certificate serial, not the name. With the availability of "Wildcard" certificates and the subjectAltName parameter, with many certificates that serial will not let the CA actually know which domain you are visiting.
Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OCSP Was: friendly reminder wrt net virtual in init scripts
Hi, Duncan wrote: > Meanwhile, another question for Thomas. Is this "certificate stapling" > the same thing google chrome is now doing for the google site, that > enabled it to detect the (I think it was) Iranian and/or Chinese CA > tampering, allowing them to say a "google" cert was valid that was > actually their MitM cert, as appeared in the tech-news a few months ago? > Or was that something different? > > I had interpreted (well, I think I read, but either the journalist could > have been mixed up too, or maybe I was misinterpreting what I read, > either way the effect on my understanding is the same) the "certificate > stapling" referred to at the time as indicating that google configured > the certs for their own sites into chrome as shipped itself, effectively > hard-coding them, NOT as google handling its own OCSP requests, as OCSP > cert stapling does. So now I'm wondering if I interpreted wrong then, or > if there's actually two different things being referred to as certificate > stapling, here. No, OCSP Stapling is something else. Guess you are talking about HSTS and "SSL pinning" [1,2]: In Google Chrome, they hard coded some certificates/certificate meta data [3] which must be present in every certificate used for any Google site. If you connect to a Google site for example and this site will use a certificate from a CA not specified in [3] (depending on the service, they may also verify against a list of known fingerprints like EV SSL is working), connection will be terminated and the browser will send some details to Google so they get noticed. See also: = [1] http://blog.chromium.org/2011/06/new-chromium-security-features-june.html [2] https://www.imperialviolet.org/2011/05/04/pinning.html [3] http://www.googblogs.com/uncategorized/changes-to-our-ssl-certificates/ -- Regards, Thomas signature.asc Description: OpenPGP digital signature
