| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 17.04.2014 17:49, Mick wrote: |
| 5 |
> On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote: |
| 6 |
>> On Apr 17, 2014, at 9:10, Mick <michaelkintzios@×××××.com> |
| 7 |
>> wrote: |
| 8 |
>>> On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote: |
| 9 |
>>>> On 4/16/2014 7:14 AM, Matti Nykyri <matti.nykyri@×××.fi> |
| 10 |
>>>> wrote: |
| 11 |
>>>>> On Apr 16, 2014, at 13:52, Tanstaafl |
| 12 |
>>>>> <tanstaafl@×××××××××××.org> wrote: |
| 13 |
>>>>>> Or will simply replacing my self-signed certs with the |
| 14 |
>>>>>> new real ones be good enough? |
| 15 |
>>>>> |
| 16 |
>>>>> No it will not. Keys are te ones that have been |
| 17 |
>>>>> compromised. You need to create new keys. With those keys |
| 18 |
>>>>> you need to create certificate request. Then you send that |
| 19 |
>>>>> request to certificate authority for signing and publishing |
| 20 |
>>>>> in their crl. When you receive the signed certificate you |
| 21 |
>>>>> can start using it with your key. Never send your key to CA |
| 22 |
>>>>> or expect to get a key from them. |
| 23 |
>>>> |
| 24 |
>>>> Ok, thanks... |
| 25 |
>>>> |
| 26 |
>>>> But... if I do this (create a new key-pair and CR), will |
| 27 |
>>>> this immediately invalidate my old ones (ie, will my current |
| 28 |
>>>> production server stop working until I get the new certs |
| 29 |
>>>> installed)? |
| 30 |
>>> |
| 31 |
>>> You have not explained your PKI set up. Creating a new private |
| 32 |
>>> key and CSR is just another private key and CSR. |
| 33 |
>>> |
| 34 |
>>> If you replace either the private CA key on the server, or any |
| 35 |
>>> of its certificates chain, but leave the path in your vhosts |
| 36 |
>>> pointing to the old key/certificate that no longer exist you |
| 37 |
>>> will of course break the server. Apache will refuse to restart |
| 38 |
>>> and warn you about borked paths. |
| 39 |
>>> |
| 40 |
>>>> I'm guessing not (or else there would be a lot of downtime |
| 41 |
>>>> for lots of sites involved) - but I've only ever done this |
| 42 |
>>>> once (created the key-pair, CR and self-signed keys) a long |
| 43 |
>>>> time ago, so want to make sure I don't shoot myself in the |
| 44 |
>>>> foot... |
| 45 |
>>> |
| 46 |
>>> Yes, better be safe with production machines. However, don't |
| 47 |
>>> take too long because your private key(s) are potentially |
| 48 |
>>> already compromised. |
| 49 |
>>> |
| 50 |
>>>> I have created new self-=signed certs a couple of times since |
| 51 |
>>>> creating the original key-pair+CR, but never created a new |
| 52 |
>>>> key-pair/CR... |
| 53 |
>>>> |
| 54 |
>>>>> There are also other algorithms the RSA. And also if you |
| 55 |
>>>>> wan't to get PFS you will need to consider your setup, |
| 56 |
>>>>> certificate and security model. |
| 57 |
>>>> |
| 58 |
>>>> What is PFS? |
| 59 |
>>>> |
| 60 |
>>> http://en.wikipedia.org/wiki/Forward_secrecy |
| 61 |
>>> |
| 62 |
>>> I'm no mathematical genius to understand cryptography at |
| 63 |
>>> anything more than a superficial level, but I thought that |
| 64 |
>>> ECDS, that PFS for TLS depends on, was compromised from |
| 65 |
>>> inception by the NSA? Perhaps only some ECDS were, I am not |
| 66 |
>>> really sure. |
| 67 |
>> |
| 68 |
>> I don't know anything about ECDS. You probably mean ECDSA?! What |
| 69 |
>> i have understood is that ECDSA is not compromised. Though I can |
| 70 |
>> not be certain about that. |
| 71 |
>> |
| 72 |
>> RSA has been in the market for a long time and the mathematics |
| 73 |
>> are for what i think a bit simpler. But with compromised software |
| 74 |
>> there was a bad algorithm for creating the primes. So it was the |
| 75 |
>> keys not RSA it self. But I think the thing that you are talking |
| 76 |
>> about is DHE_RSA... I read from somewhere that it was quite |
| 77 |
>> compromised.. But ECDHE is not. The difference with DH and DHE |
| 78 |
>> (ECDH and ECDHE) is that DH uses static keys and DHE |
| 79 |
>> authenticated ephemeral keys. These temporary keys give you |
| 80 |
>> forward secrecy but decrease performance. |
| 81 |
>> |
| 82 |
>> RSA takes quite heavy computing for the same level of security |
| 83 |
>> compared to ECDSA. RSA key creation is even more costly so using |
| 84 |
>> ephemeral temporary keys with RSA takes quite long to compute. |
| 85 |
>> Thats why I prefer ECDHE_ECDSA suites for reasonable security and |
| 86 |
>> fast encryption. |
| 87 |
>> |
| 88 |
>>> I remember reading somewhere (was it Schneier?) that RSA is |
| 89 |
>>> probably a better bet these days. I'd also appreciate some |
| 90 |
>>> views from the better informed members of the list because |
| 91 |
>>> there's a lot of FUD and tin hats flying around in the post |
| 92 |
>>> Snowden era. |
| 93 |
>> |
| 94 |
>> For high security application I would also use RSA in excess of |
| 95 |
>> 16k keys. Then make sure to use random data and a trustworthy |
| 96 |
>> key-generator. Fighting the agencies is still something I believe |
| 97 |
>> is virtually impossible ;) |
| 98 |
> |
| 99 |
> Thanks Matti, |
| 100 |
> |
| 101 |
> Can you please share how you create ECDHE_ECDSA with openssl |
| 102 |
> ecparam, or ping a URL if that is more convenient? |
| 103 |
> |
| 104 |
|
| 105 |
I don't think you realy want DSA, but here it is for DH, EC and DSA: |
| 106 |
|
| 107 |
openssl genpkey -genparam -algorithm DH \ |
| 108 |
-pkeyopt dh_paramgen_prime_len:4096 \ |
| 109 |
-out /path/dh_params.pem |
| 110 |
openssl genpkey -genparam -algorithm EC \ |
| 111 |
-pkeyopt ec_paramgen_curve:secp384r1 \ |
| 112 |
-out /path/ec_params.pem |
| 113 |
openssl genpkey -genparam -algorithm DSA \ |
| 114 |
-pkeyopt dsa_paramgen_bits:1024 \ |
| 115 |
-out /path/dsa_params.pem |
| 116 |
|
| 117 |
|
| 118 |
- -- |
| 119 |
Kind Regards, Mit freundlichen Grüssen, |
| 120 |
Markus Kohlmeyer Markus Kohlmeyer |
| 121 |
|
| 122 |
PGP: 0xEBDF5E55 / 2A22 1F71 AA70 1AD1 231B 0178 759F 407C EBDF 5E55 |
| 123 |
|
| 124 |
-----BEGIN PGP SIGNATURE----- |
| 125 |
Version: GnuPG v2.0.22 (MingW32) |
| 126 |
|
| 127 |
iQIcBAEBCgAGBQJTUAcrAAoJEHWfQHzr315VTxUP/0KdnN2CBvcQe7qOKEcnXkNq |
| 128 |
p5DzcBFacq9Opp3/ICUZ21yLla/YA+QuiEoSOQS859xkFnqCVrAOvOLsVS7GJfTG |
| 129 |
jUUWUEsd6YoxWGZql+m4P92HzTnL1cQAfc2kcd8vI6d0jCDqo3iLBcLwVuV/efz2 |
| 130 |
qtagFyIeFPAgGQ1RmTptIqc28IL8ugbL8HqePuc5pM8pOyfj7qwHI+64vVKiO+Xu |
| 131 |
S+orO9nFtDnM7crTz68722qE4+58hj4q/w0N6Uuw8SJbFCDcaal063Ba2WSh+UHm |
| 132 |
GBXidaK2eVdyTzzPx0rvkxMtD9sVb6WTZZ/gBwtJUNZ5WTinvjmQNDqkyWRxHeXP |
| 133 |
e4m3mJCB36gdgjjy/0Kmt78otYblVkmI+JYRI4fH3l9fxT14FNuXq63R7aZuFEw2 |
| 134 |
BiwmR+naf2sxkiAhy/szybfqAmeVGKjEAqlDZkzEz6tlO6SwKkYBpc1QS139QHUN |
| 135 |
bK++/bhzIh/yNEQjHIhEaMXmRTco+6fdASaq0h4r1mm5A8o0SCSJnNKp4G6ZC1SV |
| 136 |
kuuYfiSHxpRZ0RoLUsFSZM7oki/j2Q1KYZys917/sLzLeOv2US2ScliEZD5w+mF0 |
| 137 |
e1cqudLoYP9TSkF/3r/ac5yF6gR4ye1eDEdCFeG2ktq8Ru/JlviiNAspSlm2OOAz |
| 138 |
kFKkM0cJWaZ/mAuXrrfY |
| 139 |
=GSjk |
| 140 |
-----END PGP SIGNATURE----- |
Archives