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

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

[Tanstaafl]

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.

?

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

Thanks

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

[Matti Nykyri]

On Apr 16, 2014, at 13:52, Tanstaafl <tanstaafl@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

[Tanstaafl]

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

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?

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

[Matti Nykyri]

On Apr 16, 2014, at 20:56, Tanstaafl <tanstaafl@libertytrek.org> 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...
> 
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

[Mick]

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

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

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

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

[Matti Nykyri]

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

-- 
-Matti

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

[Mick]

[-- 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 --]

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

[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 <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?
> 

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
qtagFyIeFPAgGQ1RmTptIqc28IL8ugbL8HqePuc5pM8pOyfj7qwHI+64vVKiO+Xu
S+orO9nFtDnM7crTz68722qE4+58hj4q/w0N6Uuw8SJbFCDcaal063Ba2WSh+UHm
GBXidaK2eVdyTzzPx0rvkxMtD9sVb6WTZZ/gBwtJUNZ5WTinvjmQNDqkyWRxHeXP
e4m3mJCB36gdgjjy/0Kmt78otYblVkmI+JYRI4fH3l9fxT14FNuXq63R7aZuFEw2
BiwmR+naf2sxkiAhy/szybfqAmeVGKjEAqlDZkzEz6tlO6SwKkYBpc1QS139QHUN
bK++/bhzIh/yNEQjHIhEaMXmRTco+6fdASaq0h4r1mm5A8o0SCSJnNKp4G6ZC1SV
kuuYfiSHxpRZ0RoLUsFSZM7oki/j2Q1KYZys917/sLzLeOv2US2ScliEZD5w+mF0
e1cqudLoYP9TSkF/3r/ac5yF6gR4ye1eDEdCFeG2ktq8Ru/JlviiNAspSlm2OOAz
kFKkM0cJWaZ/mAuXrrfY
=GSjk
-----END PGP SIGNATURE-----

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

[Matti Nykyri]

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

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

[walt]

On 04/17/2014 11:43 AM, Matti Nykyri wrote:
> I don't know much about the secp521r1 curve or about its security.
> You can list all available curves by:
> 
> openssl ecparam -list_curves

I don't either, but I hope this guy does :)

http://www.math.columbia.edu/~woit/wordpress/?p=6243

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

[Matti Nykyri]

On Apr 17, 2014, at 23:17, walt <w41ter@gmail.com> wrote:

> On 04/17/2014 11:43 AM, Matti Nykyri wrote:
>> I don't know much about the secp521r1 curve or about its security.
>> You can list all available curves by:
>> 
>> openssl ecparam -list_curves
> 
> I don't either, but I hope this guy does :)
> 
> http://www.math.columbia.edu/~woit/wordpress/?p=6243

Good article :) The overall picture I had about EC is more or less the same as described in the article. But you always have to make a threat analysis and it depends on the private data you are protecting. By definition any private data will be disclosed given enough time and resources.

So if your adversary is NSA... Well protecting the communication of regular internet user and your production server with SSL and x509 certificates will just not secure the content. I'm 100% certain that NSA has access to at least one CA root certificates private keys. With those they can do a man-in-the-middle attack that the regular user will most likely never spot.

I my own security model I'm protected from NSA by the fact that it will disappear in the flow of all other traffic because NSA is not stealing credit card numbers :) ECDSA with ECDHE is fast and secure according to public sources.

The problem is totally different if you are protecting the secrets of your company that are within the interest of NSA. I'm lucky I don't have to try that.

-- 
-Matti

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

[Dale]

Matti Nykyri wrote:
> On Apr 17, 2014, at 23:17, walt <w41ter@gmail.com> wrote:
>
>> On 04/17/2014 11:43 AM, Matti Nykyri wrote:
>>> I don't know much about the secp521r1 curve or about its security.
>>> You can list all available curves by:
>>>
>>> openssl ecparam -list_curves
>> I don't either, but I hope this guy does :)
>>
>> http://www.math.columbia.edu/~woit/wordpress/?p=6243
> Good article :) The overall picture I had about EC is more or less the same as described in the article. But you always have to make a threat analysis and it depends on the private data you are protecting. By definition any private data will be disclosed given enough time and resources.
>
> So if your adversary is NSA... Well protecting the communication of regular internet user and your production server with SSL and x509 certificates will just not secure the content. I'm 100% certain that NSA has access to at least one CA root certificates private keys. With those they can do a man-in-the-middle attack that the regular user will most likely never spot.
>
> I my own security model I'm protected from NSA by the fact that it will disappear in the flow of all other traffic because NSA is not stealing credit card numbers :) ECDSA with ECDHE is fast and secure according to public sources.
>
> The problem is totally different if you are protecting the secrets of your company that are within the interest of NSA. I'm lucky I don't have to try that.
>

On this topic about NSA, I read a article that claimed the NSA was able
to view httpS traffic live or close to live since they had some backdoor
access keys.  I don't recall where the article was but since this is a
knowledgeable bunch, is this true?  If for example I go to my bank or
credit card website, can they "easily" view that traffic? 

One reason this jumped out at me was that in the article, it was claimed
that a group of people was going to rewrite the code/software/whatever
for httpS and other encryption tools. 

If someone has links to such info for me to read and pass on to others,
that would be great too. 

Thanks.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

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

[Mick]

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

On Friday 18 Apr 2014 15:27:12 Dale wrote:
> Matti Nykyri wrote:
> > On Apr 17, 2014, at 23:17, walt <w41ter@gmail.com> wrote:
> >> On 04/17/2014 11:43 AM, Matti Nykyri wrote:
> >>> I don't know much about the secp521r1 curve or about its security.
> >>> You can list all available curves by:
> >>> 
> >>> openssl ecparam -list_curves
> >> 
> >> I don't either, but I hope this guy does :)
> >> 
> >> http://www.math.columbia.edu/~woit/wordpress/?p=6243
> > 
> > Good article :) The overall picture I had about EC is more or less the
> > same as described in the article. But you always have to make a threat
> > analysis and it depends on the private data you are protecting. By
> > definition any private data will be disclosed given enough time and
> > resources.
> > 
> > So if your adversary is NSA... Well protecting the communication of
> > regular internet user and your production server with SSL and x509
> > certificates will just not secure the content. I'm 100% certain that NSA
> > has access to at least one CA root certificates private keys. With those
> > they can do a man-in-the-middle attack that the regular user will most
> > likely never spot.
> > 
> > I my own security model I'm protected from NSA by the fact that it will
> > disappear in the flow of all other traffic because NSA is not stealing
> > credit card numbers :) ECDSA with ECDHE is fast and secure according to
> > public sources.
> > 
> > The problem is totally different if you are protecting the secrets of
> > your company that are within the interest of NSA. I'm lucky I don't have
> > to try that.
> 
> On this topic about NSA, I read a article that claimed the NSA was able
> to view httpS traffic live or close to live since they had some backdoor
> access keys.  I don't recall where the article was but since this is a
> knowledgeable bunch, is this true?  If for example I go to my bank or
> credit card website, can they "easily" view that traffic?

If your bank was using certain versions of openssl over the last two years, 
then *any* attacker who knew of the heartbleed bug would have been able to 
steal the private key of the server and decrypt all communications with it.  
It is rumoured (but could be FUD) NSA are likely to have known of this 
vulnerability for at least since November 2013.


> One reason this jumped out at me was that in the article, it was claimed
> that a group of people was going to rewrite the code/software/whatever
> for httpS and other encryption tools.
> 
> If someone has links to such info for me to read and pass on to others,
> that would be great too.

