I am working on securing the connection using cipher suite (in my case its - TLS_PSK_WITH_AES_128_CBC_SHA).
On ssl socket I would like to explicitely enable all those TLS versions, which would support the cipher suite under consideration.
I am unable to find any mapping between TLS version vs Supported Cipher suite.
Any help?
The suites are defined together with the various SSL/TLS versions. Wikipedia provides you with a good overview and with links to all necessary standards.
In your case: TLS_PSK_WITH_AES_128_CBC_SHA is defined for SSL3.0 already.
Related
From where does the client fetches the list of cipher suites that it is going to propose to server?
For example, it looks like that on same machine, clients of two different applications can propose the different list of cipher suits.
To limit the scope of question, I want to understand it for RabbitMQ Client and TLS1.2.
More clarification
So I have RabbitMQ service installed on my machine and then in C# code I try to connect (Ex. var connection = factory.CreateConnection()) to it without any cipher suits configuration.
So here my C# application could be considered as Client.
please note that I am asking about the ciphers that client sends in 'Client Hello' message.
P.S. somewhere I read that rabbitmq internally uses openssl, so when I ran the command 'openssl ciphers -s -tls1_2' I got a list that is different when I see rabbitmq client hello's cipher suits in wireshark. Also I don't have any group policy on machine that overrides the ciphers.
See https://tls13.ulfheim.net/ for a nice graphical representation of a TLS 1.3 exchange.
In the second message, ClientHello, the client gives among other things a list of ciphers it supports. Where it gets it? Either hard-coded in the application or computed dynamically once decided to connect, etc. this all depends on the application, so you need to investigate its code source/its configuration.
If you take for example openssl s_client as TLS client, you have -cipher and -ciphersuites configuration options to specify which specific ciphers to announce when connecting.
If you look later in the exchange, there is a ServerHello where the server announces which cipher suite will be used.
How that happens? Typically, the server has its own list of preferred ciphers ordered by "quality" (cryptographic strength like preferring 256bits over 128bits and/or other properties like preferring PFS over non PFS), and based on what it got from the client, it tries to select the "best" one that is supported on both side, which is not necessarily always possible.
Now as you put in comments a specific application (Google Chrome), you can see at https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/ssl_cipher.cc;l=1152?q=cipher&ss=chromium%2Fchromium%2Fsrc the definition of a function called "ssl_create_cipher_list" whose goal is to build the cipher list, starting from all compiled ones, and then applying various rules to enable/disable some and sorting them in an order that makes sense. This is of course highly dependent on the application for how it is done, but you can certainly find similar operations in other toolkits.
Finally, do note that there is a big difference between TLS 1.2 (ciphers) and TLS 1.3 (ciphersuites). They are disjoint sets, and when TLS 1.2 has "myriad" of ciphers in the wild (see for example https://www.openssl.org/docs/man1.1.1/man1/ciphers.html for lots of them), TLS 1.3 defines only 5 ciphersuites (see https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.4) with one being mandatory to implement, so the whole question of auto-negotiation between client and server becomes almost moot.
As you mention explicitly tls1.2 as tag, do note there is no real reason today not to use 1.3 instead (which is why my first link is on purpose specially for 1.3 - the handshake routine is different in 1.2 but identical for things related to your question of ciphers), you will gain a lot of benefits, from simplified operations, better cryptography all around, and fewer holes.
I'm using Liferay 6.2 CE GA2 Framework which is running on JDK7.
While calling Discourse Forum API using Apache httpclient it throws exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure.
I think this is because*JDK7 doesn’t implement any GCM cipher suite.
And Discourse Forum is configured with SSL Protocol: TLSv1.2 and Strong Cipher Suites: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
How to resolve this issue? Or is there any other way to call Discourse API from Java platform.
Thanks,
Saurabh Khandelwal
First of all: Before you fix this problem, you really need to upgrade and patch.
Which also might bring you closer to a solution: The compatibility matrix for Liferay EE 6.2 lists Java 8 as compatible - I'm not sure when this came in, but there's a good chance that the later GA versions in CE are also compatible. With that, you should have a newer set of TLS algorithms.
Otherwise you'd have to ask the Discourse admins to enable some algorithm that's compatible with your Java version.
(Disclaimer: I've not checked available algorithms in Java7, but it sounds like an unsupported algorithm is indeed a plausible root cause)
Did I mention that you really should update urgently?
Version: REBOL/View 2.7.8.3.1 1-Jan-2011
I have run a REBOL script weekly that fetches data for years. The last verified working of the script 21-Oct-2016.
As of today, 28-Oct-2016 the script fails with this error:
** Command Error: SSL Error: error:14077410:SSL routines:SSL23_GET_SERVER_HEL
LO:sslv3 alert handshake failure
Someone suggests that during the SSL/TLS handshake, REBOL only offers ciphers that current servers no longer support. Subsequently, the server my script tried to contact is not willing to work with older ciphers of REBOL and thus the handshake fails.
Is this right? If this is so, REBOL 2.7.8 will become useless before long unless patched.
Incidentally, this fails with Saphirion's R3. In that case, it simply crashes and stops working without spewing an error message.
REBOL/View 2.7.8.3.1 1-Jan-2011
I don't know much about rebol but according to the documentation it is available for a variety of systems, including various UNIX like systems. This suggests that the underlying library used for SSL/TLS is the most commonly used library which covers all supported systems, i.e. OpenSSL.
Given the data of the release if the rebol version this should be either an early version 1.0.0 of OpenSSL or more likely version 0.9.8. None of these OpenSSL releases support TLS 1.2 or ECDHE ciphers which are commonly supported by modern servers and sometimes not only supported but required. In the last case the SSL handshake simply will fail. Other reasons why the handshake might fail is that the site requires Server Name Indication (SNI). While SNI could be supported with OpenSSL 0.9.8 already it wasn't that much used in 2011 and thus only few software supported it at this time. But today SNI is often essential, for example if you try to access sites protected by Cloudflare Free SSL.
Rebol2 only has support for TLS 1.0. If you run the report from ssllabs on that server the report says that the only supported cipher suite for TLS 1.0 is TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA.
Now, Rebol3 and its forks aren't Rebol2, but if you look at the rebol3 source for prot-tls you'll see that the supported cipher suites do not include Elliptic Curve Diffie-Hellman Ephemeral or ECDHE.
We've updated the error message in the mean time so that it now says something more meaningful
read https://www.espacehifi.com/
** Error: Handshake failure - no supported cipher suite available on server
until we get ECDHE suites into rebol3.
I want to enable SSL keys renegotiation in Tomcat as described in https://www.rfc-editor.org/rfc/rfc5746. Tomcat will use JSSE implementation for SSL. Which cipher suite should I use to enable the same?
Tomcat Version: 6.0.44
Java version: Java 1.8
Protocol - TLS 1.2
Meta: I'm not sure this is ontopic here, but security is on-hold. Migrate if necessary.
All Java 8 and 7, and 6 from 6u22 up, enable secure renegotiation per 5746. See the documentation. By default, it is used if the peer offers or accepts it; if the peer does not, the connection is still made but renegotiation is not done because it would/could be insecure. This can be varied two ways:
set system property sun.security.ssl.allowLegacyHelloMessages false. JSSE will not make the connection if the peer does not agree to 5746. This is not actually more secure, but it is more visibly secure to simple minded basic scanners, and people who care about simple minded basic scanners like auditors
set system property sun.security.ssl.allowUnsafeRenegotiation true. This is less secure if the application depends on peer credentials checked after a message. Since client always checks server before any data, this means if server requests (not requires) client authentication, and checks auth status after a request, it can wrongly accept a forged-prefix request.
The protocol implementation of 5746 sometimes uses a fake "ciphersuite" (officially SCSV -- Signalling Cipher Suite Value) in ClientHello. JSSE client can be configured using the "ciphersuite" name TLS_EMPTY_RENEGOTIATION_INFO_SCSV whether to use this SCSV or the extension. All servers always use the extension, and thus this configuration has no effect on JSSE server.
I would like to configure the server to refuse negotation of DES, RC4, MD5, etc. The mono 3.4 release notes say "Network Stack Now allows developers to control which cipher suites to use with TLS/SSL." ... But how?
(Thanks to Sebastien Pouliot for this answer)
You can set a callback for either ClientCipherSuitesCallback or ServerCipherSuitesCallback SSL/TLS. That will allow you to control which ciphers can be used and the selection order (in general most server select the first cipher suites they support).
Sample code is part of the documentation.
And also, since it will likely be difficult for some people to find the valid enumerations, see CipherSuiteFactory.cs