I want to allow this cipher TLS_RSA_WITH_3DES_EDE_CBC_SHA on my server to be compliant with NIST guidelines, i put this on my nginx.conf:
ssl_ciphers 'DES-CBC3-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:!aNULL:!eNULL:!EXPORT:!RC4:!MD5:!PSK:!aECDH';
I thought that i had to put 'DES-CBC3-SHA' but it's still not enabled for TLSv1.1 and TLS1.0
How can i do this ?
You OpenSSL version is unknown. But if you use OpenSSL 1.1.0 then this cipher is not compiled in by default because it is considered broken. You would need to have a custom build of OpenSSL to use this cipher. For more details see SSL v3 Handshake Failure (but only in newer versions of OpenSSL).
Even if you really want to use this broken cipher you should only add it at the end of your cipher string so that all these other and more secure ciphers get preferred and DES-CBC3-SHA gets only used as the (weak) fallback.
Related
I'm reversing an Android application and I noticed, while sniffing, that something weird happens.
TLSv1.3 introduces few new ciphers such as
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
And, from what I've read on OpenSSL documentation (https://wiki.openssl.org/index.php/TLS1.3),
There are new ciphersuites that only work in TLSv1.3. The old ciphersuites cannot be used for TLSv1.3 connections and the new ones cannot be used in TLSv1.2 and below.
Now, this application does something very strange: .
It is using TLSv1.2 with new TLSv1.3 ciphers during "Client Hello" and server, which also supports TLSv1.3, allows it and they start the communication for some reason.
How is that possible? Thank you.
No, you are missing an important new aspect I think ( I can not see your linked image, you should post all relevant data inside the question itself).
For compatibility reasons, TLSv1.3 try to mask itself as TLSv1.2 during ClientHello, see https://www.rfc-editor.org/rfc/rfc8446#section-4.1.2 :
4.1.2. Client Hello
When a client first connects to a server, it is REQUIRED to send the
ClientHello as its first TLS message.
Structure of this message:
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
Note the legacy_version being TLSv1.2 in fact, and then the explanation:
legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.
(See Appendix D for details about backward compatibility.)
As for cipher suites and TLS versions, the situation is more complicated. TLSv1.3 standardized only a few of them as mandatory, for reasons explained in the specification.
However that does not strictly forbid other TLS versions to use them either.
See:
ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS): This document describes the use of the ChaCha stream cipher and
Poly1305 authenticator in version 1.2 or later of the Transport Layer
Security (TLS) protocol
TLS 1.2 Update for Long-term Support with AES+SHA
The "AES GCM" family was defined 10 years ago in https://www.rfc-editor.org/rfc/rfc5116
TLSv1.3 standardized on only perfect forward privacy so that meant only (EC)DHE key exchanges, if not using PSK (see section 2 of RFC8446)
Have a look at https://security.stackexchange.com/a/77018/137710 and https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites
But the TLSv1.3 ciphers suite is defined differently, using new names, because previous ones were not relevant anymore, as TLS 1.3 made some choices about algorithms to use, etc. that removes volatility in some parts.
Hence you will see this warning in OpenSSL changelog:
Separated TLSv1.3 ciphersuite configuration out from TLSv1.2 ciphersuite
configuration. TLSv1.3 ciphersuites are not compatible with TLSv1.2 and
below. Similarly TLSv1.2 ciphersuites are not compatible with TLSv1.3.
In order to avoid issues where legacy TLSv1.2 ciphersuite configuration
would otherwise inadvertently disable all TLSv1.3 ciphersuites the
configuration has been separated out. See the ciphers man page or the
SSL_CTX_set_ciphersuites() man page for more information.
(https://github.com/openssl/openssl/pull/5392)
CloudFlare documentation on https://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suites-does-CloudFlare-use-for-SSL- says below table:
Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 1.3 (IETF TLS 1.3 draft 21).
My server may be attached to a RSA or ECDSA certificate.
In my code I set the prtocol method as
sslmethod = SSLv23_server_method();
and setting the cipher using the SSL_CTX_set_cipher_list() API.
The problem is when the server is attached to ECDSA certificate and if I pass "RSA" cipher SSL_CTX_set_cipher_list() does not return any error though "RSA" cipher is not compatible with ECDSA certificates.
Is there any openssl API which I can use to find out if the cipher we are going to set is compatible with the certificate or with protocol or not?
Is there any openssl API which I can use to find out if the cipher we are going to set is compatible with the certificate or with protocol or not?
If you author the app and own the server, then YES, you do know what to expect. But the general case is NO, you don't know in advance and you can't query for it. You try to setup a channel and if it fails, then you try something else.
Generally speaking, there's no way to know in advance what cipher suites a server supports; or what type of public key is bound in the server's certificate. In fact, there's no way to know what protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2, etc) a server supports. Its the reason for RFC 7405, TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks.
In 2016/2017, about the best you can do is assume:
No SSLv2, SSLv3; only TLS 1.0 and above
Cipher suites from the collection "HIGH:!aNULL:!kRSA:!RC4:!MD5"
"!kRSA" is "no RSA key transport", and it means you can only use ephemeral key exchanges. If a server has a RSA key, then it will only be used for authentication. That is, the key will be used to sign the server's ephemeral values during key exchange so the client knows they are authentic.
When using a VPN-like connection between the two servers (not web servers or anything like it), besides authentication I would like to enable encryption.
The authentication portion is already working, wanted some help at the encryption level.
I know that TLSv1.2 and v1.1 is supported alongside wih SSLv3.
I would only like to use TLSv1.2 and nothing else.
TLSv1.2:!aNULL:!eNULL
Is the the correct cipher suite to use?
Information from https://www.openssl.org/docs/manmaster/apps/ciphers.html seems not to be very helpful...
Can anyone help this this matter?
I would only like to use TLSv1.2 and nothing else.
If you want to use TLS 1.2 only you have to configure the protocol and not the ciphers. Limiting the ciphers to only TLS 1.2 ciphers drops support for all ciphers which are available since SSL 3.0 and which are still supported by TLS 1.2. Depending on the peer you might end up with no shared ciphers this way.
If you still want to restrict the ciphers you might try the string TLSv1.2:!aNULL:!eNULL. This will make it only use ciphers newly introduced in TLS 1.2 and thus implicitly enforce the protocol. But again, it is no guarantee that the server supports these ciphers even if the server can do the TLS 1.2 protocol.
I am running Django 1.7 with gunicorn. I am able to use https using gunicorn by passing certificate and key file as parameter.
When I validate my server by geotrust ssl tools, it says everything is fine except -
This server may be vulnerable: SSLv3 is enabled
Disable SSLv3 and use TLS 1.0 or higher.
I am new to this and not able to understand how to do this. Is this is related to machine or this is related to gunicorn?
gunicorn --ssl-version TLSv1_2 -b 0.0.0.0:8000 project:app
This should enable TLSV1.2 in 8000 port. you can also check if TLSV1 is still active by running below command. if connection established, then target uses tlsv1
openssl s_client -connect hostname:port -tls1
You can also check for tlsv1.2:
openssl s_client -connect hostname:port -tls1_2
Replying to an old thread here, in order to disable anything but TLSv1.2+ and weak ciphers, allowing to pass SSLLabs tests
Gunicorn option --ssl-version allows to set minimal SSL version to use.
Gunicorn --ciphers allows to enable / disable cipher sets or specific ciphers.
Both options accept OpenSSL standard directives.
Good cipher lists can be found on cipherli.st
As of April 2021, in order to have a secure SSL connection according to SSLLabs, I made the following
/usr/bin/gunicorn --ssl-version=TLSv1_2 --ciphers='DEFAULT:!aNULL:!eNULL:!MD5:!3DES:!DES:!RC4:!IDEA:!SEED:!aDSS:!SRP:!PSK' --certfile=/etc/pki/tls/certs/mycert.crt --keyfile=/etc/pki/tls/private/mykey.key
Warning: The singlequotes need to be removed if the commandline is to be put in a systemd unit file.
Exactly as the title states: Is it okay to set OpenSSL to use SSLv3 as a client from a compatibility standpoint?
I have recently run into websites which don't support the SSLv2 helo, therefore I was thinking that from a compatability standpoint it would be better to use SSLv3. Ultimately, Im asking whether or not it is true that SSLv3 will be more compatible than SSLv23 (i.e. SSLv23_client_method).
Well you have to support whatever the websites require that you need to talk to, but ideally at this stage you should forget all about SSlv2 and SSLv3 with the V2 handshake. You should be using TLS as the primary protocol and SSLv3 as a fallback, with the RSA and 256 bit cipher suites given priority.