[openssl-users] stronger Kex
openssl.org at 18informatique.com
Sun Jan 22 22:12:06 UTC 2017
Thank you for this very useful explanation and your time.
I apologize for the delay in response.
Le 27/12/2016 à 10:16, Jakob Bohm wrote :
> On 27/12/2016 09:15, mlrx wrote:
>> Le 21/12/2016 à 16:07, mlrx a écrit :
>>> I have two servers for testing purpose :
>>> - debian 6, apache 2.2, openssl 1.0.1t (mutu)
>>> - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated)
>>> Now, these 2 serveurs offers only those ciphers :
>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>>> I have two goals. First, I would like to use at least secp384r1
>>> and second (no problem), use an ECC certificate.
>>> Is it possible to do it with CHACHA20-POLY1305 ?
>>> Is it possible to use this cipher on those servers ?
>>> openssl ciphers -V CHACHA20 return an error on each server.
>>> I understand it's because there is no chacha20 cipher (?).
>>> Why can I connect a server by SSH with chacha20-poly1305 at openssh.com
>>> and not using it with Apache ?
>>> All advices are welcome :-).
>>> Best regards,
>> Is somebody could explain me the difference between a message who
>> received an answer and this one ?
>> What's wrong ? RTFM ?
> Even though at least one SSH program (OpenSSH) uses the crypto functions
> from the OpenSSL libcrypto, the SSH protocol is completely unrealted to
> the SSL/TLS security protocol.
> So the ability to use specific settings with SSH is almost completely
> unrelated to the ability to use similarly named settings for SSL.
> One major difference is that SSH identifies cryptographic suites by
> strings that can easily be extended by organizations such as openssh.com.
> In contrast, SSL/TLS identifies cryptographic suites by 16 bit numbers
> specified in RFCs and listed in a table published by IANA/ICANN. Thus
> for SSL/TLS libraries such as OpenSSL can really only provide choices
> that were given an official number in an RFC and added to that table
> as part of the RFC publishing process.
> On top of that, the OpenSSL team has a policy of only implementing new
> SSL/TLS cryptographic suites when the number part of the OpenSSL version
> number changes. Thus anything not included in the original OpenSSL
> 1.0.2 release will only be available in 1.1.0 or an even later release
> (because they will not be making a 1.0.3 release). Similarly anything
> not in the original 1.1.0 release will only be in 1.2.0 or later
> (assuming there is no 1.1.1 release).
More information about the openssl-users