1 |
On Thu, Apr 17, 2014 at 04:49:45PM +0100, Mick wrote: |
2 |
> On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote: |
3 |
> > On Apr 17, 2014, at 9:10, Mick <michaelkintzios@×××××.com> wrote: |
4 |
> > > On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote: |
5 |
> > >> On 4/16/2014 7:14 AM, Matti Nykyri <matti.nykyri@×××.fi> wrote: |
6 |
> > >>> On Apr 16, 2014, at 13:52, Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
7 |
> > >>>> Or will simply replacing my self-signed certs with the new real ones |
8 |
> > >>>> be good enough? |
9 |
> > >>> |
10 |
> > >>> No it will not. Keys are te ones that have been compromised. You need |
11 |
> > >>> to create new keys. With those keys you need to create certificate |
12 |
> > >>> request. Then you send that request to certificate authority for |
13 |
> > >>> signing and publishing in their crl. When you receive the signed |
14 |
> > >>> certificate you can start using it with your key. Never send your key |
15 |
> > >>> to CA or expect to get a key from them. |
16 |
> > >> |
17 |
> > >> Ok, thanks... |
18 |
> > >> |
19 |
> > >> But... if I do this (create a new key-pair and CR), will this |
20 |
> > >> immediately invalidate my old ones (ie, will my current production |
21 |
> > >> server stop working until I get the new certs installed)? |
22 |
> > > |
23 |
> > > You have not explained your PKI set up. Creating a new private key and |
24 |
> > > CSR is just another private key and CSR. |
25 |
> > > |
26 |
> > > If you replace either the private CA key on the server, or any of its |
27 |
> > > certificates chain, but leave the path in your vhosts pointing to the old |
28 |
> > > key/certificate that no longer exist you will of course break the server. |
29 |
> > > Apache will refuse to restart and warn you about borked paths. |
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 |
37 |
> > > long because your private key(s) are potentially already compromised. |
38 |
> > > |
39 |
> > >> I have created new self-=signed certs a couple of times since creating |
40 |
> > >> the original key-pair+CR, but never created a new key-pair/CR... |
41 |
> > >> |
42 |
> > >>> There are also other algorithms the RSA. And also if you wan't to get |
43 |
> > >>> PFS you will need to consider your setup, certificate and security |
44 |
> > >>> model. |
45 |
> > >> |
46 |
> > >> What is PFS? |
47 |
> > >> |
48 |
> > > http://en.wikipedia.org/wiki/Forward_secrecy |
49 |
> > > |
50 |
> > > I'm no mathematical genius to understand cryptography at anything more |
51 |
> > > than a superficial level, but I thought that ECDS, that PFS for TLS |
52 |
> > > depends on, was compromised from inception by the NSA? Perhaps only |
53 |
> > > some ECDS were, I am not really sure. |
54 |
> > |
55 |
> > I don't know anything about ECDS. You probably mean ECDSA?! What i have |
56 |
> > understood is that ECDSA is not compromised. Though I can not be certain |
57 |
> > about that. |
58 |
> > |
59 |
> > RSA has been in the market for a long time and the mathematics are for what |
60 |
> > i think a bit simpler. But with compromised software there was a bad |
61 |
> > algorithm for creating the primes. So it was the keys not RSA it self. But |
62 |
> > I think the thing that you are talking about is DHE_RSA... I read from |
63 |
> > somewhere that it was quite compromised.. But ECDHE is not. The difference |
64 |
> > with DH and DHE (ECDH and ECDHE) is that DH uses static keys and DHE |
65 |
> > authenticated ephemeral keys. These temporary keys give you forward |
66 |
> > secrecy but decrease performance. |
67 |
> > |
68 |
> > RSA takes quite heavy computing for the same level of security compared to |
69 |
> > ECDSA. RSA key creation is even more costly so using ephemeral temporary |
70 |
> > keys with RSA takes quite long to compute. Thats why I prefer ECDHE_ECDSA |
71 |
> > suites for reasonable security and fast encryption. |
72 |
> > |
73 |
> > > I remember reading somewhere (was it Schneier?) that RSA is probably a |
74 |
> > > better bet these days. I'd also appreciate some views from the better |
75 |
> > > informed members of the list because there's a lot of FUD and tin hats |
76 |
> > > flying around in the post Snowden era. |
77 |
> > |
78 |
> > For high security application I would also use RSA in excess of 16k keys. |
79 |
> > Then make sure to use random data and a trustworthy key-generator. |
80 |
> > Fighting the agencies is still something I believe is virtually impossible |
81 |
> > ;) |
82 |
> |
83 |
> Thanks Matti, |
84 |
> |
85 |
> Can you please share how you create ECDHE_ECDSA with openssl ecparam, or ping |
86 |
> a URL if that is more convenient? |
87 |
|
88 |
Select curve for ECDSA: |
89 |
openssl ecparam -out ec_param.pem -name secp521r1 |
90 |
|
91 |
Create your own CA certificate and associated new pkey: |
92 |
openssl req -new -x509 -extensions v3_ca -newkey ec:ec_param.pem -keyout private/cakey.pem -out cacert.pem -days 3650 -config ./openssl.cnf |
93 |
|
94 |
#create cert request and new pkey: |
95 |
openssl req -new -nodes -out req.pem -newkey ec:ec_param.pem -config ./openssl.cnf |
96 |
|
97 |
#sign cert with your CAcert: |
98 |
openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem |
99 |
|
100 |
#create crl for all certificate requests you have signed with your CAcert: |
101 |
openssl ca -gencrl -crldays 31 -config ./openssl.cnf -out rootca.crl |
102 |
|
103 |
#revoke certificate: |
104 |
openssl ca -revoke newcerts/<serial>.pem -config ./openssl.cnf |
105 |
|
106 |
|
107 |
Modify openssl.cnf to suite your setup. With this setup you |
108 |
will get the newest fastest and most secure cipher by public |
109 |
sources: |
110 |
|
111 |
ECDHE-ECDSA-AES256-GCM-SHA384 |
112 |
|
113 |
I don't know much about the secp521r1 curve or about its security. |
114 |
You can list all available curves by: |
115 |
|
116 |
openssl ecparam -list_curves |
117 |
|
118 |
|
119 |
With this setup apache and postfix works great. You can test my server |
120 |
with this URL: |
121 |
|
122 |
https://www.ssllabs.com/ssltest/analyze.html?d=nykyri.eu&hideResults=on |
123 |
|
124 |
So these ciphers are supported: |
125 |
|
126 |
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH 256 bits (eq. 3072 bits RSA) FS 256 |
127 |
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH 256 bits (eq. 3072 bits RSA) FS 128 |
128 |
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH 256 bits (eq. 3072 bits RSA) FS 256 |
129 |
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH 256 bits (eq. 3072 bits RSA) FS 128 |
130 |
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH 256 bits (eq. 3072 bits RSA) FS 256 |
131 |
|
132 |
I still have alternate names not setup and few other things neew changing |
133 |
with the certificates, but this might change during Easter :) |
134 |
|
135 |
The tutorial I mentioned before is here: |
136 |
http://www.eclectica.ca/howto/ssl-cert-howto.php |
137 |
|
138 |
The one problem I have is that no matter what I have failed to get |
139 |
courier to support ECDHE. Courier needs the DHparams for ephemeral |
140 |
keys to work, but I have failed to set it up... so there I have |
141 |
TLS_ECDH_ECDSA_WITH_256_GCM_SHA384 :/ Will continue trying... |
142 |
|
143 |
To create dhparameters: |
144 |
openssl dhparam -out dhparam.pem 4096 |
145 |
|
146 |
And you will find openssl.cnf attached :) Create a directory and put |
147 |
it there. Under that create directories private, newcerts. Then create |
148 |
files: |
149 |
|
150 |
echo 01 > serial |
151 |
touch index.txt |
152 |
|
153 |
-- |
154 |
-Matti |