im interested in cert v1.0 for my local server,
how to generate pair of public and private key for server?
There is a list of supported algo for tls v1:
ECDHE-ECDSA-AES256-SHA TLSv1
ECDHE-RSA-AES256-SHA TLSv1
ECDHE-ECDSA-AES128-SHA TLSv1
ECDHE-RSA-AES128-SHA TLSv1
ECDHE-PSK-AES256-CBC-SHA384 TLSv1
ECDHE-PSK-AES256-CBC-SHA TLSv1
RSA-PSK-AES256-CBC-SHA384 TLSv1
DHE-PSK-AES256-CBC-SHA384 TLSv1
PSK-AES256-CBC-SHA384 TLSv1
ECDHE-PSK-AES128-CBC-SHA TLSv1
RSA-PSK-AES128-CBC-SHA256 TLSv1
DHE-PSK-AES128-CBC-SHA256 TLSv1
PSK-AES128-CBC-SHA256 TLSv1
How to use make one of it suitable for serv?
Your requirement together with the ciphers make no sense:
You have a mix of ECDSA, RSA and PSK ciphers, i.e. ciphers which require either an ECC certificate, a RSA certificate or no certificate at all. There is no certificate which covers all of this at the same time.
A certificate is not depending on the TLS version, i.e. there is no TLSv1 certificate.
Related
In istio 1.5.1, when I tried to add a particular cipher suit to the gateway's tls section using this syntax:
minProtocolVersion: TLSV1_3
mode: SIMPLE
cipherSuites: [TLS_AES_128_GCM_SHA256]
I got the following error in the istio-ingress pod's logs:
[Envoy (Epoch 0)] [2020-06-08 15:15:44.033][22][warning][config] [external/envoy/source/common/config/grpc_subscription_impl.cc:87]
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) 0.0.0.0_443: Failed to initialize cipher suites TLS_AES_128_GCM_SHA256.
The following ciphers were rejected when tried individually: TLS_AES_128_GCM_SHA256
If I remove the cipherSuites line from the tls section, there is no errors, and the same cipher suit appears in the list of valid cipher suits.
Any advise? Thanks
As far as I checked in envoy documentation And BoringSSL documentation
TLS 1.3 ciphers do not participate in this mechanism and instead have a
built-in preference order. Functions to set cipher lists do not affect TLS
1.3, and functions to query the cipher list do not include TLS 1.3
ciphers.
cipher_suites
If specified, the TLS listener will only support the specified cipher list when negotiating TLS 1.0-1.2 (this setting has no effect when negotiating TLS 1.3). If not specified, the default list will be used.
In non-FIPS builds, the default cipher list is:
[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]
[ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA
In builds using BoringSSL FIPS, the default cipher list is:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA
Additionally take a look at this github issue.
TIBCO version - TIBCO ActiveMatrix BusinessWorks 5.7.2
Problem:
I am the consumer of the TIBCO server, getting SSL handshake failure. I have tried the following openssl commands to see if it can accept connections. Below are my results:
openssl s_client -showcerts -connect tibco-server:port -verify 3 -tls1 -state
verify depth is 3
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL3 alert read:fatal:unexpected_message
SSL_connect:failed in error
139827261306768:error:140943F2:SSL routines:ssl3_read_bytes:sslv3 alert unexpected message:s3_pkt.c:1493:SSL alert number 10
139827261306768:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1581402078
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
However the same is working when I hit with ssl3 option
openssl s_client -showcerts -connect tibco-server:port -verify 3 -ssl3 -state
verify depth is 3
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 C = AU, ST = <state>, L = <location>, O = <org>, OU = <unit>, CN = <cn>
verify error:num=18:self signed certificate
verify return:1
depth=0 C = AU, ST = <state>, L = <location>, O = <org>, OU = <unit>, CN = <cn>
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
-----BEGIN CERTIFICATE-----
.....
.....
-----END CERTIFICATE-----
---
Server certificate
subject=...
issuer=...
---
No client certificate CA names sent
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 1779 bytes and written 362 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES128-SHA
Session-ID: 8BCEAEADC85613876FFF0E2EAB590A92
Session-ID-ctx:
Master-Key: <master-key-here>
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1581402661
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
I have masked some of the output data.
Any help on why, openssl can connect TIBCO via ssl3 but not tls1.0 ?
This issue got resolved after the security configuration changes in TIBCO server. Now the clients can successfully negotiate TLS1.0 connections with TIBCO server.
FIX
Changed security to be j2se instead of entrust
java.property.TIBCO_SECURITY_VENDOR=j2se
References
https://support.tibco.com/s/article/Tibco-KnowledgeArticle-Article-38616
https://community.tibco.com/questions/tls-compatibility-tibco-bw
I wanted to add TLS/SSL to my kafka setup. To start with, I went through the kafka SSL documenation on main website. I have done the following:
1) Imported the signed certificates to keystore
2) Imported the root CA
3) Verified that the keystore and trust store password are correct by using keytool.
4) Started zookeeper and kafka.
5) Confirmed the following from server.log file:
Registered broker 0 at path /brokers/ids/0 with addresses:
EndPoint(localhost,9092,ListenerName(PLAINTEXT),PLAINTEXT),EndPoint(localhost,9093,ListenerName(SSL),SSL) (kafka.utils.ZkUtils)
my server.properties file have both listeners and advertised.listeners set to the following:
PLAINTEXT://localhost:9092,SSL://localhost:9093
I also have automatic topic creation enabled. When I do:
kafka-console-producer.bat --broker-list localhost:9093 --topic test_ssl --producer.config ....\config\producer.properties
I am getting the following error:
[2017-08-04 16:28:15,265] WARN Error while fetching metadata with correlation id 0 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:15,372] WARN Error while fetching metadata with correlation id 1 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:15,474] WARN Error while fetching metadata with correlation id 2 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,302] WARN Error while fetching metadata with correlation id 3 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,406] WARN Error while fetching metadata with correlation id 4 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,512] WARN Error while fetching metadata with correlation id 5 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
I tried to print out the SSL comms data using openssl
openssl s_client -connect localhost:9093 -debug -tls1 // default kafka broker configs have tlsv1 included
I get the following:
Certificate chain
0 s:/C=GB/ST=Unknown/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=M. Manna
i:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
1 s:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
i:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDfDCCAmQCCQDJKjhOy8KBWjANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMC
R0IxEzARBgNVBAgMClNvbWUtU3RhdGUxDzANBgNVBAcMBkxvbmRvbjEMMAoGA1UE
CgwDU0FQMRcwFQYDVQQLDA5TQVAgRmllbGRnbGFzczESMBAGA1UEAwwJbG9jYWxo
b3N0MSUwIwYJKoZIhvcNAQkBFhZtb2hhbW1lZC5tYW5uYUBzYXAuY29tMB4XDTE3
MDgwNzA5MDU0MFoXDTE5MDgwNzA5MDU0MFowajELMAkGA1UEBhMCR0IxEDAOBgNV
BAgTB1Vua25vd24xDzANBgNVBAcTBkxvbmRvbjEMMAoGA1UEChMDU0FQMRcwFQYD
VQQLEw5TQVAgRmllbGRnbGFzczERMA8GA1UEAxMITS4gTWFubmEwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+sGslb3XocPzigNOmwi9DRE7U6Gos+k1
ADWCS1UGDXPRuS9JocCc2oZ2GJxwipDpF+xRGmeAXIo77S/4GXFjs+DG1R8kojXn
bth3QRTsI6XAMuWOX3AHd4ob0/WSWsPLkGRggCyqU7qwvhuD+MzXB2Q0isRgab/c
lQl6Bj6ETaYTSY8Q2YjCR0ggL4qpYwO62fUexTB5aJx8JMpEbi0V3NZX/2xpic2m
27NW95j7oxi55Q36sYQNpFxfp9pIft6n3+RYTWIQ0bDV5O4W0TGAGPMDkH+t1K9x
ZZEoLik0aOfHw9sp96LkU5oZGGeWEGt6CmWHZQDiBSAyuTe6IjTpAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAC4m+Lpl6pH45VGGvpaolL6PnL5TGcd7FL39C6DxL7Cl
MftcLuG6Egka+eJr/tg+6pdOFfpQjrkeDpeiRIABcLu/VrK99Te7c946QWc8QupC
G/VSQRIHOW6ReBsFf2/wrwT8MWDq2I2GAZSuZ9eTGWggQEwyem6y7C4ujtrcpixq
XwkeE2AU/91O2LlRrP/gW3hwEgD3VruMFhnm/3tTc7ZeLhJPSIE8EMhCk3+j2tgI
ta9J6NZClMxRLgBe1cOH2ru8eGsJtDnT2J+h0m/Ra3t9pD70Amoo84ytE3Iyui8i
kL2gg278c7PF5qosjPkp5sjjvWFypk8iYHTgTidbRCg=
-----END CERTIFICATE-----
subject=/C=GB/ST=Unknown/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=M. Manna
issuer=/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
---
Acceptable client certificate CA names
/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5048 bytes and written 285 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 59884152B1D0B4716F30AC8E43BAC10EBBE92E6BD771AAAD31046035564F2B30
Session-ID-ctx:
Master-Key: 124F0A4796CCE67A696105F4F88798CFC31E76885DEDF3EB1F702EA565543462AB1CCC9B4E6D726BD7489C17ED77C744
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1502101842
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Extended master secret: no
---
Even though the above has error in "Self-signed certificate verification" I think this is common if the CA cert is self signed. Possibly, it is working since SSL Handshake has written/read data.
I can confirm from kafka-topics command (also, server.log) that the topic "test_ssl" creation was successful. I hope it's not because of this underscore "_".
If there was a handshake issue, it would have been caught in the logs (I think, unless the logger is turned off), but it looks like my SSL config has been accepted correctly. Just wanted to know if I have missed something which I cannot quite spot here.
Note - I am not using any SSL/TLS with my Zookeeper. Also, because I am starting the TLS tests locally, I am using a common trust store for now (cacerts in jre/lib/security).
-- my client SSL config
advertised.listeners=SSL://localhost:9093
listeners=SSL://localhost:9093
security.protocol=SSL
ssl.truststore.location=$java_path/jre/lib/security/cacerts
ssl.truststore.password=changeit
ssl.keystore.location=/kafka_2.10-0.10.2.1/config/kafka_client.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
-- my server SSL related properties
security.inter.broker.protocol=SSL
ssl.keystore.location=/kafka_2.10-0.10.2.1/config/kafka_server.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=$java_path/jre/lib/security/cacerts
ssl.truststore.password=changeit
ssl.endpoint.identification.algorithm=HTTPS
ssl.secure.random.implementation=SHA1PRNG
ssl.client.auth=required
fraction of my server logs after startup (with SSL debug enabled):
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Using SSLEngineImpl.
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, called closeOutbound()
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, closeOutboundInternal()
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
[Raw write]: length = 7
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
0000Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
: 15Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
03Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
03 00Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
02 02Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
50*** ClientHello, TLSv1.2
I am not sure what configuration I am missing to get this working. I don't think there is anything wrong in my certificate import order since I have confirmed my methods by matching with instructions here.
Regards,
It was just one config - but I wish there was slightly longer explanation on the documentation for this - but still my bad.
documentation
ssl.endpoint.identification.algorithm
I set it to HTTPS - this means that my client will verify my Fully Qualified Domain Name FQDN against one of the following:
1) Common Name (CN)
2) Subject Alternative Name (SAN)
when I created my ceritificate, I was being polite and added my first and last name thinking "That's my first and last names". Since my original certificates didn't have either of the following:
1) localhost as CN
2) localhost as a DNS
The clients couldn't verify the broker's FQDN against the presented certificate's SAN/CN values. I believe this was the reason since I got it to work after issuing a new self-signed SAN certificate (and importing them into client trust store).
EDIT: We have gotten a new server with updated openssl and are all set, so I'm voting to close this question.
We got this email from Authorize.NET about some technical updates. I am trying to figure out what needs to be done, but my skills are lacking in this area and I could use some help. They had four main points in their email:
After the update is complete on September 21st, any website or payment solution that connects via api.authorize.net that cannot validate SHA-2 signed certificates will fail to connect to Authorize.Net's servers.
Our server uses SHA-1, but we have a GoDaddy Certificate Installed that uses SHA-2.
In October of this year, due to system updates, it will be possible to receive Authorize.Net IDs (Transaction ID, Batch ID, etc.) that are not in sequential order.
I don't think this one will affect us.
As you may already be aware, new PCI DSS requirements state that all payment systems must disable TLS 1.0 by June 30, 2016. To ensure that we are compliant ahead of that date, we will be disabling TLS 1.0 first in the sandbox environment and then in our production environments. Both dates are still to be determined, but please make sure your solutions are prepared for this change as soon as possible.
I know we will need to upgrade OpenSSL on our server. This is what we currently have...
Current Version Recommended Depends On
TLS 1.0 1.2
OpenSSL 0.9.8h 1.0.1
PHP 5.2.6 5.6 Open SSL 1.0.1
Apache 2.2.10 2.4
Linux OS SUSE Enterprise SUSE Enterprise
Server 11 Server 12
Drupal 6.9 7.39 Mysql 5.0.15/PHP 5.4
MySQL 5.0.67 5.6 SUSE Enterprise Server 12 (x86_64)
phpMyAdmin 3.3.3 4.4.14.1 PHP 5.3.7/MySQL 5.5
How should I proceed with upgrading to TLS 1.2?
To meet the technical requirements, its sufficient to use either OpenSSL 1.0.1 or 1.0.2. Both provide TLS 1.2, and both trivially provide SHA-256. (There are other hidden fulfillments, like OpenSSL 1.0.0 does not provide the full compliment of EC gear and the full compliment of TLS 1.2 cipher suites, but 1.0.1 and 1.0.2 does).
In your C-Code that uses OpenSSL, all you need to do for the SSL Context or Session:
/* Useless return value ??? */
SSL_library_init();
const SSL_METHOD* method = SSLv23_method();
if(NULL == method) handleFailure();
SSL_CTX* ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();
/* Cannot fail ??? */
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | \
SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);
For Apache-like server configurations, use something like the following (mine includes +TLSv1 +TLSv1.1):
# From my CentOS production server
SSLProtocol -all +TLSv1.2
You should probably tend to cipher suites, too. For that, in C-code:
const char CIHPHER_LIST[] = "HIGH:!aNULL:!RC4:!MD5"
/* Ensure at least one cipher suite is added, which indicates non-failure */
int rc = SSL_CTX_set_cipher_list(ctx, CIHPHER_LIST);
if(!(rc >= 1)) handleFailure();
And in an Apache-like configuration file:
# From my CentOS production server
SSLCipherSuite HIGH:!aNULL:!MD5:!RC4
If you want to avoid RSA key transport (TLS 1.3 is removing it), then:
SSLCipherSuite HIGH:!aNULL:!MD5:!RC4:!kRSA
When you remove RSA key transport, you are pretty much left with ephemeral key exchange protocols (modulo cipher suites like PSK and SRP).
If you want to explicitly use ephemeral key exchanges, then you will need something like kEECDH:kECDHE:kDHE:kEDH:!aNULL. See openssl ciphers(1) man page for more details.
I'm reading between the lines, but the TLS 1.2 requirement probably has something to do with authenticated encryption, and modes of operation like GCM. For that, use openssl ciphers(1) again:
$ openssl ciphers -v 'HIGH:!aNULL' | grep GCM
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
Or:
$ openssl ciphers -v 'HIGH:!aNULL' | grep GCM | grep -v "Kx=RSA" | cut -d " " -f 1
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
Instead of specifying HIGH:!aNULL:!MD5:!RC4:!kRSA, you can do the following:
const char CIPHER_LIST[] =
"ECDHE-RSA-AES256-GCM-SHA384:"
"ECDHE-ECDSA-AES256-GCM-SHA384:"
"DHE-DSS-AES256-GCM-SHA384:"
"DHE-RSA-AES256-GCM-SHA384:"
"ECDH-RSA-AES256-GCM-SHA384:"
"ECDH-ECDSA-AES256-GCM-SHA384:"
"ECDHE-RSA-AES128-GCM-SHA256:"
"ECDHE-ECDSA-AES128-GCM-SHA256:"
"DHE-DSS-AES128-GCM-SHA256:"
"DHE-RSA-AES128-GCM-SHA256:"
"ECDH-RSA-AES128-GCM-SHA256:"
"ECDH-ECDSA-AES128-GCM-SHA256:"
/* Ensure at least one cipher suite is added, which indicates non-failure */
int rc = SSL_CTX_set_cipher_list(ctx, CIPHER_LIST);
if(!(rc >= 1)) handleFailure();
If you look at the AES256-GCM-SHA384 cipher suite, you'll see uses key transport (Kx=RSA), so you may want to avoid it even though its TLS 1.2. Hece the reason for the grep -v on it.
For completeness, Au=RSA is fine. It just means the server uses its RSA key for signing only. And in practice, Au=DSS is rarely used, so OpenSSL will remove the cipher suite if there's no DSS key.
Now, the hardship is probably getting a distro that provides the latest OpenSSL 1.0.2 and provides the long term support. My CentOS machines don't provide it, so I have to build it from sources, and then rebuild every library or program that depends upon OpenSSL while playing those stupid r-path games.
In your case, that looks like Apache, PHP, Drupal, MySQL, phpAdmin (does anyone really use that when security is a concern :) and friends.
I am using openssl-0.9.8e-7.el5.
openssl ciphers -v shows support only for SSLv2 and SSLv3 cipher types.
However, if I test this connection using tls 1.0 it connects successfully:
openssl s_client -connect hostname:15000 -tls1
CONNECTED(00000003)
SSL handshake has read 2136 bytes and written 413 bytes
...
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
How does it show Protocol is TLSv1 yet OpenSSL itself only supports SSL 3 and 2?
SSLv3 cipher suites are usable with protocol versions SSLv3 and up, i.e also TLS1.x. The version of the cipher suite only tells you the minimal protocol version.
This also means that if you disable SSLv3 and SSLv2 ciphers suites you effectively disable not only SSLv3 but also TLS 1.0 and TLS 1.1, since new cipher suites were only introduced with TLS 1.2.