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

2014-04-19 Thread Mick 
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.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

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

2014-04-19 Thread Joe User 
-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-

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

2014-04-19 Thread Matti Nykyri 
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 courieropenssl. 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

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

2014-04-19 Thread Joe User 
-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 courieropenssl. 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-

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

2014-04-19 Thread Mick 
On Saturday 19 Apr 2014 14:17:56 Joe User wrote:
 On 19.04.2014 13:51, Mick wrote:

  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

I beg your pardon!  I went all cross-eyed scanning different RFC pages and 
tables.

 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

Yes, you are right.  Also, some of these 'safe curves' are not currently 
available through openssl and some are just toy examples.  One would have to 
be technically competent enough to develop their own implementation of e.g. 
Curve25519 - in my case this would be decidedly dangerous to attempt!  ha, ha!


 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.

Well, from what I understand their argument is that the alleged criteria of 
efficiency assumed by the standards are not necessarily supportive of a better 
security model and often do not provide computational efficiency either.  In 
addition, the derivation of the supposedly random integers k are allegedly 
either not random, or in any case arbitrarily chosen.


 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)

Thanks!  I need to use certificates with strongswan, so I think I will be 
limited to:

prime256v1
secp384r1
secp521r1

http://wiki.strongswan.org/projects/strongswan/wiki/EcDsaSecret

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

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

2014-04-17 Thread Matti Nykyri 
On Apr 16, 2014, at 20:56, Tanstaafl tansta...@libertytrek.org wrote:

 On 4/16/2014 7:14 AM, Matti Nykyri matti.nyk...@iki.fi wrote:
 On Apr 16, 2014, at 13:52, Tanstaafl tansta...@libertytrek.org wrote:
 Or will simply replacing my self-signed certs with the new real ones be 
 good enough?
 
 No it will not. Keys are te ones that have been compromised. You need
 to create new keys. With those keys you need to create certificate
 request. Then you send that request to certificate authority for
 signing and publishing in their crl. When you receive the signed
 certificate you can start using it with your key. Never send your key
 to CA or expect to get a key from them.
 
 Ok, thanks...
 
Ok... This is the second time I'm writing this message. Last time my rotten 
battery of my rotten apple died while it was sending the message. That drove me 
to despair and i had sleep on it before retrying :/

 But... if I do this (create a new key-pair and CR), will this immediately 
 invalidate my old ones (ie, will my current production server stop working 
 until I get the new certs installed)?

No. Your cert is valid as described in the cert fields: not valid before, not 
valid after. You should never have two different valid certificates for the 
same propose. So it is the jobs of the CA to set the revoke bit on the old 
certificate when issuing a new one.

 I'm guessing not (or else there would be a lot of downtime for lots of sites 
 involved) - but I've only ever done this once (created the key-pair, CR and 
 self-signed keys) a long time ago, so want to make sure I don't shoot myself 
 in the foot...

The same here. Now this heartbleed got me updating everything. There are a few 
very good tutorials... And if you skim back this list there was a really good 
post on certs like two weeks ago.

 I have created new self-=signed certs a couple of times since creating the 
 original key-pair+CR, but never created a new key-pair/CR...

First you need to create parameters for your keys. If using elliptic key use:

openssl ecparam

This is not necessary for all types of keys. And usually most of these commands 
can be combined but I try to separate them so you get the full picture.

Then create keys:

openssl genpkey

Then make CR:

openssl req

After this the job is handled by the CA... So you for self signed cert. for a 
real cert you just send the CR to the CA.

CA will then sign your cert:

openssl ca

And publish your cert:

openssl ca -gencrl

For this CAcert is needed of course. If you just want a self signed cert you 
can create your own CAcert by creating keys and self-signed cert by:

openssl genpkey
openssl req -x509

Then sign and publish your CR with your CAcert using openssl ca-utility.

About security.. Your CA keys should never ever be on a computer that is 
online. If they were and would have been compromised by heartbleed for example 
we would be having a true catastrophe at the moment. Still it is suggested that 
you encrypt your CAcert keys. 

 There are also other algorithms the RSA. And also if you wan't to get
 PFS you will need to consider your setup, certificate and security
 model.
 
 What is PFS?

PFS = perfect forward secrecy. Meaning that the exposure of your cert keys will 
not compromise the content of past transmissions that have been recorded by 
your adversary.

This is offered by certain cipher suites. So you really need to consider what 
algorithms and what ciphers you wish to use with you SSL servers and choose 
certificates and parameters that will do the job.

DHE and ECDHE will provide PFS. I dont know enough about cryptography to truly 
say what to trust. Someone should correct me if my assumptions are false... But 
I have come to a conclusion that DHE is compromised by NSA. So I would not use 
it. DH and ECDH do not provide PFS. 

Using PFS gives you a performance penalty but increase security. DH uses 
DHparams to do the key exchange. Openssl will reuse these params across 
different connection to boost performance. It needs to be explicitly told not 
to if this is desired. This again increases security but degrades performance.

For the cert I would use elliptic cryptography. I trust NSA has not poisoned 
this algorithm... But can you be sure? Anyways making things secure you need to 
trust that you have truly random data and there are no vulnerabilities in you 
key generators... It is really hard to make sure of this. It requires you to be 
a true pro.

-Matti

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

2014-04-17 Thread Mick 
On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote:
 On 4/16/2014 7:14 AM, Matti Nykyri matti.nyk...@iki.fi wrote:
  On Apr 16, 2014, at 13:52, Tanstaafl tansta...@libertytrek.org wrote:
  Or will simply replacing my self-signed certs with the new real ones be
  good enough?
  
  No it will not. Keys are te ones that have been compromised. You need
  to create new keys. With those keys you need to create certificate
  request. Then you send that request to certificate authority for
  signing and publishing in their crl. When you receive the signed
  certificate you can start using it with your key. Never send your key
  to CA or expect to get a key from them.
 
 Ok, thanks...
 
 But... if I do this (create a new key-pair and CR), will this
 immediately invalidate my old ones (ie, will my current production
 server stop working until I get the new certs installed)?

You have not explained your PKI set up.  Creating a new private key and CSR is 
just another private key and CSR.

If you replace either the private CA key on the server, or any of its 
certificates chain, but leave the path in your vhosts pointing to the old 
key/certificate that no longer exist you will of course break the server.  
Apache will refuse to restart and warn you about borked paths.


 I'm guessing not (or else there would be a lot of downtime for lots of
 sites involved) - but I've only ever done this once (created the
 key-pair, CR and self-signed keys) a long time ago, so want to make sure
 I don't shoot myself in the foot...

Yes, better be safe with production machines.  However, don't take too long 
because your private key(s) are potentially already compromised.


 I have created new self-=signed certs a couple of times since creating
 the original key-pair+CR, but never created a new key-pair/CR...
 
  There are also other algorithms the RSA. And also if you wan't to get
  PFS you will need to consider your setup, certificate and security
  model.
 
 What is PFS?

  http://en.wikipedia.org/wiki/Forward_secrecy

I'm no mathematical genius to understand cryptography at anything more than a 
superficial level, but I thought that ECDS, that PFS for TLS depends on, was 
compromised from inception by the NSA?  Perhaps only some ECDS were, I am not 
really sure.

I remember reading somewhere (was it Schneier?) that RSA is probably a better 
bet these days.  I'd also appreciate some views from the better informed 
members of the list because there's a lot of FUD and tin hats flying around in 
the post Snowden era.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

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

2014-04-17 Thread Matti Nykyri 
On Apr 17, 2014, at 9:10, Mick michaelkintz...@gmail.com wrote:

 On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote:
 On 4/16/2014 7:14 AM, Matti Nykyri matti.nyk...@iki.fi wrote:
 On Apr 16, 2014, at 13:52, Tanstaafl tansta...@libertytrek.org wrote:
 Or will simply replacing my self-signed certs with the new real ones be
 good enough?
 
 No it will not. Keys are te ones that have been compromised. You need
 to create new keys. With those keys you need to create certificate
 request. Then you send that request to certificate authority for
 signing and publishing in their crl. When you receive the signed
 certificate you can start using it with your key. Never send your key
 to CA or expect to get a key from them.
 
 Ok, thanks...
 
 But... if I do this (create a new key-pair and CR), will this
 immediately invalidate my old ones (ie, will my current production
 server stop working until I get the new certs installed)?
 
 You have not explained your PKI set up.  Creating a new private key and CSR 
 is 
 just another private key and CSR.
 
 If you replace either the private CA key on the server, or any of its 
 certificates chain, but leave the path in your vhosts pointing to the old 
 key/certificate that no longer exist you will of course break the server.  
 Apache will refuse to restart and warn you about borked paths.
 
 
 I'm guessing not (or else there would be a lot of downtime for lots of
 sites involved) - but I've only ever done this once (created the
 key-pair, CR and self-signed keys) a long time ago, so want to make sure
 I don't shoot myself in the foot...
 
 Yes, better be safe with production machines.  However, don't take too long 
 because your private key(s) are potentially already compromised.
 
 
 I have created new self-=signed certs a couple of times since creating
 the original key-pair+CR, but never created a new key-pair/CR...
 
 There are also other algorithms the RSA. And also if you wan't to get
 PFS you will need to consider your setup, certificate and security
 model.
 
 What is PFS?
 
  http://en.wikipedia.org/wiki/Forward_secrecy
 
 I'm no mathematical genius to understand cryptography at anything more than a 
 superficial level, but I thought that ECDS, that PFS for TLS depends on, was 
 compromised from inception by the NSA?  Perhaps only some ECDS were, I am not 
 really sure.

