From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4625B138247 for ; Wed, 6 Nov 2013 20:13:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 29B21E09C2; Wed, 6 Nov 2013 20:13:39 +0000 (UTC) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 31D0CE09F3 for ; Wed, 6 Nov 2013 20:13:37 +0000 (UTC) Received: from localhost (66-208-231-133.ubr01a.rte20201.pa.hfc.comcastbusiness.net [66.208.231.133]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lg1bf-1VxWmy0LUZ-00pXFH; Wed, 06 Nov 2013 15:13:36 -0500 Date: Wed, 6 Nov 2013 14:13:34 -0600 From: mingdao To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts Message-ID: <20131106201334.GD22282@server> References: <20131105033007.GA23263@linux1> <20131105144915.GM22282@server> <52791F2E.2020704@orlitzky.com> <527A9478.10208@whissi.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527A9478.10208@whissi.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V02:K0:9xTT+55h+/wrLmjKudnRKN13b08Z5ZBo876LfdbJGZx 4O+nfYXv7UbUKkNOGBo5/Bvn6ZbThwttQrQEefbB7zMtYKMoZg ri2tPxP5Yksp4qZvmszpy6g6YZIy2w6AMw2+ibHlYTQH4KAP5B XeJrJEjlgBObbYoaTXlmS0diUSCPzMYPAPMIbDf4YUXNr1A803 7j+qa+NbpMOEeHfxtFgtUMoSto3dAjW6zGhsDcQITV9/TPjjHY oi/7ptLAKvS8Lu15kt7BpZmGF7FsPXWuP2E3NMWy9tQp3DkUi4 njJ9yAy8+XiLhDf+EpgAP8tSH5yzZoBHBC3tzh7wnz/cEyPb64 OYmplb6GXWGKYS50Eqe3O4kmtjrg+Ijoou4vZJtis X-Archives-Salt: 64cee5b6-ace5-4e83-ad37-6e57e83751d3 X-Archives-Hash: 5167a6749cb92c7a51615a145dde1f6b On Wed, Nov 06, 2013 at 08:11:52PM +0100, Thomas D. wrote: > 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 Thanks for the detailed explanation, Thomas. Now, if any one of us turned off OCSP as Michael suggested, what should one do after turning it back on? Could there now be certificates trusted there which should not be? -- Happy Penguin Computers >') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ support@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting