Is there a difference between RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_RC4_128_SHA, and for my information, any cipher and its TLS_ prepended version?
In RFC 6101 (SSL 3.0) all cipher suites start with "SSL_".
In RFC 2246 (TLS 1.0) all cipher suites start with "TLS_", however the two-byte identifier of the cipher suites are identical to the cipher suites of SSL 3.0 (of course only for ciphers which exist in SSL and TLS).
Therefore I assume that the cipher suite without prepended TLS was used in a context where both protocols (SSL and TLS) are used.
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.
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).
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.
Is there way to have different cipher suite configurations for different SSL/TLS versions?
For eg. I want to have different cipher suites for TLS 1.1 and different suites for TLS 1.0
So If client supports TLS 1.0 as highest protocol, different suites will be preferred
I am trying to enable TLS 1.2 on Tomcat on Spring-boot 1.2.1. Android 5.0 is failing to connect to the default SSL settings, due to an SSL handshake failure. Android 4.4, iOS, Firefox, and Chrome all connect to the default version. I think this is because of a mismatch in the TLS protocols supported in Android 5.0 and the spring boot tomcat defaults (TLS v1?).
I imagine I want to change this application.properties setting:
server.ssl.protocol=TLS
but I have not located the other acceptable strings (or if there are any, even). There is no enumeration that I can find by searching on "protocol" in spring boot github.
I have tried "TLSv1.2", but this appears to have no effect.
The current SSL configuration in application.properties is:
server.ssl.key-store = chainedcertificates.p12
server.ssl.key-store-password = secret
server.ssl.key-store-type = PKCS12
How do you enable TLS 1.2 in spring boot?
If it matters, I am using Java 1.7. The documentation for this seems to indicate it should support TLS 1.2.
Tomcat 8 seems to have support present. I am not sure how to check exactly which version is running in spring boot.
You may experience an SSL handshake error due to the default ciphers that spring boot includes. It is recommended that you define a set of ciphers. We had a similar issue, and the way we fixed it was by using SSLScan on the caller and then scanning our system to see if there were any matches. This lead us to find out that there were no matches and helped us define a list of ciphers we should support.
Using SSLScan these are the default ciphers spring boot will use:
Preferred TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 1024 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 DHE 1024 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 1024 bits
To enable TLS 1.2 and to define the cipher list please do the following:
#enable/diable https
server.ssl.enabled=true
#ssl ciphers
server.ssl.ciphers=TLS_RSA_WITH_AES_128_CBC_SHA256, INCLUDE_ANY_OTHER_ONES_YOU_NEED_TO_SUPPORT
# SSL protocol to use.
server.ssl.protocol=TLS
# Enabled SSL protocols.
server.ssl.enabled-protocols=TLSv1.2
For a list of of ciphers you can use https://testssl.sh/openssl-rfc.mapping.html and https://msdn.microsoft.com/en-us/library/windows/desktop/mt813794(v=vs.85).aspx
TLS 1.2 is enabled by default in spring-boot 1.2.1. This can be verified by running the following from the command line
openssl s_client -connect serverAddress:port
which outputs
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
So my problem must be something separate.