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@xxxxxxxxxxx >>> 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
