public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mick <michaelkintzios@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones
Date: Thu, 17 Apr 2014 16:49:45 +0100	[thread overview]
Message-ID: <201404171649.57228.michaelkintzios@gmail.com> (raw)
In-Reply-To: <76ABA3DD-014E-42A8-B109-3D02CF20D27F@iki.fi>

[-- Attachment #1: Type: Text/Plain, Size: 4338 bytes --]

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?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2014-04-17 15:51 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16 10:52 [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones Tanstaafl
2014-04-16 11:14 ` Matti Nykyri
2014-04-16 17:56   ` Tanstaafl
2014-04-17  5:59     ` Matti Nykyri
2014-04-17  6:10     ` Mick
2014-04-17 14:40       ` Matti Nykyri
2014-04-17 15:49         ` Mick [this message]
2014-04-17 16:54           ` Joe User
2014-04-17 18:43           ` Matti Nykyri
2014-04-17 20:17             ` [gentoo-user] " walt
2014-04-18  5:50               ` Matti Nykyri
2014-04-18 14:27                 ` Dale
2014-04-18 16:45                   ` Mick
2014-04-18 18:08                     ` Dale
2014-04-18 19:01                       ` Mick
2014-04-18 20:27                         ` Dale
2014-04-18 23:33                           ` Mick
2014-04-19 15:29                             ` Dale
2014-04-19 15:43                               ` Matti Nykyri
2014-04-19 19:33                                 ` Dale
2014-04-19 19:43                                   ` Joe User
2014-04-19 21:23                                     ` Dale
2014-04-20  0:18                                 ` Peter Humphrey
2014-04-20  8:49                                   ` Mick
2014-04-20  9:21                                     ` Matti Nykyri
2014-04-20 10:26                                       ` Mick
2014-04-19 16:11                               ` Mick
2014-04-19 18:41                                 ` Dale
2014-04-20  8:27                                   ` Mick
2014-04-20  9:10                                     ` Dale
2014-04-20 12:38                                       ` Mick
2014-04-20 16:40                                         ` Matti Nykyri
2014-04-20 17:20                                           ` Joe User
2014-04-21  6:57                                             ` Matti Nykyri
2014-04-20 18:36                                         ` Dale
2014-04-19 11:51             ` [gentoo-user] " Mick
2014-04-19 13:17               ` Joe User
2014-04-19 15:38                 ` Matti Nykyri
2014-04-19 16:40                   ` Joe User
2014-04-19 17:14                 ` Mick
2014-04-20 23:20                 ` Mick
2014-04-21  7:11                   ` Matti Nykyri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201404171649.57228.michaelkintzios@gmail.com \
    --to=michaelkintzios@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox