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

[Matti Nykyri <Matti.Nykyri@iki.fi>]

[-- Attachment #1: Type: text/plain, Size: 6882 bytes --]

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 <michaelkintzios@gmail.com> wrote:
> > > On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote:
> > >> On 4/16/2014 7:14 AM, Matti Nykyri <matti.nykyri@iki.fi> wrote:
> > >>> On Apr 16, 2014, at 13:52, Tanstaafl <tanstaafl@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 secure cipher by public
sources:

ECDHE-ECDSA-AES256-GCM-SHA384

I don't know much about the secp521r1 curve or about its security.
You can list all available curves by:

openssl ecparam -list_curves


With this setup apache and postfix works great. You can test my server
with this URL:

https://www.ssllabs.com/ssltest/analyze.html?d=nykyri.eu&hideResults=on

So these ciphers are supported:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)   ECDH 256 bits (eq. 3072 bits RSA)   FS		256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   ECDH 256 bits (eq. 3072 bits RSA)   FS		128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)   ECDH 256 bits (eq. 3072 bits RSA)   FS		256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)   ECDH 256 bits (eq. 3072 bits RSA)   FS		128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   ECDH 256 bits (eq. 3072 bits RSA)   FS		256

I still have alternate names not setup and few other things neew changing
with the certificates, but this might change during Easter :)

The tutorial I mentioned before is here:
http://www.eclectica.ca/howto/ssl-cert-howto.php

The one problem I have is that no matter what I have failed to get
courier to support ECDHE. Courier needs the DHparams for ephemeral
keys to work, but I have failed to set it up... so there I have
TLS_ECDH_ECDSA_WITH_256_GCM_SHA384 :/ Will continue trying...

To create dhparameters:
openssl dhparam -out dhparam.pem 4096

And you will find openssl.cnf attached :) Create a directory and put 
it there. Under that create directories private, newcerts. Then create
files:

echo 01 > serial
touch index.txt

-- 
-Matti

[-- Attachment #2: openssl.cnf --]
[-- Type: text/plain, Size: 2550 bytes --]

# OpenSSL configuration file.
#
#
# Establish working directory.

dir			= .

[ ca ]
default_ca		= CA_default

[ CA_default ]
serial			= $dir/serial
database		= $dir/index.txt
new_certs_dir		= $dir/newcerts
certificate		= $dir/cacert.pem
private_key		= $dir/private/cakey.pem
default_days		= 365
default_md		= sha512
preserve		= no
email_in_dn		= no
utf8			= yes
nameopt			= default_ca
certopt			= default_ca
policy			= policy_match

[ policy_match ]
countryName		= match
stateOrProvinceName	= match
organizationName	= match
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional

[ req ]
default_bits		= 4096			# Size of keys
default_keyfile		= key.pem		# name of generated keys
default_md		= sha512		# message digest algorithm
string_mask		= nombstr		# permitted characters
#string_mask		= utf8only		# permitted characters
utf8			= yes
distinguished_name	= req_distinguished_name
req_extensions		= v3_req

[ req_distinguished_name ]
# Variable name		  Prompt string
#----------------------	  ----------------------------------
0.organizationName	= Organization Name (company)
organizationalUnitName	= Organizational Unit Name (department, division)
emailAddress		= Email Address
emailAddress_max	= 40
localityName		= Locality Name (city, district)
stateOrProvinceName	= State or Province Name (full name)
countryName		= Country Name (2 letter code)
countryName_min		= 2
countryName_max		= 2
commonName		= Common Name (hostname, IP, or your name)
commonName_max		= 64

# Default values for the above, for consistency and less typing.
# Variable name			  Value
#------------------------------	  ------------------------------
0.organizationName_default	= 
localityName_default		= 
stateOrProvinceName_default	= 
countryName_default		= 

[ v3_ca ]
basicConstraints	= CA:TRUE
subjectKeyIdentifier	= hash
authorityKeyIdentifier	= keyid:always,issuer:always

[ v3_req ]
basicConstraints	= CA:FALSE
subjectKeyIdentifier	= hash

#basicConstraints	= CA:TRUE,pathlen:0
#keyUsage		= digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment,keyArgeement,keyCertSign,cRLSign,encipherOnly,decipherOnly
#extandedKeyUsage	= keyUsage
#	serverAuth
#	clientAuth
#	codeSigning
#	emailProtection
#	timeStamping
#authorityKeyIdentifier	= keyid,issuer
#subjectAltName		= email:postmaster@nykyri.eu
#	DNS:www.nykyri.eu
#	DNS:nykyri.eu
#authorityInfoAccess	= OCSP;URI:http://test.nykyri.eu/
#authorityInfoAccess	= caIssuers;URI:http://example.org/
#crlDistributionPoints	= URI:http://example.org/onelist.crl,URI:http://test.fi/calist.crl