[openssl-users] stronger Kex

[mlrx]

Hello,
Thank you for this very useful explanation and your time.
I apologize for the delay in response.
Best regards,
benoist.

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 :
>>> Hello,
>>>
>>> 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,
>> Hello,
>> 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).
> 
> Enjoy
> 
> Jakob


-- 
benoist

-- 
benoist