On Apr 19, 2014, at 16:17, Joe User <mailingli...@rootservice.org> wrote:
> -----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. Which of the safecurves are supported by openssl? > 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) What program do you use to provide IMAP-SSL/TLS? I have not gotten ECDHE to work with courier&openssl. Anyways I fail to see any logic with courier-setup... Postfix and apache on the other hand are easy to setup to use the correct ciphers. -Matti
