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 41853138247 for ; Thu, 7 Nov 2013 01:00:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 65267E0A45; Thu, 7 Nov 2013 01:00:23 +0000 (UTC) Received: from mail2.viabit.com (mail2.viabit.com [65.246.80.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7EA64E09F7 for ; Thu, 7 Nov 2013 01:00:22 +0000 (UTC) Received: from [172.17.29.6] (vpn1.metro-data.com [65.213.236.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.viabit.com (Postfix) with ESMTPSA id 3dFR9d3WF9z3PyD for ; Wed, 6 Nov 2013 20:00:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orlitzky.com; s=mail2; t=1383786021; bh=xJbz/5LX9FUvqa3FbZQJmluDhCkERR62w8P/dQqbxKU=; h=Date:From:To:Subject:References:In-Reply-To; b=UoQWc31U9OVZIgDN/3SD3q6T3Kk6JkA5vTJZRTQF1gQLarTnIZa7alEGK+64W1GEy Gl4MV+N9I+MkSkQpoEezwkiHYMFpZGdozZTqUi4ncElSLoI1K4Kgpto3lDas3YI3mB fimsPWNKtQE85Efx+hY6V4MozC3v5eECBIU8NDXc= Message-ID: <527AE624.7020201@orlitzky.com> Date: Wed, 06 Nov 2013 20:00:20 -0500 From: Michael Orlitzky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130929 Thunderbird/17.0.9 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts References: <20131105033007.GA23263@linux1> <20131105144915.GM22282@server> <52791F2E.2020704@orlitzky.com> <527A9478.10208@whissi.de> In-Reply-To: <527A9478.10208@whissi.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: dc0971ed-0e21-4d0a-bf1f-885fd76df80e X-Archives-Hash: b643a26ae4844ca917b28109a7848013 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > 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." > 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). > 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. > 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. > 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJSeuYkAAoJEBxJck0inpOigpUP/3AqhOXf3D5nPzHZumJw9iv6 /9eXu2MMgoZTdwILAc0GnlSwnstTgaI/WZYFHRsU24DQsCQxCMr8VnJnirRNv0Zz EB+fu3i991e85BloxaZaC3nDcJ5cDB3WjEOfUi4adHVEaY71eAKlwge2P9jG2t9B 60HslYxK9pBhmCzqfpxViunSZV36w4mGOSB9X8ajagkklW4BGzP508czzX0KU/HH zBxhRxowuLKzIKQZ0R996bEk7b0STadNbTllSyF4850Iftm9Aj+smYHXmbO5wT1I lYWJGP11bAZfbObstG+ZepST98FxsZGke80LicydNIvZ13tnqYLYERYdxb9GVMB/ /hO4wi53ltvEtb6/7uy/ec3jg5x8V3e6ZidHu/4ObToYZF4gzsNZ8agLazFEHA54 Xpk3+nh8ypJPBdBiJZuuYQckUFwXzTpEXqpfb5X6c38F6pOxNElexuAa57coIqoy M8ZsMoTr3oCYsRC5lRFmb6uv9WZZDi6iRSTh5z78fzxc3/ynF7SYmJIQEIKzZDnn FxEAjjhLrJtFCkfFWd1GaIJjrwLjcX+laMJrx6zqkjG3BvQRGTvO2md5m7WoX0v9 0MmxfMsjkQpDV7e/w4gxNG6aZzf1kvBZXPhdFuLJM1NEbD40xoJC90E+y9LsENbV ++m0ObSQf+JfCMcqH0BS =PbZR -----END PGP SIGNATURE-----