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 F36CC138A1F for ; Thu, 17 Apr 2014 15:51:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0EABDE0AB0; Thu, 17 Apr 2014 15:51:52 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C7691E09BA for ; Thu, 17 Apr 2014 15:51:50 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id n12so609320wgh.0 for ; Thu, 17 Apr 2014 08:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=93jSi59tjlDL2iqc/+pTVzKGXJeCRVPzEgyBowT7bIQ=; b=p+Pofvr/KTvLE/vVl/tJk4+YzcvMzoqP1pjlVqFxEfL7fq0AZUXWwRKe0XKe1fpyn1 kNyg6MyoY+YJgn5dqNGYdhKg1H2r2SD56fuGii6yTyJFM+SyNmZm2TYIYAoGbr/M2zvj 200CIHWoKoZqNUaHK4YYnYD6D4I1AnpAXV3J6XyfY5D4kSmUMvPG8jTCXaNYJp3f5w7e TLfcrbNgjH1ldKeqC7lhdbleBccEz4JbFUVkKcrWRRRBIIA99+/CCCYzznXvgL0+4xJc 4vuP7Gc2qX9rFTAylEZpDggiN3/Ph9LcT5q13m29t94PktKnQGtSNzSzlq2D40nVA/LJ 0cGA== X-Received: by 10.180.78.225 with SMTP id e1mr24878148wix.17.1397749909149; Thu, 17 Apr 2014 08:51:49 -0700 (PDT) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPSA id uy4sm25660093wjc.8.2014.04.17.08.51.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 08:51:48 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones Date: Thu, 17 Apr 2014 16:49:45 +0100 User-Agent: KMail/1.13.7 (Linux/3.12.13-gentoo; KDE/4.11.5; x86_64; ; ) References: <534E60E8.6050502@libertytrek.org> <201404170710.57224.michaelkintzios@gmail.com> <76ABA3DD-014E-42A8-B109-3D02CF20D27F@iki.fi> In-Reply-To: <76ABA3DD-014E-42A8-B109-3D02CF20D27F@iki.fi> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2190881.nXtcUTKukP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201404171649.57228.michaelkintzios@gmail.com> X-Archives-Salt: 1a8f36d9-657b-4a85-ad4c-33d9db163d96 X-Archives-Hash: f17cbfcc8361f7a8c6c6f16928e1d77c --nextPart2190881.nXtcUTKukP Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote: > On Apr 17, 2014, at 9:10, Mick wrote: > > On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote: > >> On 4/16/2014 7:14 AM, Matti Nykyri wrote: > >>> On Apr 16, 2014, at 13:52, Tanstaafl wrot= e: > >>>> Or will simply replacing my self-signed certs with the new real ones > >>>> be good enough? > >>>=20 > >>> No it will not. Keys are te ones that have been compromised. You need > >>> to create new keys. With those keys you need to create certificate > >>> request. Then you send that request to certificate authority for > >>> signing and publishing in their crl. When you receive the signed > >>> certificate you can start using it with your key. Never send your key > >>> to CA or expect to get a key from them. > >>=20 > >> Ok, thanks... > >>=20 > >> But... if I do this (create a new key-pair and CR), will this > >> immediately invalidate my old ones (ie, will my current production > >> server stop working until I get the new certs installed)? > >=20 > > You have not explained your PKI set up. Creating a new private key and > > CSR is just another private key and CSR. > >=20 > > If you replace either the private CA key on the server, or any of its > > certificates chain, but leave the path in your vhosts pointing to the o= ld > > key/certificate that no longer exist you will of course break the serve= r. > > Apache will refuse to restart and warn you about borked paths. > >=20 > >> I'm guessing not (or else there would be a lot of downtime for lots of > >> sites involved) - but I've only ever done this once (created the > >> key-pair, CR and self-signed keys) a long time ago, so want to make su= re > >> I don't shoot myself in the foot... > >=20 > > Yes, better be safe with production machines. However, don't take too > > long because your private key(s) are potentially already compromised. > >=20 > >> I have created new self-=3Dsigned certs a couple of times since creati= ng > >> the original key-pair+CR, but never created a new key-pair/CR... > >>=20 > >>> There are also other algorithms the RSA. And also if you wan't to get > >>> PFS you will need to consider your setup, certificate and security > >>> model. > >>=20 > >> What is PFS? > >>=20 > > http://en.wikipedia.org/wiki/Forward_secrecy > >=20 > > I'm no mathematical genius to understand cryptography at anything more > > than a superficial level, but I thought that ECDS, that PFS for TLS > > depends on, was compromised from inception by the NSA? Perhaps only > > some ECDS were, I am not really sure. >=20 > I don't know anything about ECDS. You probably mean ECDSA?! What i have > understood is that ECDSA is not compromised. Though I can not be certain > about that. >=20 > RSA has been in the market for a long time and the mathematics are for wh= at > i think a bit simpler. But with compromised software there was a bad > algorithm for creating the primes. So it was the keys not RSA it self. But > I think the thing that you are talking about is DHE_RSA... I read from > somewhere that it was quite compromised.. But ECDHE is not. The difference > with DH and DHE (ECDH and ECDHE) is that DH uses static keys and DHE > authenticated ephemeral keys. These temporary keys give you forward > secrecy but decrease performance. >=20 > RSA takes quite heavy computing for the same level of security compared to > ECDSA. RSA key creation is even more costly so using ephemeral temporary > keys with RSA takes quite long to compute. Thats why I prefer ECDHE_ECDSA > suites for reasonable security and fast encryption. >=20 > > I remember reading somewhere (was it Schneier?) that RSA is probably a > > better bet these days. I'd also appreciate some views from the better > > informed members of the list because there's a lot of FUD and tin hats > > flying around in the post Snowden era. >=20 > For high security application I would also use RSA in excess of 16k keys. > Then make sure to use random data and a trustworthy key-generator. > Fighting the agencies is still something I believe is virtually impossible > ;) Thanks Matti, Can you please share how you create ECDHE_ECDSA with openssl ecparam, or pi= ng=20 a URL if that is more convenient? =2D-=20 Regards, Mick --nextPart2190881.nXtcUTKukP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAABAgAGBQJTT/glAAoJELAdA+zwE4Yeqi0IAIkCivrUVdOJomscyEaefIZ+ n6CguVN9hHkRW7s7ls2lm24pgKNuG+OE3Q7n03ZvhYKp/3pccvL9TRv0dNH0Zfj9 e9G3S/Knp5j2b4GCXBXVrMgfpiOenYwkqlbK3cGxYP4Xy2WM07EZG2g8xOy3r5Be N8dbNjo86JtLitU5iClDbN2jlBg9Hm649EgW/iG7GwhNnf3aWx9giwxeAxxBeBSp GGJSQw7HqAaLk7yk3IAfvqSubCmaFn4fNReu5qZkp2aGBpts7fgv1TmIdW+5TqAs BOQ8oMzcp/EPkTIN0QetPNc7DGRdswZBP9bcbJt2lDsjtaXYzPRW+Bto+G14BS8= =VIbr -----END PGP SIGNATURE----- --nextPart2190881.nXtcUTKukP--