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 |