HTTPS on its own does not mean much, if it is using insecure (less secure) 
algorithms.  RC4 and DES are no longer considered secure, but there are 
websites and browsers that still use them in preference to more secure 
cryptos.  Some elliptic curves based algorithms peddled by NIST at the behest 
of NSA are now considered suspicious, if not downright compromised by design.

  http://safecurves.cr.yp.to/

-- 
Regards,
Mick

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

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

[Dale]

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

Mick wrote:
> On Friday 18 Apr 2014 15:27:12 Dale wrote:
>>
>>
>> On this topic about NSA, I read a article that claimed the NSA was able
>> to view httpS traffic live or close to live since they had some backdoor
>> access keys.  I don't recall where the article was but since this is a
>> knowledgeable bunch, is this true?  If for example I go to my bank or
>> credit card website, can they "easily" view that traffic?
>
> If your bank was using certain versions of openssl over the last two
years,
> then *any* attacker who knew of the heartbleed bug would have been
able to
> steal the private key of the server and decrypt all communications
with it. 
> It is rumoured (but could be FUD) NSA are likely to have known of this
> vulnerability for at least since November 2013.

I'm a little vague on some things but it seems the claim was that NSA
had some sort of backdoor that was built in from the beginning of the
project for encryption which sounded like it would include httpS and
others.  Again, the details are fuzzy.  I would say that I need to
bookmark this sort of thing but I already have so many bookmarks that it
is very hard to dig through them as it is.  Adding more may be
counterproductive, yet again.


>
>
>> One reason this jumped out at me was that in the article, it was claimed
>> that a group of people was going to rewrite the code/software/whatever
>> for httpS and other encryption tools.
>>
>> If someone has links to such info for me to read and pass on to others,
>> that would be great too.
>
> HTTPS on its own does not mean much, if it is using insecure (less
secure)
> algorithms.  RC4 and DES are no longer considered secure, but there are
> websites and browsers that still use them in preference to more secure
> cryptos.  Some elliptic curves based algorithms peddled by NIST at the
behest
> of NSA are now considered suspicious, if not downright compromised by
design.
>
>   http://safecurves.cr.yp.to/
>

Neat link.  Lots of red stuff, which I assume is bad.  ;-)  Will dive
into that more later on.

Thanks.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 3220 bytes --]

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

[Mick]

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

On Friday 18 Apr 2014 19:08:21 Dale wrote:
> I'm a little vague on some things but it seems the claim was that NSA
> had some sort of backdoor that was built in from the beginning of the
> project for encryption which sounded like it would include httpS and
> others.  Again, the details are fuzzy.  I would say that I need to
> bookmark this sort of thing but I already have so many bookmarks that it
> is very hard to dig through them as it is.  Adding more may be
> counterproductive, yet again.

I think that you are referring to their Dual_EC_DRBG (Dual Elliptic Curve 
Deterministic Random Bit Generator) which is/was used by RSA Security (not RSA 
the algorithm developed by Ron Rivest, Adi Shamir and Leonard Adleman).

http://www.computing.co.uk/ctg/news/2295881/rsa-warns-customers-against-nsa-compromised-security-product#

I don't know if Schneier said, stay away from elliptic curve algos and use 
symmetric keys instead, because of this.  Others have tried to crack elliptic 
curves and have not been successful - so one has to tread carefully.  Given 
the NSA/NIST and big corporates are all in it up to their neck, I would guess 
that distrusting *everything* they have or could be behind is a healthy 
attitude to take at the moment.  ;-)

-- 
Regards,
Mick

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

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

[Dale]

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

Mick wrote:
> On Friday 18 Apr 2014 19:08:21 Dale wrote:
>> I'm a little vague on some things but it seems the claim was that NSA
>> had some sort of backdoor that was built in from the beginning of the
>> project for encryption which sounded like it would include httpS and
>> others.  Again, the details are fuzzy.  I would say that I need to
>> bookmark this sort of thing but I already have so many bookmarks that it
>> is very hard to dig through them as it is.  Adding more may be
>> counterproductive, yet again.
>
> I think that you are referring to their Dual_EC_DRBG (Dual Elliptic Curve
> Deterministic Random Bit Generator) which is/was used by RSA Security
(not RSA
> the algorithm developed by Ron Rivest, Adi Shamir and Leonard Adleman).
>
>
http://www.computing.co.uk/ctg/news/2295881/rsa-warns-customers-against-nsa-compromised-security-product#
>
> I don't know if Schneier said, stay away from elliptic curve algos and
use
> symmetric keys instead, because of this.  Others have tried to crack
elliptic
> curves and have not been successful - so one has to tread carefully. 
Given
> the NSA/NIST and big corporates are all in it up to their neck, I
would guess
> that distrusting *everything* they have or could be behind is a healthy
> attitude to take at the moment.  ;-)
>

Well, I just wondered if it was true or not.  If the NSA has some sort
of back hack then encryption to them is meaningless.  Thing is, I don't
know if it is true or not.  I wouldn't be surprised if it is for sure.

I try to keep things as secure as I can and protect myself from the bad
guys but this sort of things makes me wonder if it really does much if
any good.  If companies/governments have backdoor ways to get passed it,
then there is no way to know who else can use that too.  All it takes is
for one employee/contractor with the knowledge to decide to sell out and
then the whole thing is compromised.

Imagine if it were to come out that there is a backdoor key to all the
encryption that is currently in use.  That would really throw a wrench
into the whole internet community.  I just read that yet another store
has been hacked into and customer info stolen here in the USA.  Waiting
to see it from a reputable source before getting to deep into it.

Of recent, I have seriously thought of encrypting my /home partition. 
I'm not a crook but like a guy said once in a TV interview, if a person
looks long enough and hard enough, they will find something then build a
career off building the rest.  There are to many laws for anyone to
really be able to safely say they have never broken the law before.

I thought I read that article on Linux Journal but I can't find it there
so it must have been somewhere else.  < shrugs >

Thanks.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 3898 bytes --]

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

[Mick]

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

On Friday 18 Apr 2014 21:27:28 Dale wrote:
> Mick wrote:
> > On Friday 18 Apr 2014 19:08:21 Dale wrote:
> >> I'm a little vague on some things but it seems the claim was that NSA
> >> had some sort of backdoor that was built in from the beginning of the
> >> project for encryption which sounded like it would include httpS and
> >> others.  Again, the details are fuzzy.  I would say that I need to
> >> bookmark this sort of thing but I already have so many bookmarks that it
> >> is very hard to dig through them as it is.  Adding more may be
> >> counterproductive, yet again.
> > 
> > I think that you are referring to their Dual_EC_DRBG (Dual Elliptic Curve
> > Deterministic Random Bit Generator) which is/was used by RSA Security
> 
> (not RSA
> 
> > the algorithm developed by Ron Rivest, Adi Shamir and Leonard Adleman).
> 
> http://www.computing.co.uk/ctg/news/2295881/rsa-warns-customers-against-nsa
> -compromised-security-product#
> 
> > I don't know if Schneier said, stay away from elliptic curve algos and
> 
> use
> 
> > symmetric keys instead, because of this.  Others have tried to crack
> 
> elliptic
> 
> > curves and have not been successful - so one has to tread carefully.
> 
> Given
> 
> > the NSA/NIST and big corporates are all in it up to their neck, I
> 
> would guess
> 
> > that distrusting *everything* they have or could be behind is a healthy
> > attitude to take at the moment.  ;-)
> 
> Well, I just wondered if it was true or not.  If the NSA has some sort
> of back hack then encryption to them is meaningless.  Thing is, I don't
> know if it is true or not.  I wouldn't be surprised if it is for sure.
> 
> I try to keep things as secure as I can and protect myself from the bad
> guys but this sort of things makes me wonder if it really does much if
> any good.  If companies/governments have backdoor ways to get passed it,
> then there is no way to know who else can use that too.  All it takes is
> for one employee/contractor with the knowledge to decide to sell out and
> then the whole thing is compromised.
> 
> Imagine if it were to come out that there is a backdoor key to all the
> encryption that is currently in use.  That would really throw a wrench
> into the whole internet community.  I just read that yet another store
> has been hacked into and customer info stolen here in the USA.  Waiting
> to see it from a reputable source before getting to deep into it.
> 
> Of recent, I have seriously thought of encrypting my /home partition.
> I'm not a crook but like a guy said once in a TV interview, if a person
> looks long enough and hard enough, they will find something then build a
> career off building the rest.  There are to many laws for anyone to
> really be able to safely say they have never broken the law before.
> 
> I thought I read that article on Linux Journal but I can't find it there
> so it must have been somewhere else.  < shrugs >

Encryption still works, at least for some attackers.  The fact that burglars 
can pick locks doesn't mean that you should leave your door unlocked.

FWIW I just checked my bank's website encryption ...  they *still* use RC4!!! 

  O_O

I guess they are keen to make sure all these customers with WinXP and MSIE 7.0 
can still login?  For crying out loud!

It seems that RSA's days may be numbered and elliptic curve cryptography would 
be the way forward, not because of resource constrained mobile devices, but 
also because of recent advances in crypto-analytics which may make RSA 
obsolete:

http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/

-- 
Regards,
Mick

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

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

[Mick]

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

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

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

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

[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] Re: Heartbleed fix - question re: replacing self-signed certs with real ones

[Dale]

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

Mick wrote:
> Encryption still works, at least for some attackers. The fact that burglars can pick locks doesn't
mean that you should leave your door unlocked. FWIW I just checked my
bank's website encryption ... they *still* use RC4!!! O_O I guess they
are keen to make sure all these customers with WinXP and MSIE 7.0 can
still login? For crying out loud! It seems that RSA's days may be
numbered and elliptic curve cryptography would be the way forward, not
because of resource constrained mobile devices, but also because of
recent advances in crypto-analytics which may make RSA obsolete:
http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/


How does one find out what their bank uses?  I'd like to check on what
mine uses.  I have Seamonkey and Firefox installed here IF it matters.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 1502 bytes --]

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

[Matti Nykyri]

On Apr 19, 2014, at 16:17, Joe User <mailinglists@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

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

[Matti Nykyri]

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

On Apr 19, 2014, at 18:29, Dale <rdalek1967@gmail.com> wrote:

> Mick wrote:
> > Encryption still works, at
>       least for some attackers. The fact that burglars can pick locks
>       doesn't mean that you should leave your door unlocked. FWIW I just
>       checked my bank's website encryption ... they *still* use RC4!!!
>       O_O I guess they are keen to make sure all these customers with
>       WinXP and MSIE 7.0 can still login? For crying out loud! It seems
>       that RSA's days may be numbered and elliptic curve cryptography
>       would be the way forward, not because of resource constrained
>       mobile devices, but also because of recent advances in
>       crypto-analytics which may make RSA obsolete:
>       http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/
>     
> 
> How does one find out what their bank uses?  I'd like to check on what mine uses.  I have Seamonkey and Firefox installed here IF it matters. 

Well you can use ssllabs.com. I use it for debuging. Here is what Bank of America uses:

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

-Matti

[-- Attachment #2: Type: text/html, Size: 2095 bytes --]

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

[Mick]

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

On Saturday 19 Apr 2014 16:29:34 Dale wrote:

> How does one find out what their bank uses?  I'd like to check on what
> mine uses.  I have Seamonkey and Firefox installed here IF it matters.

Some banks have reverted to RC4 to protect against TLS v1.0 attacks from the 
BEAST.

I don't think that FF shows the algos used for key exchange and encryption in 
enough detail.  You can see them if you use Chromium and click on the green 
padlock.

I use openssl s_client, e.g.:

openssl s_client -connect www.wellsfargo.com:443

and look for this info:

New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA

-- 
Regards,
Mick

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

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

[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 <mailinglists@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-----

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

[Mick]

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

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

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

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

[Dale]

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

Mick wrote:
> On Saturday 19 Apr 2014 16:29:34 Dale wrote:
>
>> How does one find out what their bank uses?  I'd like to check on what
>> mine uses.  I have Seamonkey and Firefox installed here IF it matters.
>
> Some banks have reverted to RC4 to protect against TLS v1.0 attacks
from the
> BEAST.
>
> I don't think that FF shows the algos used for key exchange and
encryption in
> enough detail.  You can see them if you use Chromium and click on the
green
> padlock.
>
> I use openssl s_client, e.g.:
>
> openssl s_client -connect www.wellsfargo.com:443
>
> and look for this info:
>
> New, TLSv1/SSLv3, Cipher is RC4-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : RC4-SHA
>


I have this little padlock looking thing too.  I dug around and found
this info:

CN = VeriSign Class 3 Extended Validation SSL SGC CA
OU = Terms of use at https://www.verisign.com/rpa (c)06
OU = VeriSign Trust Network
O = "VeriSign, Inc."
C = US

PKCS #1 RSA Encryption

There is another place with info but it doesn't allow me to highlight it
so that I can copy and paste.  Hmmmmmm.

Anyway, is that reasonable for a bank to use?  In case you haven't
noticed, I'm not a wealth of info on encryption, just rich in
questions.  I just know that it is supposed to make things unreadable
without a password, pass key or whatever.

This is currently my bank.

http://cadencebank.com/

Since they changed to a card that a lot of stores don't take, that could
be changing real soon.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 2808 bytes --]

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

[Dale]

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

Matti Nykyri wrote:
> On Apr 19, 2014, at 18:29, Dale <rdalek1967@gmail.com
> <mailto:rdalek1967@gmail.com>> wrote:
>
>> Mick wrote:
>> > Encryption still works, at least for some attackers. The fact that burglars can pick locks
>> doesn't mean that you should leave your door unlocked. FWIW I just
>> checked my bank's website encryption ... they *still* use RC4!!! O_O
>> I guess they are keen to make sure all these customers with WinXP and
>> MSIE 7.0 can still login? For crying out loud! It seems that RSA's
>> days may be numbered and elliptic curve cryptography would be the way
>> forward, not because of resource constrained mobile devices, but also
>> because of recent advances in crypto-analytics which may make RSA
>> obsolete:
>> http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/
>>
>>
>> How does one find out what their bank uses?  I'd like to check on
>> what mine uses.  I have Seamonkey and Firefox installed here IF it
>> matters.
>
> Well you can use ssllabs.com <http://ssllabs.com>. I use it for
> debuging. Here is what Bank of America uses:
>
> https://www.ssllabs.com/ssltest/analyze.html?d=www.bankofamerica.com&hideResults=on
>
>
> -Matti

I get this.

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


I don't know a lot about this encryption stuff but mine don't look to
good.  :/  You got your test graded and mine seems to be bad enough to
not even deserve a grading. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 3430 bytes --]

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

[Joe User]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 19.04.2014 21:33, Dale wrote:
> Matti Nykyri wrote:
>> On Apr 19, 2014, at 18:29, Dale <rdalek1967@gmail.com 
>> <mailto:rdalek1967@gmail.com>> wrote:
>> 
>>> Mick wrote:
>>>> Encryption still works, at least for some attackers. The fact
>>>> that burglars can pick locks
>>> doesn't mean that you should leave your door unlocked. FWIW I
>>> just checked my bank's website encryption ... they *still* use
>>> RC4!!! O_O I guess they are keen to make sure all these
>>> customers with WinXP and MSIE 7.0 can still login? For crying
>>> out loud! It seems that RSA's days may be numbered and elliptic
>>> curve cryptography would be the way forward, not because of
>>> resource constrained mobile devices, but also because of recent
>>> advances in crypto-analytics which may make RSA obsolete: 
>>> http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/
>>>
>>>
>>>
>>> 
How does one find out what their bank uses?  I'd like to check on
>>> what mine uses.  I have Seamonkey and Firefox installed here IF
>>> it matters.
>> 
>> Well you can use ssllabs.com <http://ssllabs.com>. I use it for 
>> debuging. Here is what Bank of America uses:
>> 
>> https://www.ssllabs.com/ssltest/analyze.html?d=www.bankofamerica.com&hideResults=on
>>
>>
>>
>> 
- -Matti
> 
> I get this.
> 
> https://www.ssllabs.com/ssltest/analyze.html?d=cadencebank.com&hideResults=on
> 
> 
> 
> I don't know a lot about this encryption stuff but mine don't look
> to good.  :/  You got your test graded and mine seems to be bad
> enough to not even deserve a grading.
> 
> Dale
> 
> :-)  :-)
> 

You have to use the https-URLs like this one:
https://www.ssllabs.com/ssltest/analyze.html?d=secure1.cadencebanking.com&hideResults=on
Very secure your banks customer-login ;)

Time to move to a safer bank...


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

iQIcBAEBCgAGBQJTUtHkAAoJEHWfQHzr315VmSsQALxIc+McPiO66/eHX2SURyiP
ruo56b2NnB/8h2PNM6u9yeqfqwQeMjuj3CmNM6NnM8R4S1CUBGNP14iubAvgKdWc
JSjkWZZMO/zkdpJQPatWsFriKNRAWncybrc/cQ/h6b9SXsHu0PYtk3grFlKm7fSp
k8bLWTJCTy3pKQW86g3rJ5vGjXP8n1BjF0GgQ5WJjBKJK8iUn8oGzG0M4He2Zi33
t1HONE1lpkpgUG1r7PycKCobQMypMbd/h5zXLrd6RwM5qP6tK/ZzNsFkGXoT3bWt
icZCdlH2vmWUlFMB0fdGORyu0u0qhQ5VVL4PS+rd//aq8WhAobGoTomRU+woSBQY
xuzqmm1ssxrqiPeHCbXvTOnl6EPAWIcCj9YloonPLB9SpNizXufqD5exVJWme/2H
BZYMmfRK2kkIhvEnxb2js7COQtyVcajQ8paQfaYMmKjk/HtdZwfvYy4OV9TLXI7g
zfPKo9vnXPnmg2DvVFnhRZC+KTlqyMC8fZ3TI6uPOWhaQIspx6gN0FpA8gEzD1mt
6Z38C7IdJrv72B3hDoXrZnIA6kmCEVQgky3G5Um1h+qNT19Xb2UuJPnYJoG9Q7KP
idvxPaZBlXUvUePB2CZu2o1plS4m6Nyoglv6HCCdRB9tbonx5NOas6LefiZCpHkk
ceNA84TmDiuVdt32nRZY
=mc4j
-----END PGP SIGNATURE-----

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

[Dale]

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

Joe User wrote:
> On 19.04.2014 21:33, Dale wrote:
> > Matti Nykyri wrote:
> >> On Apr 19, 2014, at 18:29, Dale <rdalek1967@gmail.com
> >> <mailto:rdalek1967@gmail.com>> wrote:
> >>
> >>> Mick wrote:
> >>>> Encryption still works, at least for some attackers. The fact
> >>>> that burglars can pick locks
> >>> doesn't mean that you should leave your door unlocked. FWIW I
> >>> just checked my bank's website encryption ... they *still* use
> >>> RC4!!! O_O I guess they are keen to make sure all these
> >>> customers with WinXP and MSIE 7.0 can still login? For crying
> >>> out loud! It seems that RSA's days may be numbered and elliptic
> >>> curve cryptography would be the way forward, not because of
> >>> resource constrained mobile devices, but also because of recent
> >>> advances in crypto-analytics which may make RSA obsolete:
> >>>
http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/
> >>>
> >>>
> >>>
> >>>
> How does one find out what their bank uses?  I'd like to check on
> >>> what mine uses.  I have Seamonkey and Firefox installed here IF
> >>> it matters.
> >>
> >> Well you can use ssllabs.com <http://ssllabs.com>. I use it for
> >> debuging. Here is what Bank of America uses:
> >>
> >>
https://www.ssllabs.com/ssltest/analyze.html?d=www.bankofamerica.com&hideResults=on
> >>
> >>
> >>
> >>
> -Matti
>
> > I get this.
>
> >
https://www.ssllabs.com/ssltest/analyze.html?d=cadencebank.com&hideResults=on
>
>
>
> > I don't know a lot about this encryption stuff but mine don't look
> > to good.  :/  You got your test graded and mine seems to be bad
> > enough to not even deserve a grading.
>
> > Dale
>
> > :-)  :-)
>
>
> You have to use the https-URLs like this one:
>
https://www.ssllabs.com/ssltest/analyze.html?d=secure1.cadencebanking.com&hideResults=on
> Very secure your banks customer-login ;)
>
> Time to move to a safer bank...
>
>

Well, I have had doubts about their security for a while now since I
think they run windoze anyway.  This sort of confirms it.  They changed
from Visa for their debit card to Discover about a year ago.  I'm get
pretty fed up with going places and them NOT take my card and me being
stuck in awkward situations.  Then finding out that their security is
just barely half what it should be, yep, time to find a new bank.  I
been putting this off for a while now.  As some know, my brother had
cancer and I been busy dealing with that.  We lost him about a month ago
so I'm trying to play catch up.  He beat the cancer but we think he took
to much meds by mistake and it was to late by the time he realized it. 
Changing banks is on my todo list and may have just took a higher
priority.  It just went from not worth much to not worth spit.  ;-)

At least now I know how to check any potential new banks that I am
interested in too.  Thanks for sharing that howto info.

Dale

:-)  :-)


-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 5291 bytes --]

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

[Peter Humphrey]

On Saturday 19 Apr 2014 18:43:50 Matti Nykyri wrote:

> Well you can use ssllabs.com. I use it for debuging. Here is what Bank of
> America uses:
> 
> https://www.ssllabs.com/ssltest/analyze.html?d=www.bankofamerica.com&hideRes
> ults=on

Well, that's an eye-opener and no mistake. I see my bank is rated B overall. 
Could be worse I suppose. Maybe I should forward the results to them.

-- 
Regards
Peter

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

[Mick]

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

On Saturday 19 Apr 2014 19:41:02 Dale wrote:
> Mick wrote:

