Re: [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones

[Joe User <mailinglists@rootservice.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 19.04.2014 13:51, Mick wrote:
> On Thursday 17 Apr 2014 19:43:25 Matti Nykyri wrote:
>> On Thu, Apr 17, 2014 at 04:49:45PM +0100, Mick wrote:
> 
>>> Can you please share how you create ECDHE_ECDSA with openssl
>>> ecparam, or ping a URL if that is more convenient?
>> 
>> Select curve for ECDSA: openssl ecparam -out ec_param.pem -name
>> secp521r1
> [snip ...]
> 
>> I don't know much about the secp521r1 curve or about its
>> security.
> [snip ...]
> 
> It seems that many sites that use ECDHE with various CA signature
> algorithms (ECC as well as conventional symmetric) use the
> secp521r1 curve - aka P-256. I just checked and gmail/google
> accounts use it too.
> 
> Markus showed secp384r1 (P-384) in his example.
> 
> The thing is guys that both of these are shown as 'unsafe' in the 
> http://safecurves.cr.yp.to tables and are of course specified by
> NIST and NSA.
> 
> Thank you both for your replies.  I need to read a bit more into
> all this before I settle on a curve.
> 

1.) secp521r1 is *not* P-256
2.) I used secp384r1 aka P-384 as it's defined by RFC 6460 while
    secp521r1 is not, and all TLS1.2 implementations implement
    secp256r1 and secp384r1 as defined in RFC 6460, while secp521r1
    is implemented only by some. So better to be RFC compliant and
    reach all possible users/customers as to violate the RFC and
    loose possible users/customers.
    https://tools.ietf.org/html/rfc6460
3.) Even the people behind http://safecurves.cr.yp.to have no proof
    that secp[256|384|521]r1 are unsecure, they just don't trust the
    NIST. So that list is mostly useless and possibly untrue.
4.) ECC in certificates is not widely used and therfor also not
    extensivly audited, so it might be less secure than SHA256+RSA,
    or may suffer from implementation failures like heartbeat did.
5.) ECDSA has the same problems i mentioned in 4, so it may be a bad
    idea to use it in production. Stick to ECDHE and as a fallback
    to DHE. I use the following ciphers for my services:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)



- -- 
Kind Regards,                             Mit freundlichen Grüssen,
Markus Kohlmeyer                                   Markus Kohlmeyer

PGP: 0xEBDF5E55 / 2A22 1F71 AA70 1AD1 231B 0178 759F 407C EBDF 5E55

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTUneDAAoJEHWfQHzr315V9hcP/286xUPhj3TtJDZlAmP/lqM9
htEL2eE2Jr7l6GDX8/LNS5kWWN4ytEZEbGEIXijZSjss4AJiWq3b+CmW+n0F75E8
d94bEbl/voiTHS3yF5ytANzOLXdyKt3r7jJ6rAdEHCFI+8SYrV8oNM/u0Vx25saB
mFabQrUqfd1pe5vMtYJyl9xGogKuQdWdSCAO4K2u62Ktrbh7XGxgzMnToxzOZh+G
LxCSlRO+YdArW4pD5rOOfTm/6gPdq3t/KtM/+1sdkvhSP+t6VfbBZKFXBdyIto3+
B4vd2Wz2XtN1POAWezY2E9PjfeEo0jkfXUNgxo9FiCiX5M7u8/izirEQSw3yKONS
WmEhu+Bc0zYfaHN/4Up+Pq+8yUEQMiY5llOS2YaiTivHCajq9+e5ULFI42GTY+dG
BJcVFKz5nUQaACbhDJ1sXgrOh2GMMaUn61RF7a+5FbEDLhmo/Db7WYJzjfTSRqfa
EGtFC++P4ZN6R6AXt1CThdUoJC1x4YAU5ncu77iTAr5bxD3SE4UGnLpE5NNOS4AH
53bF8RKNlp7GV8ukyt3FBnQt9+TQt+ePcyru6teLHfb0f2euz7dRTtgkL/P4wi30
XtWxVTsk0JrufFVpm7FZNaIvHnZ2SS0AU4NIvejTVOmlkP3vXBqzNHCzoapTW09d
+6rVo7teibHK1B59e+0P
=KASv
-----END PGP SIGNATURE-----