-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 19.04.2014 17:38, Matti Nykyri wrote: > 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?
openssl ecparam -list_curves But openssl is not used by the major browsers and other clients, so it is not a reference here. >> 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. I use Dovecot as IMAPd. If you're interested in how i setup my servers then have a look at my corresponding howtos (in order): http://www.rootservice.org/howtos/freebsd/remote_install.html http://www.rootservice.org/howtos/freebsd/certificate_authority.html http://www.rootservice.org/howtos/freebsd/hosting_system.html My Gentoo-HowTos are out of date, so don't look at them ;) But the configs should work also on Gentoo with little tweaks. - -- 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) iQIcBAEBCgAGBQJTUqcFAAoJEHWfQHzr315VY+cP/2mv/IJV8jkFMEtanP7WasYt gHWLNXW170+iTY7LbtEoZr9Or9U/RDWsXAEpb7kKO/G628zwOXOjMZAlBCr/O7U3 ZP0KNQfl7m+/BwIJ3uvjjHPExMHTF6f/w8U+9bhgPUMkGfBPqUEHF8jRRgn5wEdz Gd4l+fyQnWkheeb7TE1/ggEDrtHu232SumF3niDEkZlvO5ENoXquXw3YkFQ05Iyw LIU+j/yWCvajUN7CPEHEn7/KSJVzkwaH+6hqme2IxoyFjDScDBps2QqyqQgnX8gO 4QyCtn+/w8DChFs/gx2DUDTEKwhcjbzP3832RmejBoHpxFdwEUiT5ZMUNFqY33QP QlXhtQCogED6RJpJfeysaHt35p8B0Pb8wU4pR4GbFsvU0yBrUKK1aTFKsJqK9kQq +1U7sbgWFc+4kImIIHX/v5uOBlaCoQSrZ6gaBk2EGWc5uNnrW7qLvszA0VcRPwGo cgEuPZDgBedOdDSSA1oeHyk2mAk3f1pU8gxOEXZPEDpAzHlGGKyV/DkG+Co/YwC4 39kmWLJPfHT3sy5U8i9yC2P5zDHvO4dBalcsQ9BY+N+ynv1MfMN5NI0YT2EXCsEO upHPs4g8Y6LpJcVuERbiqYj1urRegGKj4N83p+0NaNk2mz0lP20OxVWaYdUw/bTW yMyf/oLzxxmgMF4kKtbg =n7KU -----END PGP SIGNATURE-----
