Gentoo Archives: gentoo-user

From: Mick <michaelkintzios@×××××.com>
To: 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 15:51:57
Message-Id: 201404171649.57228.michaelkintzios@gmail.com
In Reply to: Re: [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones by Matti Nykyri
1 On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote:
2 > On Apr 17, 2014, at 9:10, Mick <michaelkintzios@×××××.com> wrote:
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
7 > >>>> be 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
23 > > CSR is 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 > >> I'm guessing not (or else there would be a lot of downtime for lots of
31 > >> sites involved) - but I've only ever done this once (created the
32 > >> key-pair, CR and self-signed keys) a long time ago, so want to make sure
33 > >> I don't shoot myself in the foot...
34 > >
35 > > Yes, better be safe with production machines. However, don't take too
36 > > long because your private key(s) are potentially already compromised.
37 > >
38 > >> I have created new self-=signed certs a couple of times since creating
39 > >> the original key-pair+CR, but never created a new key-pair/CR...
40 > >>
41 > >>> There are also other algorithms the RSA. And also if you wan't to get
42 > >>> PFS you will need to consider your setup, certificate and security
43 > >>> model.
44 > >>
45 > >> What is PFS?
46 > >>
47 > > http://en.wikipedia.org/wiki/Forward_secrecy
48 > >
49 > > I'm no mathematical genius to understand cryptography at anything more
50 > > than a superficial level, but I thought that ECDS, that PFS for TLS
51 > > depends on, was compromised from inception by the NSA? Perhaps only
52 > > some ECDS were, I am not really sure.
53 >
54 > I don't know anything about ECDS. You probably mean ECDSA?! What i have
55 > understood is that ECDSA is not compromised. Though I can not be certain
56 > about that.
57 >
58 > RSA has been in the market for a long time and the mathematics are for what
59 > i think a bit simpler. But with compromised software there was a bad
60 > algorithm for creating the primes. So it was the keys not RSA it self. But
61 > I think the thing that you are talking about is DHE_RSA... I read from
62 > somewhere that it was quite compromised.. But ECDHE is not. The difference
63 > with DH and DHE (ECDH and ECDHE) is that DH uses static keys and DHE
64 > authenticated ephemeral keys. These temporary keys give you forward
65 > secrecy but decrease performance.
66 >
67 > RSA takes quite heavy computing for the same level of security compared to
68 > ECDSA. RSA key creation is even more costly so using ephemeral temporary
69 > keys with RSA takes quite long to compute. Thats why I prefer ECDHE_ECDSA
70 > suites for reasonable security and fast encryption.
71 >
72 > > I remember reading somewhere (was it Schneier?) that RSA is probably a
73 > > better bet these days. I'd also appreciate some views from the better
74 > > informed members of the list because there's a lot of FUD and tin hats
75 > > flying around in the post Snowden era.
76 >
77 > For high security application I would also use RSA in excess of 16k keys.
78 > Then make sure to use random data and a trustworthy key-generator.
79 > Fighting the agencies is still something I believe is virtually impossible
80 > ;)
81
82 Thanks Matti,
83
84 Can you please share how you create ECDHE_ECDSA with openssl ecparam, or ping
85 a URL if that is more convenient?
86
87 --
88 Regards,
89 Mick

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies