OpenSSL and DH parameters

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
LN
Reply | Threaded
Open this post in threaded view
|

OpenSSL and DH parameters

LN
Hi,

When using SSL is it mandatory to specify along with the certificate (chain) and the private key, also the DH parameters ?
What's the use for DH parameters when specified to OpenSSL ?

Thank you!
Reply | Threaded
Open this post in threaded view
|

RE: OpenSSL and DH parameters

Dave Thompson-5

Do you mean SSL/TLS the protocols and OpenSSL the implementation?

 

For SSL when an ADH or EDH aka DHE suite is negotiated, the server must send DH parameters

and its (nominally one-time) public key, and the client uses or at least matches the parameters

and sends its (ditto) public key. Similarly for AECDH or EECDH/ECDHE the server must send an

ECC curve and public key and the client uses/checks and sends public key, but for ECC the curve

can be and usually(?) is a named curve specified by an OID rather than ‘explicit’ parameters.

 

Other implementations may have default or auto (EC)DH parameters; OpenSSL library does not.

If you are the server and want to support ADH/EDH/DHE or AECDH/EECDH/ECDHE suites,

you must configure the respective “tmp_dh” or “tmp_ecdh” before handshake, or configure

a callback to select/set it during the handshake (which can set the specific key as well).

(For EC, the specified curve must also be acceptable to client(s) per ClientHello extension,

which encourages using the callback or choosing a popular curve like P-256.)

 

A server may want to support ADH/EDH/DHE on its own, or because its client(s) want that.

 

For the non-anonymous suites, server must configure a server cert/chain and privatekey before

handshake. That is “along with” in the sense that both must be done, but not necessarily

at the same place in the code. If you are the client, you do not configure tmp_[ec]dh, and

you configure cert/chain and privatekey only if you use client-auth (also called mutual-auth)

which is relatively rare.

 

OpenSSL commandline s_server does have defaults, although the default tmp_dh is (still) 512 bits,

which is (now) way too small. OTOH it’s nominally only a test tool.

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of LN
Sent: Thursday, October 24, 2013 08:59
To: [hidden email]
Subject: OpenSSL and DH parameters

 

Hi,

 

When using SSL is it mandatory to specify along with the certificate (chain) and the private key, also the DH parameters ?

What's the use for DH parameters when specified to OpenSSL ?

 

Thank you!

Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL and DH parameters

Patrick Pelletier
On 10/24/13 1:59 PM, Dave Thompson wrote:

> (For EC, the specified curve must also be acceptable to client(s) per
> ClientHello extension,
> which encourages using the callback or choosing a popular curve like P-256.)

So, my understanding is that if the "tmp_ecdh" is set to a curve which
is not supported by the client, then OpenSSL ought to just skip the
elliptic curve cipher suites and pick the next acceptable cipher suite
supported by both the client and server.  Is this not the case?

I was puzzled by this message:

http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html

It suggests that if the client offers P-256 and P-384, but the server's
"tmp_ecdh" is set to P-521, then the server will pick an elliptic curve
cipher suite anyway, try to force P-521 on the client, and the handshake
will fail.  Hence his assertion "With TLS, no EC is better than crippled
EC."  This seems very wrong to me!  If the client and server can't agree
on a curve, shouldn't the server just pick a non-elliptic-curve cipher
suite that both it and the client support instead?  It seems like
offering EC should never be worse than not offering EC!

The following draft also seems to suggest the same thing, that if client
and server both support an elliptic curve suite, they will pick it, and
then discover that they don't have any curves in common, and give up,
rather than picking a non-EC suite:

http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/

Is this true?  And why?  It doesn't seem like it should work that way.

--Patrick

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL and DH parameters

Viktor Dukhovni
On Thu, Oct 24, 2013 at 11:52:36PM -0700, Patrick Pelletier wrote:

> >(For EC, the specified curve must also be acceptable to client(s) per
> >ClientHello extension,
> >which encourages using the callback or choosing a popular curve like P-256.)
>
> So, my understanding is that if the "tmp_ecdh" is set to a curve
> which is not supported by the client, then OpenSSL ought to just
> skip the elliptic curve cipher suites and pick the next acceptable
> cipher suite supported by both the client and server.  Is this not
> the case?
>
> I was puzzled by this message:
>
> http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html

With respect to the OpenSSL server implementation I was wrong.
The issue was a bug in the RedHat OpenSSL package's recently
introduced EC support advertising curves it did not implement.

The issue is still possible if clients both send SSLv2 compatible
HELLO (thus no extensions) and include EC ciphersuites.  Since
SSLv2 is now disabled by default, one might say they should not do
that.

> The following draft also seems to suggest the same thing, that if
> client and server both support an elliptic curve suite, they will
> pick it, and then discover that they don't have any curves in
> common, and give up, rather than picking a non-EC suite:
>
> http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/

That's a deeper set of issues, that are still relevant.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
LN
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL and DH parameters

LN
Hi,

I mean in a typical usage of OpenSSL is it mandatory to call SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey(). I know that for RSA keys, for example, the session key exchange is done using the public keys of the client and server.
If my understanding is correct, the DH parameters are used for key exchange also. So if public key are used, is there a situation when the DH parameters will be used instead for key exchange. 
So is my understading correct, that DH might be used if the client uses a protocol for key exchange that is based on DH and if the server doesn't have the DH parameters, the negociation will fail ?

Thank you!


On Friday, October 25, 2013 4:03 PM, Viktor Dukhovni <[hidden email]> wrote:
On Thu, Oct 24, 2013 at 11:52:36PM -0700, Patrick Pelletier wrote:

> >(For EC, the specified curve must also be acceptable to client(s) per
> >ClientHello extension,
> >which encourages using the callback or choosing a popular curve like P-256.)
>
> So, my understanding is that if the "tmp_ecdh" is set to a curve
> which is not supported by the client, then OpenSSL ought to just
> skip the elliptic curve cipher suites and pick the next acceptable
> cipher suite supported by both the client and server.  Is this not
> the case?
>
> I was puzzled by this message:
>
> http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html

With respect to the OpenSSL server implementation I was wrong.
The issue was a bug in the RedHat OpenSSL package's recently
introduced EC support advertising curves it did not implement.

The issue is still possible if clients both send SSLv2 compatible
HELLO (thus no extensions) and include EC ciphersuites.  Since
SSLv2 is now disabled by default, one might say they should not do
that.

> The following draft also seems to suggest the same thing, that if
> client and server both support an elliptic curve suite, they will
> pick it, and then discover that they don't have any curves in
> common, and give up, rather than picking a non-EC suite:
>
> http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/

That's a deeper set of issues, that are still relevant.

--
    Viktor.

______________________________________________________________________
OpenSSL Project                                http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                          [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL and DH parameters

Viktor Dukhovni
On Fri, Oct 25, 2013 at 06:35:08AM -0700, LN wrote:

> I mean in a typical usage of OpenSSL is it mandatory to call
> SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate()
> and SSL_CTX_use_PrivateKey().

No, this is optional.

> I know that for RSA keys, for example, the session key exchange is done
> using the public keys of the client and server.

No, this depends on the cipher-suite.

> If my understanding is correct, the DH parameters are used for
> key exchange also.

No, not "also", rather "instead" when an EDH cipher-suite is
negotiated.

> So if public key are used, is there a situation when the DH parameters
> will be used instead for key exchange.?

When an EDH cipher-suite is negotiated.

> So is my understading correct, that DH might be used if the client
> uses a protocol for key exchange that is based on DH and if the
> server doesn't have the DH parameters, the negotiation will fail

No, the server won't negotiate an EDH cipher-suite when it has no
DH parameters.  Clients don't begin EDH/EECDH key Exchange, servers do.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
LN
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL and DH parameters

LN
Is it recommended to specify and use DH parameters for server ?

I know that RSA encryption/decryption is slow and this is why RSA public keys are used only for establishing the session key which is a symmetric key usually because symetric key encryption is fast.
If the negotiated cipher suite for an RSA encrypted client-server session does not involve using the RSA public keys, then when is RSA used in that session ?


On Friday, October 25, 2013 4:49 PM, Viktor Dukhovni <[hidden email]> wrote:
On Fri, Oct 25, 2013 at 06:35:08AM -0700, LN wrote:

> I mean in a typical usage of OpenSSL is it mandatory to call
> SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate()
> and SSL_CTX_use_PrivateKey().

No, this is optional.

> I know that for RSA keys, for example, the session key exchange is done
> using the public keys of the client and server.

No, this depends on the cipher-suite.

> If my understanding is correct, the DH parameters are used for
> key exchange also.

No, not "also", rather "instead" when an EDH cipher-suite is
negotiated.

> So if public key are used, is there a situation when the DH parameters
> will be used instead for key exchange.?

When an EDH cipher-suite is negotiated.

> So is my understading correct, that DH might be used if the client
> uses a protocol for key exchange that is based on DH and if the
> server doesn't have the DH parameters, the negotiation will fail

No, the server won't negotiate an EDH cipher-suite when it has no
DH parameters.  Clients don't begin EDH/EECDH key Exchange, servers do.


--
    Viktor.
______________________________________________________________________
OpenSSL Project                                http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                          [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: OpenSSL and DH parameters

Dave Thompson-5
In reply to this post by Patrick Pelletier
> From: owner-openssl-users On Behalf Of Patrick Pelletier
> Sent: Friday, October 25, 2013 02:53

> On 10/24/13 1:59 PM, Dave Thompson wrote:
>
> > (For EC, the specified curve must also be acceptable to client(s) per
> > ClientHello extension,
> > which encourages using the callback or choosing a popular curve like
P-256.)
>
> So, my understanding is that if the "tmp_ecdh" is set to a curve which
> is not supported by the client, then OpenSSL ought to just skip the
> elliptic curve cipher suites and pick the next acceptable cipher suite
> supported by both the client and server.  Is this not the case?
>
That's what OpenSSL does -- if there is another mutually acceptable suite.
In particular if the server has an RSA key/cert and the client offers both
ECDHE-RSA but not the server's curve and akRSA, OpenSSL will choose
akRSA and work, but without forward secrecy. If the server has ECDSA
key/cert (only) and the client offers ECDHE-ECDSA and ECDHE-RSA but
not the server's curve and akRSA, none can work and handshake fails.
(Similarly for static-ECDH, and AECDH but in most situations anonymous
suites aren't acceptable at all.)

> I was puzzled by this message:
>
> http://www.metzdowd.com/pipermail/cryptography/2013-
> October/018330.html
>
> It suggests that if the client offers P-256 and P-384, but the server's
> "tmp_ecdh" is set to P-521, then the server will pick an elliptic curve
> cipher suite anyway, try to force P-521 on the client, and the handshake

He doesn't say, and I don't know, if the cited servers are OpenSSL.
And if they are, what suites they enable. Someone who thinks P-521
is needed today might also try to force forward secrecy.
But if OpenSSL server has a choice of EC with unagreed curve
and something else, it will go with the something else, which
is still better than nothing. (Unless the something else is
something badly stupid like export RSA-512 DES-40 MD5.)

> will fail.  Hence his assertion "With TLS, no EC is better than crippled
> EC."  This seems very wrong to me!  If the client and server can't agree
> on a curve, shouldn't the server just pick a non-elliptic-curve cipher
> suite that both it and the client support instead?  It seems like
> offering EC should never be worse than not offering EC!
>
I agree. I think he meant that if the server is mishandling EC nego
and thus causing fallback to no SSL at all, better not to try EC.

Note an OpenSSL server using the ecdh *callback* could dynamically
choose an appropriate curve (and possibly also key) based on what the
client offers, but that's more work and for now requires poking directly
in the SSL/session structure, although I think I remember a rumor that
a better API is coming soon presumably 1.0.2.

> The following draft also seems to suggest the same thing, that if client
> and server both support an elliptic curve suite, they will pick it, and
> then discover that they don't have any curves in common, and give up,
> rather than picking a non-EC suite:
>
> http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/
>
> Is this true?  And why?  It doesn't seem like it should work that way.

I don't think he says that. 1 para 1 says "later parameter[s] can negate
the initial cipher suite choice, requiring returning to the suite list to
try
[another]". (Other) implementations might have this wrong, though.

I'm also not sure what he means by "later"; everything is in the one
ClientHello message, except possibly the issue he notes later about
ECDSA and (E)ECDH with different (but both supported) curves;
that isn't apparent until you get the (Server)Cert and ServerKX.
In most cases that would make auth stronger or weaker than
privacy, which isn't usually desirable, but might be.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: OpenSSL and DH parameters

Dave Thompson-5
In reply to this post by Viktor Dukhovni
> From: owner-openssl-users On Behalf Of Viktor Dukhovni
> Sent: Friday, October 25, 2013 09:46

> On Fri, Oct 25, 2013 at 06:35:08AM -0700, LN wrote:
>
> > I mean in a typical usage of OpenSSL is it mandatory to call
> > SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate()
> > and SSL_CTX_use_PrivateKey().
>
> No, this is optional.
>
Maybe. Assuming only server 'typically' sets key&cert, It depends on what
you want the server to support. If you want to (maybe need to) support
EDH, you must either set_tmp_dh or set_tmp_dh_cb . Ditto for ADH,
but that's rare at least on the public net. If your clients/users demand
forward secrecy -- which since Snowden has become more popular --
then EDH or EECDH are the only authenticated choices to accomplish this,
and as noted recently getting EECDH to interoperate may be an issue.

> > I know that for RSA keys, for example, the session key exchange is done
> > using the public keys of the client and server.
>
> No, this depends on the cipher-suite.
>
Technically DH keys are also public/private pairs (x and y = g^x mod p), but

EDH (and ADH) keys are normally ephemeral so people don't notice them.
(And the same for EC, except it's point multiply instead of modexp.)

akRSA key-exchange uses server RSA keypair for key-exchange; if client-auth
is used client (RSA) keypair is used to sign key-exchange data.

EDH-RSA uses the server (RSA static) keypair to sign key-exchange data, and
both DH keypairs for key-agreement. Static DH (rarely if ever used, and not
yet released in OpenSSL but reportedly will in 1.0.2) uses the DH keypairs
for key-agreement, and higher (RSA/DSA) publickey to verify the cert.

> > If my understanding is correct, the DH parameters are used for
> > key exchange also.
>
> No, not "also", rather "instead" when an EDH cipher-suite is
> negotiated.
>
Right. (Technically DH parameters and keys are used, but the keys are
usually ephemeral, so the application need only care about parameters.)

> > So if public key are used, is there a situation when the DH parameters
> > will be used instead for key exchange.?
>
> When an EDH cipher-suite is negotiated.
>
> > So is my understading correct, that DH might be used if the client
> > uses a protocol for key exchange that is based on DH and if the
> > server doesn't have the DH parameters, the negotiation will fail
>
> No, the server won't negotiate an EDH cipher-suite when it has no
> DH parameters.  Clients don't begin EDH/EECDH key Exchange, servers do.
>
The client doesn't start key-exchange, but what it offers limits what the
server can choose. If the client offers only EDH suite(s), and the server
doesn't have DH parameters, then negotiation will indeed fail.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL and DH parameters

michel-60
In reply to this post by Viktor Dukhovni

If the negotiated cipher suite for an RSA encrypted client-server session does not involve using the RSA public keys, then when is RSA used in that session ?
Not sure to fully understand your question, but the answer may be : 'Just for [server] authentication'

Hope this helps.
Reply | Threaded
Open this post in threaded view
|

SSL/TLS encryption algorithms

Walter H.
Hello,

Which one of the following two is better (1) or (2)?

(1)

SSL_CIPHER=DHE-RSA-CAMELLIA256-SHA
SSL_CIPHER_ALGKEYSIZE=256
SSL_CIPHER_EXPORT=false
SSL_CIPHER_USEKEYSIZE=256
SSL_COMPRESS_METHOD=NULL
SSL_PROTOCOL=TLSv1
SSL_SECURE_RENEG=true


(2)

SSL_CIPHER=AES128-SHA256
SSL_CIPHER_ALGKEYSIZE=128
SSL_CIPHER_EXPORT=false
SSL_CIPHER_USEKEYSIZE=128
SSL_COMPRESS_METHOD=NULL
SSL_PROTOCOL=TLSv1.2
SSL_SECURE_RENEG=true

Thanks,
Walter


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS encryption algorithms

Viktor Dukhovni
On Fri, Nov 01, 2013 at 09:56:10PM +0100, Walter H. wrote:

> Which one of the following two is better (1) or (2)?
>
> (1)
>
> SSL_CIPHER=DHE-RSA-CAMELLIA256-SHA

    $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA
    DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1

> (2)
>
> SSL_CIPHER=AES128-SHA256

    $ openssl ciphers -v AES128-SHA256
    AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

They're both fine.

Your question has no answer, except that neither is known to be
weak enough that you should avoid it.  The latter requires OpenSSL
1.0.1 which (IIRC) introduces support for TLSv1.2.

    - These are available at different minimum protocol versions.
    - These use different bulk crypt algorithms
    - At different key lengths
    - With different key exchange algorithms.

Does your application need to perform faster, offer forward-secrecy, be
most interoperable, ... ?

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS encryption algorithms

Walter H.
Hello,

On 01.11.2013 22:34, Viktor Dukhovni wrote:

> On Fri, Nov 01, 2013 at 09:56:10PM +0100, Walter H. wrote:
>
>> Which one of the following two is better (1) or (2)?
>>
>> (1)
>>
>> SSL_CIPHER=DHE-RSA-CAMELLIA256-SHA
>      $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA
>      DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
>
>> (2)
>>
>> SSL_CIPHER=AES128-SHA256
>      $ openssl ciphers -v AES128-SHA256
>      AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
>
> They're both fine.
>
> Does your application need to perform faster, offer forward-secrecy, be
> most interoperable, ... ?

these was the result of using 2 different browsers with the same SSL
website ...
(1) an old firefox
(2) the latest IE - IE11 on Win 8.1

https://ssl.mathemainzel.info/info/
you can try your browser ...

how would I define forward-secrecy on Apache webserver?

Thanks,
Walter

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS encryption algorithms

Viktor Dukhovni
> >     $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA
> >     DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
> >
> >     $ openssl ciphers -v AES128-SHA256
> >     AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
> >
> >Does your application need to perform faster, offer forward-secrecy, be
> >most interoperable, ... ?
>
> these was the result of using 2 different browsers with the same SSL
> website ...
> (1) an old firefox
> (2) the latest IE - IE11 on Win 8.1
>
> https://ssl.mathemainzel.info/info/
> you can try your browser ...
>
> how would I define forward-secrecy on Apache webserver?

If the server negotiated both ciphers, it already supports
forward-secrecy (aka PFS) if the client does too.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS encryption algorithms

Walter H.
On 01.11.2013 23:12, Viktor Dukhovni wrote:

>>>      $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA
>>>      DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
>>>
>>>      $ openssl ciphers -v AES128-SHA256
>>>      AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
>>>
>>> Does your application need to perform faster, offer forward-secrecy, be
>>> most interoperable, ... ?
>> these was the result of using 2 different browsers with the same SSL
>> website ...
>> (1) an old firefox
>> (2) the latest IE - IE11 on Win 8.1
>>
>> https://ssl.mathemainzel.info/info/
>> you can try your browser ...
>>
>> how would I define forward-secrecy on Apache webserver?
> If the server negotiated both ciphers, it already supports
> forward-secrecy (aka PFS) if the client does too.
>
What about a browser that shows this

SSL_CIPHER=RC4-MD5
SSL_CIPHER_ALGKEYSIZE=128
SSL_CIPHER_EXPORT=false
SSL_CIPHER_USEKEYSIZE=128
SSL_COMPRESS_METHOD=NULL
SSL_PROTOCOL=TLSv1
SSL_SECURE_RENEG=true

Thanks,
Walter

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS encryption algorithms

Viktor Dukhovni
On Sun, Nov 03, 2013 at 06:18:38PM +0100, Walter H. wrote:

> > >how would I define forward-secrecy on Apache webserver?
> >
> > If the server negotiated both ciphers, it already supports
> > forward-secrecy (aka PFS) if the client does too.
>
> What about a browser that shows this
>
> SSL_CIPHER=RC4-MD5
> SSL_CIPHER_ALGKEYSIZE=128
> SSL_CIPHER_EXPORT=false
> SSL_CIPHER_USEKEYSIZE=128
> SSL_COMPRESS_METHOD=NULL
> SSL_PROTOCOL=TLSv1
> SSL_SECURE_RENEG=true

Your server supports PFS, some browsers don't.  Or prefer non-PFS
cipher-suites to PFS.  Default settings of OpenSSL 1.0.0 or later
have sensibly ordered ciphersuites.  Sufficiently recent versions
of Apache enable EDH/EECDH (aka PFS) cipher-suites by setting
appropriate parameters ((p,g) pairs or named curves).

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS encryption algorithms

Walter H.
On 03.11.2013 18:27, Viktor Dukhovni wrote:

> On Sun, Nov 03, 2013 at 06:18:38PM +0100, Walter H. wrote:
>
>>>> how would I define forward-secrecy on Apache webserver?
>>> If the server negotiated both ciphers, it already supports
>>> forward-secrecy (aka PFS) if the client does too.
>> What about a browser that shows this
>>
>> SSL_CIPHER=RC4-MD5
>> SSL_CIPHER_ALGKEYSIZE=128
>> SSL_CIPHER_EXPORT=false
>> SSL_CIPHER_USEKEYSIZE=128
>> SSL_COMPRESS_METHOD=NULL
>> SSL_PROTOCOL=TLSv1
>> SSL_SECURE_RENEG=true
> Your server supports PFS, some browsers don't.  Or prefer non-PFS
> cipher-suites to PFS.  Default settings of OpenSSL 1.0.0 or later
> have sensibly ordered ciphersuites.  Sufficiently recent versions
> of Apache enable EDH/EECDH (aka PFS) cipher-suites by setting
> appropriate parameters ((p,g) pairs or named curves).
>
Ok, I understand; how good is this encryption in comparison
to the other two I mentioned before?

what does SSL_SECURE_RENEG say to me?
some browsers show true, some show false ...

Thanks,
Walter

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SSL/TLS encryption algorithms

Dave Thompson-5
In reply to this post by Viktor Dukhovni
> From: owner-openssl-users On Behalf Of Viktor Dukhovni
> Sent: Friday, November 01, 2013 18:12

<snip: differences between>

> > >     $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA
> > >     DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA
> Enc=Camellia(256) Mac=SHA1
> > >
> > >     $ openssl ciphers -v AES128-SHA256
> > >     AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)
> Mac=SHA256
> > >
> > >Does your application need to perform faster, offer forward-secrecy, be
> > >most interoperable, ... ?
> >
> > these was the result of using 2 different browsers with the same SSL
> > website ...
> > (1) an old firefox
> > (2) the latest IE - IE11 on Win 8.1
> >
Different browsers (or sometimes versions) offer different lists
of supported cipher suites, in different orders. In some cases
the same browser can be reconfigured to offer different suites;
Firefox in particular can do this in about:config. I don't know about
Windows/IE but it wouldn't surprise me at all if there's a registry hack.

Some servers, and particularly OpenSSL and thus Apache by default
(unless you configure HonorCipherOrder), will agree the first suite
in client preference order that the server supports. In practice this
tends to be the first one, or in the first few, of the client preferences.

Firefox is the only client I know that prefers Camellia to AES at same
strength, and thus tends to get a Camellia suite from a server that
supports them, as OpenSSL and thus Apache do unless disabled.

> > https://ssl.mathemainzel.info/info/
> > you can try your browser ...
> >
> > how would I define forward-secrecy on Apache webserver?
>
> If the server negotiated both ciphers, it already supports
> forward-secrecy (aka PFS) if the client does too.
>
Not necessarily. In principle either end could implement and be configured
to support each PFS suite individually; even if both ends support some PFS
suite or suites, they may not intersect and allow actual PFS session.
In practice this mostly breaks down by auth&kx; there would be no sensible
reason to exclude an implementable suite that is otherwise strong enough.
In particular IE/Windows through the latest I have (IE9/Seven) supports
DHE-DSS but not DHE-RSA. If an OpenSSL server has RSA key&cert, and
dh_tmp but not ecdh_tmp params, it supports DHE-RSA but not DHE-DSS.
That means both ends "support" PFS, but they still can't negotiate it.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]