> > and look for this info:
> > 
> > New, TLSv1/SSLv3, Cipher is RC4-SHA
> > Server public key is 2048 bit
> > Secure Renegotiation IS NOT supported
> > Compression: NONE
> > Expansion: NONE
> > 
> > SSL-Session:
> >     Protocol  : TLSv1
> >     Cipher    : RC4-SHA
> 
> I have this little padlock looking thing too.  I dug around and found
> this info:
> 
> CN = VeriSign Class 3 Extended Validation SSL SGC CA
> OU = Terms of use at https://www.verisign.com/rpa (c)06
> OU = VeriSign Trust Network
> O = "VeriSign, Inc."
> C = US
> 
> PKCS #1 RSA Encryption
> 
> There is another place with info but it doesn't allow me to highlight it
> so that I can copy and paste.  Hmmmmmm.
> 
> Anyway, is that reasonable for a bank to use?  In case you haven't
> noticed, I'm not a wealth of info on encryption, just rich in
> questions.  I just know that it is supposed to make things unreadable
> without a password, pass key or whatever.
> 
> This is currently my bank.
> 
> http://cadencebank.com/
> 
> Since they changed to a card that a lot of stores don't take, that could
> be changing real soon.

You need to go to the URL that they provide for secure banking, not the home 
page of their main website.  They seem to offer a lot of services under 
different URLs.  Not all of them have the same level of protection.  Picking 
two URLs at random:

The Fluent account login page takes me to:

  https://portal.cadencebank.com/consumer/

and openssl s_client tells me:

======================================
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
======================================

So, they use TLSv1, as opposed to the latest TLSv1.2 and their digital 
signature is with the AES symmetric cipher with 128bit keys. This is 
considered safe enough for today. They also use the SHA1 hash which is less 
secure (if you are paranoid that someone may change the packets payload in 
flight).  Since 2004 it was found that practical collision attacks could be 
launched on MD5, SHA-1, and other hash algorithms and NIST has launched a 
competition for the next secure hash SHA3.  However, MD5 and SHA1 are used so 
widely today it could take a loooong time for them to disappear.


However, picking up another banking service of theirs I see that they are 
using RC4 with MD5:

======================================
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
======================================

RC4 is considered completely broken today, even for Microsoft!  :-)

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


The good news are that your bank's servers do not leak any secrets at this 
moment and it seems they never did (they use SUN servers).

-- 
Regards,
Mick

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

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

[Mick]

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

On Sunday 20 Apr 2014 01:18:43 Peter Humphrey wrote:
> On Saturday 19 Apr 2014 18:43:50 Matti Nykyri wrote:
> > Well you can use ssllabs.com. I use it for debuging. Here is what Bank of
> > America uses:
> > 
> > https://www.ssllabs.com/ssltest/analyze.html?d=www.bankofamerica.com&hide
> > Res ults=on
> 
> Well, that's an eye-opener and no mistake. I see my bank is rated B
> overall. Could be worse I suppose. Maybe I should forward the results to
> them.

Many banks, businesses and public institutions have to cater for the lowest 
common denominator, or their help lines would be inundated with irate 
customers being asked to first reboot their MSWindows PC.  Until the beginning 
of April 2014 this would have been a WinXP user with MSIE 8.0.  In Europe up 
to 25% of all PCs are still on WinXP.  This counts out anything exotic in 
encryption capabilities, like ECDHE and ECDSA, because it is only the latest 
versions of Firefox and Chrome that can use these.

This is the reason that banks also employ some other means of authentication, 
in addition to your user ID;  e.g. they typically ask you to enter a few 
characters out of your password (different each time), or additional secret 
data like the name of your favourite teacher, mother's maiden name and the 
like.

Unless someone was recording each and every login of yours with the bank and 
kept a record of each and every password character you ever typed they may 
still not be able to login, without locking up the account and triggering an 
offline replacement of your password.

So I suspect they assume that the Internet connection to their servers should 
be treated as <aheam!> less than private and have deployed additional means of 
at least stopping unauthorised transactions online.

-- 
Regards,
Mick

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

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

[Dale]

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

Mick wrote:
> On Saturday 19 Apr 2014 19:41:02 Dale wrote:
>> Mick wrote:
>
>>> and look for this info:
>>>
>>> New, TLSv1/SSLv3, Cipher is RC4-SHA
>>> Server public key is 2048 bit
>>> Secure Renegotiation IS NOT supported
>>> Compression: NONE
>>> Expansion: NONE
>>>
>>> SSL-Session:
>>>     Protocol  : TLSv1
>>>     Cipher    : RC4-SHA
>>
>> I have this little padlock looking thing too.  I dug around and found
>> this info:
>>
>> CN = VeriSign Class 3 Extended Validation SSL SGC CA
>> OU = Terms of use at https://www.verisign.com/rpa (c)06
>> OU = VeriSign Trust Network
>> O = "VeriSign, Inc."
>> C = US
>>
>> PKCS #1 RSA Encryption
>>
>> There is another place with info but it doesn't allow me to highlight it
>> so that I can copy and paste.  Hmmmmmm.
>>
>> Anyway, is that reasonable for a bank to use?  In case you haven't
>> noticed, I'm not a wealth of info on encryption, just rich in
>> questions.  I just know that it is supposed to make things unreadable
>> without a password, pass key or whatever.
>>
>> This is currently my bank.
>>
>> http://cadencebank.com/
>>
>> Since they changed to a card that a lot of stores don't take, that could
>> be changing real soon.
>
> You need to go to the URL that they provide for secure banking, not
the home
> page of their main website.  They seem to offer a lot of services under
> different URLs.  Not all of them have the same level of protection. 
Picking
> two URLs at random:
>
> The Fluent account login page takes me to:
>
>   https://portal.cadencebank.com/consumer/
>
> and openssl s_client tells me:
>
> ======================================
> New, TLSv1/SSLv3, Cipher is AES128-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : AES128-SHA
> ======================================
>
> So, they use TLSv1, as opposed to the latest TLSv1.2 and their digital
> signature is with the AES symmetric cipher with 128bit keys. This is
> considered safe enough for today. They also use the SHA1 hash which is
less
> secure (if you are paranoid that someone may change the packets
payload in
> flight).  Since 2004 it was found that practical collision attacks
could be
> launched on MD5, SHA-1, and other hash algorithms and NIST has launched a
> competition for the next secure hash SHA3.  However, MD5 and SHA1 are
used so
> widely today it could take a loooong time for them to disappear.
>
>
> However, picking up another banking service of theirs I see that they are
> using RC4 with MD5:
>
> ======================================
> New, TLSv1/SSLv3, Cipher is RC4-MD5
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : RC4-MD5
> ======================================
>
> RC4 is considered completely broken today, even for Microsoft!  :-)
>
>   http://en.wikipedia.org/wiki/RC4
>
>
> The good news are that your bank's servers do not leak any secrets at
this
> moment and it seems they never did (they use SUN servers).
>

Yet.  I would rather not be the next customer to have his ID stolen like
Target, I think the chain Micheal's was stolen in the past couple days
but not positive on that yet.

That bank is not a small bank and I pay fees each month for them to be
able to keep their stuff updated.  If they can't be bothered to keep it
updated and then turn around and give me a card that sucks, well, oh
well.  < picture a thumbs up here >

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 5883 bytes --]

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

[Matti Nykyri]

On Apr 20, 2014, at 11:49, Mick <michaelkintzios@gmail.com> wrote:

> On Sunday 20 Apr 2014 01:18:43 Peter Humphrey wrote:
>> On Saturday 19 Apr 2014 18:43:50 Matti Nykyri wrote:
>>> Well you can use ssllabs.com. I use it for debuging. Here is what Bank of
>>> America uses:
>>> 
>>> https://www.ssllabs.com/ssltest/analyze.html?d=www.bankofamerica.com&hide
>>> Res ults=on
>> 
>> Well, that's an eye-opener and no mistake. I see my bank is rated B
>> overall. Could be worse I suppose. Maybe I should forward the results to
>> them.
> 
> Many banks, businesses and public institutions have to cater for the lowest 
> common denominator, or their help lines would be inundated with irate 
> customers being asked to first reboot their MSWindows PC.  Until the beginning 
> of April 2014 this would have been a WinXP user with MSIE 8.0.  In Europe up 
> to 25% of all PCs are still on WinXP.  This counts out anything exotic in 
> encryption capabilities, like ECDHE and ECDSA, because it is only the latest 
> versions of Firefox and Chrome that can use these.

Yes, this is true. Even gentoo doesn't have a stable firefox that supports TLSv1.2 highest security ciphers C030 and C02C (ECDHE-RSA/ECDSA-AES256-GMC-SHA384). But wht banks should do they should support the most secure ciphers and sort their ciphers lists so that the most secure are at the top. Because what I understood is that browsers will by default use the first cipher in the order the server sent them it supports and not go through the entire list.

A security aware user can ofcourse disable all the bad ciphers he foesn't want to use in his own browser. Now if he tries to connect to a poorly secured site the connection will fail until a common cipher is found. But what is important you will know when you try to make an insecure connection.

> This is the reason that banks also employ some other means of authentication, 
> in addition to your user ID;  e.g. they typically ask you to enter a few 
> characters out of your password (different each time), or additional secret 
> data like the name of your favourite teacher, mother's maiden name and the 
> like.
> 
> Unless someone was recording each and every login of yours with the bank and 
> kept a record of each and every password character you ever typed they may 
> still not be able to login, without locking up the account and triggering an 
> offline replacement of your password.

NSA has this capability. Also i think most of the largest ISPs are capable to do it. All this requires is enough HD space, private key of any CA enabled x509 certificate and access to any router between you and the bank or DNS poisoning of your computer.

> So I suspect they assume that the Internet connection to their servers should 
> be treated as <aheam!> less than private and have deployed additional means of 
> at least stopping unauthorised transactions online.

-- 
-Matti

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

[Mick]

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

On Sunday 20 Apr 2014 10:21:08 Matti Nykyri wrote:
> On Apr 20, 2014, at 11:49, Mick <michaelkintzios@gmail.com> wrote:
> > On Sunday 20 Apr 2014 01:18:43 Peter Humphrey wrote:
> >> On Saturday 19 Apr 2014 18:43:50 Matti Nykyri wrote:
> >>> Well you can use ssllabs.com. I use it for debuging. Here is what Bank
> >>> of America uses:
> >>> 
> >>> https://www.ssllabs.com/ssltest/analyze.html?d=www.bankofamerica.com&hi
> >>> de Res ults=on
> >> 
> >> Well, that's an eye-opener and no mistake. I see my bank is rated B
> >> overall. Could be worse I suppose. Maybe I should forward the results to
> >> them.
> > 
> > Many banks, businesses and public institutions have to cater for the
> > lowest common denominator, or their help lines would be inundated with
> > irate customers being asked to first reboot their MSWindows PC.  Until
> > the beginning of April 2014 this would have been a WinXP user with MSIE
> > 8.0.  In Europe up to 25% of all PCs are still on WinXP.  This counts
> > out anything exotic in encryption capabilities, like ECDHE and ECDSA,
> > because it is only the latest versions of Firefox and Chrome that can
> > use these.
> 
> Yes, this is true. Even gentoo doesn't have a stable firefox that supports
> TLSv1.2 highest security ciphers C030 and C02C
> (ECDHE-RSA/ECDSA-AES256-GMC-SHA384). But wht banks should do they should
> support the most secure ciphers and sort their ciphers lists so that the
> most secure are at the top. Because what I understood is that browsers
> will by default use the first cipher in the order the server sent them it
> supports and not go through the entire list.

I think the browsers go through the list, but agree to support the first 
server preferred cipher that is also supported by the client, even if it is 
lower in the list of preferred ciphers on the client:

http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html


> A security aware user can ofcourse disable all the bad ciphers he foesn't
> want to use in his own browser. Now if he tries to connect to a poorly
> secured site the connection will fail until a common cipher is found. But
> what is important you will know when you try to make an insecure
> connection.
> 
> > This is the reason that banks also employ some other means of
> > authentication, in addition to your user ID;  e.g. they typically ask
> > you to enter a few characters out of your password (different each
> > time), or additional secret data like the name of your favourite
> > teacher, mother's maiden name and the like.
> > 
> > Unless someone was recording each and every login of yours with the bank
> > and kept a record of each and every password character you ever typed
> > they may still not be able to login, without locking up the account and
> > triggering an offline replacement of your password.
> 
> NSA has this capability. Also i think most of the largest ISPs are capable
> to do it. All this requires is enough HD space, private key of any CA
> enabled x509 certificate and access to any router between you and the bank
> or DNS poisoning of your computer.

In Europe I think that the situation for ISPs capturing data is not settled 
yet.  I seem to recall that Germany and Belgium disputed in court a European 
Directive (Data Retention Directive 2006) to capture and store users data.  I 
think that they eventually were forced to implement part of the directive - 
who needs GDR's STASI these days! :p   In the UK data is kept for 1-2 years, 
but that is only what they let us know.  A few days ago the EU Court of 
Justice declared the directive invalid/unlawful, but that has been kept quiet 
in the media.

-- 
Regards,
Mick

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

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

[Mick]

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

On Sunday 20 Apr 2014 10:10:42 Dale wrote:
> Mick wrote:

> > SSL-Session:
> >     Protocol  : TLSv1
> >     Cipher    : RC4-MD5
> > 
> > ======================================
> > 
> > RC4 is considered completely broken today, even for Microsoft!  :-)
> > 
> >   http://en.wikipedia.org/wiki/RC4
> > 
> > The good news are that your bank's servers do not leak any secrets at
> > this moment and it seems they never did (they use SUN servers).
> 
> Yet.  I would rather not be the next customer to have his ID stolen like
> Target, I think the chain Micheal's was stolen in the past couple days
> but not positive on that yet.
> 
> That bank is not a small bank and I pay fees each month for them to be
> able to keep their stuff updated.  If they can't be bothered to keep it
> updated and then turn around and give me a card that sucks, well, oh
> well.  < picture a thumbs up here >

Just a 1/3 of all websites offer TLSv1.2 at the moment and hardly any public 
sites offer it as an exclusive encryption protocol, because they would lock 
out most of their visitors.  This is because most browsers do not yet support 
it.  MSWindows 8.1 MSIE 11 now offers TLSv1.2 by default and has dropped the 
RC4 cipher (since November last year).  I understand they are planning to drop 
SHA-1 next Christmas and have already dropped MD5 because of the Flame 
malware.  This should push many websites to sort out their encryption and SSL 
certificates and move away from using RC4 and SHA1 or MD5.  As I said RC4 has 
been reverted to by many sites as an immediate if interim defence against the 
infamous BEAST and Lucky Thirteen attacks.

According to the Netcraft SSL Survey (May 2013) only a third of all web 
servers out there offer Perfect Forward Secrecy to ensure that even if the 
encryption keys were to be compromised, previous communications cannot be 
retrospectively decrypted.

Elliptic Curve algorithms are not yet included in many browsers and in any 
case the security of these in a post-Snowden world should be questionable 
(well, at least the arbitrarily specified NIST-NSA sponsored curves, which 
OpenSSL is heavily impregnated with).

What I'm saying is that there may be no perfect banking website out there, 
because Internet security is screwed up at the moment, but it is always worth 
looking for a better bet.

-- 
Regards,
Mick

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

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

[Matti Nykyri]

On Apr 20, 2014, at 15:38, Mick <michaelkintzios@gmail.com> wrote:

> On Sunday 20 Apr 2014 10:10:42 Dale wrote:
> 
> Just a 1/3 of all websites offer TLSv1.2 at the moment and hardly any public 
> sites offer it as an exclusive encryption protocol, because they would lock 
> out most of their visitors.  This is because most browsers do not yet support 
> it.  MSWindows 8.1 MSIE 11 now offers TLSv1.2 by default and has dropped the 
> RC4 cipher (since November last year).  I understand they are planning to drop 
> SHA-1 next Christmas and have already dropped MD5 because of the Flame 
> malware.  This should push many websites to sort out their encryption and SSL 
> certificates and move away from using RC4 and SHA1 or MD5.  As I said RC4 has 
> been reverted to by many sites as an immediate if interim defence against the 
> infamous BEAST and Lucky Thirteen attacks.

This is a problem all Microsoft's customers are facing. I wonder why they don't demand more. I hope this publicity that snowden and heartbleed has brought to an average user will change their interests to demand better privacy. Anyways I just wonder who trusts software whose source code isn't open and and reviewed by a large community that don't have a financial interest on you.

> According to the Netcraft SSL Survey (May 2013) only a third of all web 
> servers out there offer Perfect Forward Secrecy to ensure that even if the 
> encryption keys were to be compromised, previous communications cannot be 
> retrospectively decrypted.
> 
> Elliptic Curve algorithms are not yet included in many browsers and in any 
> case the security of these in a post-Snowden world should be questionable 
> (well, at least the arbitrarily specified NIST-NSA sponsored curves, which 
> OpenSSL is heavily impregnated with).
> 
> What I'm saying is that there may be no perfect banking website out there, 
> because Internet security is screwed up at the moment, but it is always worth 
> looking for a better bet.

It is really hard to fight for privacy, because we have large companies and agencies that actively are lobbing politicians and standards for their own personal interests. In order for the security to get better an average user need to gain an interest to it. This seems unlikely because now a days everybody is uploading all their secrets to a cloud computing service etc. But I hope this publicity will change it even slowly.

Another thing is that system administrators need to gain more knowledge on securing their services. For that I think this conversation is quite helpful. A lot of people read this list and it can be found by google. Openssl and gnupg are not very easy to use for someone who doesn't have any knowledge on cryptography. For example openssl will try to use md5 by default even in gentoo if you just try to create x509 cert. And many manual pages are way behind... Newest algorithms are almost never listed there. So you have to truly dig in or ask somebody to find safe and up-to date answers.

-- 
-Matti 

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

[Joe User]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 20.04.2014 18:40, Matti Nykyri wrote:
> On Apr 20, 2014, at 15:38, Mick <michaelkintzios@gmail.com> wrote:
> 
>> On Sunday 20 Apr 2014 10:10:42 Dale wrote:
>> 
>> Just a 1/3 of all websites offer TLSv1.2 at the moment and hardly
>> any public sites offer it as an exclusive encryption protocol,
>> because they would lock out most of their visitors. This is
>> because most browsers do not yet support it.  MSWindows 8.1 MSIE
>> 11 now offers TLSv1.2 by default and has dropped the RC4 cipher
>> (since November last year).  I understand they are planning to
>> drop SHA-1 next Christmas and have already dropped MD5 because of
>> the Flame malware.  This should push many websites to sort out
>> their encryption and SSL certificates and move away from using
>> RC4 and SHA1 or MD5.  As I said RC4 has been reverted to by many
>> sites as an immediate if interim defence against the infamous
>> BEAST and Lucky Thirteen attacks.
> 
> This is a problem all Microsoft's customers are facing.

Take a look on Linux Distros from 2000 when WinXP has been developed,
and you'll see, that the Linux Distros weren't better in this. Same
for the time when WinVista was developed, and the same for Win7 and Win8.
So don't blame Microsoft for things that they did as good as everybody
else did, that would be unfair.

> Anyways I just wonder who trusts software whose source code isn't 
> open and and reviewed by a large community that don't have a 
> financial interest on you.

Ouch, wrong argument, realy! Nobody in the large opensource community
had ever reviewed the heartbeat code in more than two years. This was
not a harmless bug in a mostly unused library, it was a realy big
issue in one of the most used library in the world and *nobody* saw it.
Has openssl ever been carefully audited? I don't think so and i bet
that there are more heartbleed like bugs in openssl.
On the other hand schannel (the Windows cryptolib) is regularly audited.
Sorry, but the large opensource community is blind on both eyes,
whereas the closed source community is only blind on one eye.



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

iQIcBAEBCgAGBQJTVAHEAAoJEHWfQHzr315VBREP/11tSjfwXJEOmJ4kC/PG+8lj
LN1vb/vMLWDny7HaTYRqCX8k49rhLCXTXeCB5sb10qeUX3rtqrudrYc/sGwI/H3E
euhiU4oGK4YLDEQkXQDtFaSjpV0hayNQZruiz7x1mFO5FB05IqBmbSmxZLgKndE/
ydRevZPjvX475yVQ8YBsZRlLP8JQnOfec+4pxh8X+pq8/7THWOpdMqmaXdHwZVkM
p0aZX3NBKQyFCtV/JTriQ/ByRC3OfDQbPY75qup13kr74B1222EGFpStU7TGedgR
A+N36/9VrH/DCObQ78c8hsDfjLgRE5eJXBuYlL9dznKM68DrXGVP3hRkvuRozdQx
KlNeQalkVd2p561dY0m92sCqitQIlTJ4uYEMeo4uIURYfBecQz/21Hk4cAATd+Yo
IFamC3N8lO/iww4JsAzPgaywi2mkBzxH5o0jmSjmUW/aq/Mype7FADE9yFBNYr9P
+E/d8AItXM7ouVfE2n55iz7i8wKIeyxZ2Ob1JMP0Bidxv9haihYMA6VYlmkryPmk
TtR+oLxsGywRz21rBghOvzuyy7cyfBX2uHCo55VmxYIVGMfnYKF4ww/5iomgVtwp
wTRo8JYPu8ixW9GAwtfoydEr4N4WMWyqHveNX+YqQMiQqlz2U1MieL/ILyHplRh8
PU4uCElXb5sYR6/w0KEV
=5FIt
-----END PGP SIGNATURE-----

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

[Dale]

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

Mick wrote:
> On Sunday 20 Apr 2014 10:10:42 Dale wrote:
>> Mick wrote:
>
>>> SSL-Session:
>>>     Protocol  : TLSv1
>>>     Cipher    : RC4-MD5
>>>
>>> ======================================
>>>
>>> RC4 is considered completely broken today, even for Microsoft!  :-)
>>>
>>>   http://en.wikipedia.org/wiki/RC4
>>>
>>> The good news are that your bank's servers do not leak any secrets at
>>> this moment and it seems they never did (they use SUN servers).
>>
>> Yet.  I would rather not be the next customer to have his ID stolen like
>> Target, I think the chain Micheal's was stolen in the past couple days
>> but not positive on that yet.
>>
>> That bank is not a small bank and I pay fees each month for them to be
>> able to keep their stuff updated.  If they can't be bothered to keep it
>> updated and then turn around and give me a card that sucks, well, oh
>> well.  < picture a thumbs up here >
>
> Just a 1/3 of all websites offer TLSv1.2 at the moment and hardly any
public
> sites offer it as an exclusive encryption protocol, because they would
lock
> out most of their visitors.  This is because most browsers do not yet
support
> it.  MSWindows 8.1 MSIE 11 now offers TLSv1.2 by default and has
dropped the
> RC4 cipher (since November last year).  I understand they are planning
to drop
> SHA-1 next Christmas and have already dropped MD5 because of the Flame
> malware.  This should push many websites to sort out their encryption
and SSL
> certificates and move away from using RC4 and SHA1 or MD5.  As I said
RC4 has
> been reverted to by many sites as an immediate if interim defence
against the
> infamous BEAST and Lucky Thirteen attacks.
>
> According to the Netcraft SSL Survey (May 2013) only a third of all web
> servers out there offer Perfect Forward Secrecy to ensure that even if
the
> encryption keys were to be compromised, previous communications cannot be
> retrospectively decrypted.
>
> Elliptic Curve algorithms are not yet included in many browsers and in
any
> case the security of these in a post-Snowden world should be questionable
> (well, at least the arbitrarily specified NIST-NSA sponsored curves,
which
> OpenSSL is heavily impregnated with).
>
> What I'm saying is that there may be no perfect banking website out
there,
> because Internet security is screwed up at the moment, but it is
always worth
> looking for a better bet.
>

Well, my bank only got a C for it's grade.  For what it costs every
month, it should get a A+.  I don't have one of those free checking
accounts.  I pay fees each month for mine.  Plus I have already been
planning to switch ever since they switched my debit card from Visa to
Discover.  I'm tired of finding something online or going into a
business to buy something and then find out they don't take Discover. 
It's just a matter of speed of switching that has changed.

Basically, just one more nail in the coffin.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 4397 bytes --]

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

[Mick]

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

On Saturday 19 Apr 2014 14:17:56 Joe User wrote:
> 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.

I am not knowledgeable enough in cryptanalysis or mathematics, to defend or 
dispute Tanja Lange and Dan Bernstein's analysis, but their safecurves 
evaluation criteria[1] appear logical to me and in any case better than the 
undeclared reasons that NIST/NSA have chosen particular seed values to arrive 
at the secpXXX series while rejected others.

The issue of safe curves to use with TLS has also troubled the IETF TLS 
Working Group members and they raise similar issues [2], while they try to 
strike some working compromise for real world implementations - they admit 
though that these recommendations are very much a temporary state until more 
secure curves/algos show up.

I came across a draft guide on Crypto Hardening for sysadmins in the post-
Snowden era, produced by the bettercrypto.org and thought of sharing with the 
list.  I hope it is useful for people here who look after webservers and 
applications.


  [1] http://safecurves.cr.yp.to/rigid.html
  [2] http://ftp.zut.edu.pl/mirrors/ftp.ietf.org/ietf-mail-archive/uta/2014-01.mail
  [3] https://bettercrypto.org/static/applied-crypto-hardening.pdf

-- 
Regards,
Mick

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

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

[Matti Nykyri]

On Apr 20, 2014, at 20:20, Joe User <mailinglists@rootservice.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 20.04.2014 18:40, Matti Nykyri wrote:
>> On Apr 20, 2014, at 15:38, Mick <michaelkintzios@gmail.com> wrote:
>> 
>>> On Sunday 20 Apr 2014 10:10:42 Dale wrote:
>>> 
>>> Just a 1/3 of all websites offer TLSv1.2 at the moment and hardly
>>> any public sites offer it as an exclusive encryption protocol,
>>> because they would lock out most of their visitors. This is
>>> because most browsers do not yet support it.  MSWindows 8.1 MSIE
>>> 11 now offers TLSv1.2 by default and has dropped the RC4 cipher
>>> (since November last year).  I understand they are planning to
>>> drop SHA-1 next Christmas and have already dropped MD5 because of
>>> the Flame malware.  This should push many websites to sort out
>>> their encryption and SSL certificates and move away from using
>>> RC4 and SHA1 or MD5.  As I said RC4 has been reverted to by many
>>> sites as an immediate if interim defence against the infamous
>>> BEAST and Lucky Thirteen attacks.
>> 
>> This is a problem all Microsoft's customers are facing.
> 
> Take a look on Linux Distros from 2000 when WinXP has been developed,
> and you'll see, that the Linux Distros weren't better in this. Same
> for the time when WinVista was developed, and the same for Win7 and Win8.
> So don't blame Microsoft for things that they did as good as everybody
> else did, that would be unfair.

Ok, that's a good point. Sorry, didn't really think about it that way. It's mostly a user issue for not updating their software. But still the point is correct that the ones that are suffering of this are their customers, although its not Microsoft's fault. But the number of people using a Linux Distro from the year 2000 is neglible... And of course there are many reasons for that.

But what is something to blame Microsoft for is the order of preference that MSIE selects it's cipher. I don't know if user can change this order but i think it would be better to order them by security and not by some other factor ei speed. But thats just my oppinion and I usually try to stay away from windows :)

>> Anyways I just wonder who trusts software whose source code isn't 
>> open and and reviewed by a large community that don't have a 
>> financial interest on you.
> 
> Ouch, wrong argument, realy! Nobody in the large opensource community
> had ever reviewed the heartbeat code in more than two years. This was
> not a harmless bug in a mostly unused library, it was a realy big
> issue in one of the most used library in the world and *nobody* saw it.
> Has openssl ever been carefully audited? I don't think so and i bet
> that there are more heartbleed like bugs in openssl.

Yes heartbleed was solely a bug in openssl and yes it was truely severe and that should never ever be allowed to happen.

> On the other hand schannel (the Windows cryptolib) is regularly audited.
> Sorry, but the large opensource community is blind on both eyes,
> whereas the closed source community is only blind on one eye.


But I still disagree... Everybody has some goals why they are doing something.. Some of these goals might be private and some are public. The public and private goal need not to correlate. For any PLC their true goal is to make money for their stock holders. People are by nature greedy and put their own interests above everybody-else's. I think there are less of these greedy people within the open-source community than in general.

How can you say that nobody is auditing the security of open-source software? We audit all the software and hardware we use! And every company should. Open-source is just easier coz you have the source to look at. Hardware is the trickiest one to audit of-course. Big agencies have capital to put their people to work in the closed source companies and try inject their goals to the code. It is even harder if you inject the vulnerability to hardware as claimed by Snowden.

If you look at Linux kernel I think that is a quite good example on how software should be developed. The update cycle is fast and the few bugs that are found get fixed rapidly. And better the program is written the easier it is to debug and avoid security disasters. Just be reviewing a file you can see how well it is organized and that tells you about the quality of the program.

All these things are mostly opinions and speculation because all the data has not been disclosed. Snowden revealed it to some extent but with that content you can analyze the hole extent of operations. What would you do if there were no limits?

-- 
-Matti

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

[Matti Nykyri]

On Apr 21, 2014, at 2:20, Mick <michaelkintzios@gmail.com> wrote:
> I came across a draft guide on Crypto Hardening for sysadmins in the post-
> Snowden era, produced by the bettercrypto.org and thought of sharing with the 
> list.  I hope it is useful for people here who look after webservers and 
> applications.

Thank you. Good articles. All-in-all it's about the system administrators ability to implement the security to their services not matter what the theory is behind them. So it is really important that sysadmins have good knowledge of security and these links promote that :)

>  [1] http://safecurves.cr.yp.to/rigid.html
>  [2] http://ftp.zut.edu.pl/mirrors/ftp.ietf.org/ietf-mail-archive/uta/2014-01.mail
>  [3] https://bettercrypto.org/static/applied-crypto-hardening.pdf

-- 
-Matti