I don't know anything about ECDS. You probably mean ECDSA?! What i have 
understood is that ECDSA is not compromised. Though I can not be certain about 
that.

RSA has been in the market for a long time and the mathematics are for what i 
think a bit simpler. But with compromised software there was a bad algorithm 
for creating the primes. So it was the keys not RSA it self. But I think the 
thing that you are talking about is DHE_RSA... I read from somewhere that it 
was quite compromised.. But ECDHE is not. The difference with DH and DHE (ECDH 
and ECDHE) is that DH uses static keys and DHE authenticated ephemeral keys. 
These temporary keys give you forward secrecy but decrease performance.

RSA takes quite heavy computing for the same level of security compared to 
ECDSA. RSA key creation is even more costly so using ephemeral temporary keys 
with RSA takes quite long to compute. Thats why I prefer ECDHE_ECDSA suites for 
reasonable security and fast encryption.

 I remember reading somewhere (was it Schneier?) that RSA is probably a better 
 bet these days.  I'd also appreciate some views from the better informed 
 members of the list because there's a lot of FUD and tin hats flying around 
 in 
 the post Snowden era.

For high security application I would also use RSA in excess of 16k keys. Then 
make sure to use random data and a trustworthy key-generator. Fighting the 
agencies is still something I believe is virtually impossible ;)

-- 
-Matti

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

2014-04-17 Thread Mick 
On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote:
 On Apr 17, 2014, at 9:10, Mick michaelkintz...@gmail.com wrote:
  On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote:
  On 4/16/2014 7:14 AM, Matti Nykyri matti.nyk...@iki.fi wrote:
  On Apr 16, 2014, at 13:52, Tanstaafl tansta...@libertytrek.org wrote:
  Or will simply replacing my self-signed certs with the new real ones
  be good enough?
  
  No it will not. Keys are te ones that have been compromised. You need
  to create new keys. With those keys you need to create certificate
  request. Then you send that request to certificate authority for
  signing and publishing in their crl. When you receive the signed
  certificate you can start using it with your key. Never send your key
  to CA or expect to get a key from them.
  
  Ok, thanks...
  
  But... if I do this (create a new key-pair and CR), will this
  immediately invalidate my old ones (ie, will my current production
  server stop working until I get the new certs installed)?
  
  You have not explained your PKI set up.  Creating a new private key and
  CSR is just another private key and CSR.
  
  If you replace either the private CA key on the server, or any of its
  certificates chain, but leave the path in your vhosts pointing to the old
  key/certificate that no longer exist you will of course break the server.
  Apache will refuse to restart and warn you about borked paths.
  
  I'm guessing not (or else there would be a lot of downtime for lots of
  sites involved) - but I've only ever done this once (created the
  key-pair, CR and self-signed keys) a long time ago, so want to make sure
  I don't shoot myself in the foot...
  
  Yes, better be safe with production machines.  However, don't take too
  long because your private key(s) are potentially already compromised.
  
  I have created new self-=signed certs a couple of times since creating
  the original key-pair+CR, but never created a new key-pair/CR...
  
  There are also other algorithms the RSA. And also if you wan't to get
  PFS you will need to consider your setup, certificate and security
  model.
  
  What is PFS?
  
   http://en.wikipedia.org/wiki/Forward_secrecy
  
  I'm no mathematical genius to understand cryptography at anything more
  than a superficial level, but I thought that ECDS, that PFS for TLS
  depends on, was compromised from inception by the NSA?  Perhaps only
  some ECDS were, I am not really sure.
 
 I don't know anything about ECDS. You probably mean ECDSA?! What i have
 understood is that ECDSA is not compromised. Though I can not be certain
 about that.
 
 RSA has been in the market for a long time and the mathematics are for what
 i think a bit simpler. But with compromised software there was a bad
 algorithm for creating the primes. So it was the keys not RSA it self. But
 I think the thing that you are talking about is DHE_RSA... I read from
 somewhere that it was quite compromised.. But ECDHE is not. The difference
 with DH and DHE (ECDH and ECDHE) is that DH uses static keys and DHE
 authenticated ephemeral keys. These temporary keys give you forward
 secrecy but decrease performance.
 
 RSA takes quite heavy computing for the same level of security compared to
 ECDSA. RSA key creation is even more costly so using ephemeral temporary
 keys with RSA takes quite long to compute. Thats why I prefer ECDHE_ECDSA
 suites for reasonable security and fast encryption.
 
  I remember reading somewhere (was it Schneier?) that RSA is probably a
  better bet these days.  I'd also appreciate some views from the better
  informed members of the list because there's a lot of FUD and tin hats
  flying around in the post Snowden era.
 
 For high security application I would also use RSA in excess of 16k keys.
 Then make sure to use random data and a trustworthy key-generator.
 Fighting the agencies is still something I believe is virtually impossible
 ;)

Thanks Matti,

Can you please share how you create ECDHE_ECDSA with openssl ecparam, or ping 
a URL if that is more convenient?

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

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

2014-04-17 Thread Joe User 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 17.04.2014 17:49, Mick wrote:
 On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote:
 On Apr 17, 2014, at 9:10, Mick michaelkintz...@gmail.com
 wrote:
 On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote:
 On 4/16/2014 7:14 AM, Matti Nykyri matti.nyk...@iki.fi
 wrote:
 On Apr 16, 2014, at 13:52, Tanstaafl
 tansta...@libertytrek.org wrote:
 Or will simply replacing my self-signed certs with the
 new real ones be good enough?
 
 No it will not. Keys are te ones that have been
 compromised. You need to create new keys. With those keys
 you need to create certificate request. Then you send that
 request to certificate authority for signing and publishing
 in their crl. When you receive the signed certificate you
 can start using it with your key. Never send your key to CA
 or expect to get a key from them.
 
 Ok, thanks...
 
 But... if I do this (create a new key-pair and CR), will
 this immediately invalidate my old ones (ie, will my current
 production server stop working until I get the new certs
 installed)?
 
 You have not explained your PKI set up.  Creating a new private
 key and CSR is just another private key and CSR.
 
 If you replace either the private CA key on the server, or any
 of its certificates chain, but leave the path in your vhosts
 pointing to the old key/certificate that no longer exist you
 will of course break the server. Apache will refuse to restart
 and warn you about borked paths.
 
 I'm guessing not (or else there would be a lot of downtime
 for lots of sites involved) - but I've only ever done this
 once (created the key-pair, CR and self-signed keys) a long
 time ago, so want to make sure I don't shoot myself in the
 foot...
 
 Yes, better be safe with production machines.  However, don't
 take too long because your private key(s) are potentially
 already compromised.
 
 I have created new self-=signed certs a couple of times since
 creating the original key-pair+CR, but never created a new
 key-pair/CR...
 
 There are also other algorithms the RSA. And also if you
 wan't to get PFS you will need to consider your setup,
 certificate and security model.
 
 What is PFS?
 
 http://en.wikipedia.org/wiki/Forward_secrecy
 
 I'm no mathematical genius to understand cryptography at
 anything more than a superficial level, but I thought that
 ECDS, that PFS for TLS depends on, was compromised from
 inception by the NSA?  Perhaps only some ECDS were, I am not
 really sure.
 
 I don't know anything about ECDS. You probably mean ECDSA?! What
 i have understood is that ECDSA is not compromised. Though I can
 not be certain about that.
 
 RSA has been in the market for a long time and the mathematics
 are for what i think a bit simpler. But with compromised software
 there was a bad algorithm for creating the primes. So it was the
 keys not RSA it self. But I think the thing that you are talking
 about is DHE_RSA... I read from somewhere that it was quite
 compromised.. But ECDHE is not. The difference with DH and DHE
 (ECDH and ECDHE) is that DH uses static keys and DHE 
 authenticated ephemeral keys. These temporary keys give you
 forward secrecy but decrease performance.
 
 RSA takes quite heavy computing for the same level of security
 compared to ECDSA. RSA key creation is even more costly so using
 ephemeral temporary keys with RSA takes quite long to compute.
 Thats why I prefer ECDHE_ECDSA suites for reasonable security and
 fast encryption.
 
 I remember reading somewhere (was it Schneier?) that RSA is
 probably a better bet these days.  I'd also appreciate some
 views from the better informed members of the list because
 there's a lot of FUD and tin hats flying around in the post
 Snowden era.
 
 For high security application I would also use RSA in excess of
 16k keys. Then make sure to use random data and a trustworthy
 key-generator. Fighting the agencies is still something I believe
 is virtually impossible ;)
 
 Thanks Matti,
 
 Can you please share how you create ECDHE_ECDSA with openssl
 ecparam, or ping a URL if that is more convenient?
 

I don't think you realy want DSA, but here it is for DH, EC and DSA:

openssl genpkey -genparam -algorithm DH \
-pkeyopt dh_paramgen_prime_len:4096 \
-out /path/dh_params.pem
openssl genpkey -genparam -algorithm EC \
-pkeyopt ec_paramgen_curve:secp384r1 \
-out /path/ec_params.pem
openssl genpkey -genparam -algorithm DSA \
-pkeyopt dsa_paramgen_bits:1024 \
-out /path/dsa_params.pem


- -- 
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)

iQIcBAEBCgAGBQJTUAcrAAoJEHWfQHzr315VTxUP/0KdnN2CBvcQe7qOKEcnXkNq
p5DzcBFacq9Opp3/ICUZ21yLla/YA+QuiEoSOQS859xkFnqCVrAOvOLsVS7GJfTG
jUUWUEsd6YoxWGZql+m4P92HzTnL1cQAfc2kcd8vI6d0jCDqo3iLBcLwVuV/efz2

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

2014-04-17 Thread Matti Nykyri 
On Thu, Apr 17, 2014 at 04:49:45PM +0100, Mick wrote:
 On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote:
  On Apr 17, 2014, at 9:10, Mick michaelkintz...@gmail.com wrote:
   On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote:
   On 4/16/2014 7:14 AM, Matti Nykyri matti.nyk...@iki.fi wrote:
   On Apr 16, 2014, at 13:52, Tanstaafl tansta...@libertytrek.org wrote:
   Or will simply replacing my self-signed certs with the new real ones
   be good enough?
   
   No it will not. Keys are te ones that have been compromised. You need
   to create new keys. With those keys you need to create certificate
   request. Then you send that request to certificate authority for
   signing and publishing in their crl. When you receive the signed
   certificate you can start using it with your key. Never send your key
   to CA or expect to get a key from them.
   
   Ok, thanks...
   
   But... if I do this (create a new key-pair and CR), will this
   immediately invalidate my old ones (ie, will my current production
   server stop working until I get the new certs installed)?
   
   You have not explained your PKI set up.  Creating a new private key and
   CSR is just another private key and CSR.
   
   If you replace either the private CA key on the server, or any of its
   certificates chain, but leave the path in your vhosts pointing to the old
   key/certificate that no longer exist you will of course break the server.
   Apache will refuse to restart and warn you about borked paths.
   
   I'm guessing not (or else there would be a lot of downtime for lots of
   sites involved) - but I've only ever done this once (created the
   key-pair, CR and self-signed keys) a long time ago, so want to make sure
   I don't shoot myself in the foot...
   
   Yes, better be safe with production machines.  However, don't take too
   long because your private key(s) are potentially already compromised.
   
   I have created new self-=signed certs a couple of times since creating
   the original key-pair+CR, but never created a new key-pair/CR...
   
   There are also other algorithms the RSA. And also if you wan't to get
   PFS you will need to consider your setup, certificate and security
   model.
   
   What is PFS?
   
http://en.wikipedia.org/wiki/Forward_secrecy
   
   I'm no mathematical genius to understand cryptography at anything more
   than a superficial level, but I thought that ECDS, that PFS for TLS
   depends on, was compromised from inception by the NSA?  Perhaps only
   some ECDS were, I am not really sure.
  
  I don't know anything about ECDS. You probably mean ECDSA?! What i have
  understood is that ECDSA is not compromised. Though I can not be certain
  about that.
  
  RSA has been in the market for a long time and the mathematics are for what
  i think a bit simpler. But with compromised software there was a bad
  algorithm for creating the primes. So it was the keys not RSA it self. But
  I think the thing that you are talking about is DHE_RSA... I read from
  somewhere that it was quite compromised.. But ECDHE is not. The difference
  with DH and DHE (ECDH and ECDHE) is that DH uses static keys and DHE
  authenticated ephemeral keys. These temporary keys give you forward
  secrecy but decrease performance.
  
  RSA takes quite heavy computing for the same level of security compared to
  ECDSA. RSA key creation is even more costly so using ephemeral temporary
  keys with RSA takes quite long to compute. Thats why I prefer ECDHE_ECDSA
  suites for reasonable security and fast encryption.
  
   I remember reading somewhere (was it Schneier?) that RSA is probably a
   better bet these days.  I'd also appreciate some views from the better
   informed members of the list because there's a lot of FUD and tin hats
   flying around in the post Snowden era.
  
  For high security application I would also use RSA in excess of 16k keys.
  Then make sure to use random data and a trustworthy key-generator.
  Fighting the agencies is still something I believe is virtually impossible
  ;)
 
 Thanks Matti,
 
 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

Create your own CA certificate and associated new pkey:
openssl req -new -x509 -extensions v3_ca -newkey ec:ec_param.pem -keyout 
private/cakey.pem -out cacert.pem -days 3650 -config ./openssl.cnf

#create cert request and new pkey:
openssl req -new -nodes -out req.pem -newkey ec:ec_param.pem -config 
./openssl.cnf

#sign cert with your CAcert:
openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem

#create crl for all certificate requests you have signed with your CAcert:
openssl ca -gencrl -crldays 31 -config ./openssl.cnf -out rootca.crl

#revoke certificate:
openssl ca -revoke newcerts/serial.pem -config ./openssl.cnf


Modify openssl.cnf to suite your setup. With this setup you
will get the newest fastest and most

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

2014-04-16 Thread Matti Nykyri 
On Apr 16, 2014, at 13:52, Tanstaafl tansta...@libertytrek.org wrote:

 Hi all,
 
 I've taken this opportunity to prod the boss to let me buy some real certs 
 for our few self-hosted mail services. Until now, we've used self-signed 
 certs.
 
 My question is, what exactly is the correct procedure for doing this?
 
 Also, do I still need to do the step I've been seeing:
 
 Step: 2
 
 Delete SSL key set
 
Now, make out a list of websites that are equipped with SSL
certificates.
After that, delete all SSL keys, private and CSR key
Finally, create a new private key and CSR key for each of your
website. However, remember that your keys should be of 2048-bit key
length.
 
 ?
Depends on your security model. RSA 2048-bit should be sufficient for most 
people. Although it is totally possible to create 16384-bit key. Just remember 
to use random data and a trust worthy keygenerator. They both have been know to 
be tampered by some agencies :)

 
 Or will simply replacing my self-signed certs with the new real ones be good 
 enough?

No it will not. Keys are te ones that have been compromised. You need to create 
new keys. With those keys you need to create certificate request. Then you send 
that request to certificate authority for signing and publishing in their crl. 
When you receive the signed certificate you can start using it with your key. 
Never send your key to CA or expect to get a key from them.

There are also other algorithms the RSA. And also if you wan't to get PFS you 
will need to consider your setup, certificate and security model.

-- 
-Matti

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

2014-04-16 Thread Tanstaafl 

On 4/16/2014 7:14 AM, Matti Nykyri matti.nyk...@iki.fi wrote:

On Apr 16, 2014, at 13:52, Tanstaafl tansta...@libertytrek.org wrote:

Or will simply replacing my self-signed certs with the new real ones be good 
enough?



No it will not. Keys are te ones that have been compromised. You need
to create new keys. With those keys you need to create certificate
request. Then you send that request to certificate authority for
signing and publishing in their crl. When you receive the signed
certificate you can start using it with your key. Never send your key
to CA or expect to get a key from them.


Ok, thanks...

But... if I do this (create a new key-pair and CR), will this 
immediately invalidate my old ones (ie, will my current production 
server stop working until I get the new certs installed)?


I'm guessing not (or else there would be a lot of downtime for lots of 
sites involved) - but I've only ever done this once (created the 
key-pair, CR and self-signed keys) a long time ago, so want to make sure 
I don't shoot myself in the foot...


I have created new self-=signed certs a couple of times since creating 
the original key-pair+CR, but never created a new key-pair/CR...



There are also other algorithms the RSA. And also if you wan't to get
PFS you will need to consider your setup, certificate and security
model.


What is PFS?