Gentoo Archives: gentoo-user

From: Matti Nykyri <matti.nykyri@×××.fi>
To: "gentoo-user@l.g.o" <gentoo-user@l.g.o>
Subject: Re: [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones
Date: Thu, 17 Apr 2014 14:40:37
Message-Id: 76ABA3DD-014E-42A8-B109-3D02CF20D27F@iki.fi
In Reply to: Re: [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones by Mick
1 On Apr 17, 2014, at 9:10, Mick <michaelkintzios@×××××.com> wrote:
2
3 > On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote:
4 >> On 4/16/2014 7:14 AM, Matti Nykyri <matti.nykyri@×××.fi> wrote:
5 >>> On Apr 16, 2014, at 13:52, Tanstaafl <tanstaafl@×××××××××××.org> wrote:
6 >>>> Or will simply replacing my self-signed certs with the new real ones be
7 >>>> good enough?
8 >>>
9 >>> No it will not. Keys are te ones that have been compromised. You need
10 >>> to create new keys. With those keys you need to create certificate
11 >>> request. Then you send that request to certificate authority for
12 >>> signing and publishing in their crl. When you receive the signed
13 >>> certificate you can start using it with your key. Never send your key
14 >>> to CA or expect to get a key from them.
15 >>
16 >> Ok, thanks...
17 >>
18 >> But... if I do this (create a new key-pair and CR), will this
19 >> immediately invalidate my old ones (ie, will my current production
20 >> server stop working until I get the new certs installed)?
21 >
22 > You have not explained your PKI set up. Creating a new private key and CSR is
23 > just another private key and CSR.
24 >
25 > If you replace either the private CA key on the server, or any of its
26 > certificates chain, but leave the path in your vhosts pointing to the old
27 > key/certificate that no longer exist you will of course break the server.
28 > Apache will refuse to restart and warn you about borked paths.
29 >
30 >
31 >> I'm guessing not (or else there would be a lot of downtime for lots of
32 >> sites involved) - but I've only ever done this once (created the
33 >> key-pair, CR and self-signed keys) a long time ago, so want to make sure
34 >> I don't shoot myself in the foot...
35 >
36 > Yes, better be safe with production machines. However, don't take too long
37 > because your private key(s) are potentially already compromised.
38 >
39 >
40 >> I have created new self-=signed certs a couple of times since creating
41 >> the original key-pair+CR, but never created a new key-pair/CR...
42 >>
43 >>> There are also other algorithms the RSA. And also if you wan't to get
44 >>> PFS you will need to consider your setup, certificate and security
45 >>> model.
46 >>
47 >> What is PFS?
48 >
49 > http://en.wikipedia.org/wiki/Forward_secrecy
50 >
51 > I'm no mathematical genius to understand cryptography at anything more than a
52 > superficial level, but I thought that ECDS, that PFS for TLS depends on, was
53 > compromised from inception by the NSA? Perhaps only some ECDS were, I am not
54 > really sure.
55
56 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.
57
58 RSA has been in the market for a long time and the mathematics are for what 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.
59
60 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.
61
62 > I remember reading somewhere (was it Schneier?) that RSA is probably a better
63 > bet these days. I'd also appreciate some views from the better informed
64 > members of the list because there's a lot of FUD and tin hats flying around in
65 > the post Snowden era.
66
67 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 ;)
68
69 --
70 -Matti

Replies