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.
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.
For my current project i need to implement http over tls at client ,for this i need a local server able to simulate this . is there any online or offline tool. which i can use and and see the handshake in wireshark .
For watching the TLS handshake you might not get far enough with wireshark. For such kind of monitoring you would ensure the security is low enough for wireshark to be able getting the session key from watching the handshake for decoding the later parts. Thus, you need to avoid any forward secrecy.
Otherwise any (https) server that is accessible (and willing to talk) to your client will do.
In case you are in an environment that is supported (e.g. any unix/linux), you might try using openssl. It allows setting up a server that will do handshake. And it will log the handshake such that you will be able looking at what is going on. This will eliminate the need for using wireshark for debugging.
For achieving this you need a Web Server accepting connection over TLS.I have achieved this on Apache Tomcat web Server.
TLS configuration needs to be done in the server.xml file present in config directory of Tomcat webserver. Connector tag needs to be added in the server.xml file that contains information like
TLS version to be used, port, List of supported Cipher Suites, Keystore path and password, Truststore path and password.
Any regular Rest client can be used to make a call like Postman client. But to use that over TLS/SSL certificate is needed to be installed in Chrome browser.
Hope this answers your doubt.
We have clients who can be using anything, WindowsXP,Vista,Linux....
Currently our systems support SSLV2 and SSLV3.But, we are planning to disable both SSLV2 and SSLV3 in windows server 2008R2 in favour of TLS 1.2.
Will it have any breaking changes with the end user?I'm worried that If I disable SSLV3 ( and SSLV2) , some of the clients who use windowsXP(for example) might not be able to access my web service.
PS: Tried to find a similar question in stackoverflow, didn't find any. So, posting this as a question. :)
This is one of the scenarios where you will NOT be able to support old clients using insecure protocols and expect to have decent security.
If you have not enabled TLS 1.2 yet, do so.
Some clients do not support TLS 1.2 (e.g., older Android versions). You may need to support TLS 1.0 and 1.1 in addition to 1.2. While not ideal, it is definitely better than supporting SSL 2.0 and 3.0.
Post an announcement indicating that your web service is being upgraded to meet minimum security requirements and set a date for retiring insecure protocols.
Optionally, check your server metrics to see what protocols/ ciphers are used. Since you haven't mentioned your web server, I'm assuming it is IIS, in which case this is not easy[1][2].
Retire SSL 2.0 and SSL 3.0. There will be a few clients who will not be able to connect. Plan to have an answer ready for them. If you have clients running XP and using IE6, they have bigger issues than not being able to access your web service.
While you are at it, run your TLS configuration through an online
scanner like SSL Labs to ensure you fix any other issues.
I have successfully built the Web Application but when I try to view the app in the browser it throws "Could not create SSL/TLS secure channel". I tried changing the compile to Debug mode and then it throws "The client and server cannot communicate, because they do not possess a common algorithm" errors.
I have also checked the Regedit.exe for the SSL Protocols and eveything is enabled. I also have the client side test certificate in installed on my machine.
My concern is does the Web Application have the ability to pick the installed certificate from the App Pool or should I write any specific code to use the that particular certificate?
I'm not familiar with .NET, but this kind of error typically occurs if the server is not configured to use a certificate. In this case the only ciphers it can offer are ADH etc, i.e. ciphers which don't require a certificate. Because in this case the connection would be vulnerable to man-in-the-middle attacks most clients don't support such ciphers by default and thus you get the error message that client and server have no ciphers in common.
I would like to display a message to customers who's browser's highest level of encryption is SSLv3. Is it possible for me to target browser settings of SSLv3 and lower? Client or Server code? We will be allowing lower versions of SSL to use our site during a certain grace period. During this grace period, we would like to display a message only to those users that have browser settings of SSL3 or lower.
Not easily. The browser's supported SSL versions are not detectable until the SSL handshake is in progress, and even then only if the browser uses an SSLv2 handshake to allow dynamic version negotiation. If an unsupported version were detected, you would not be able to send a message back since the handshake failed and the connection would be closed before you could send any message. However, SSL itself has an error packet that gets sent during handshaking, and it can specify a version mismatch error.
The best you can do in your own code is support all SSL versions on the server side, let the client complete a handshake normally, and then detect which version was actually used and send back a message if the SSL version is too low.
Or, you could simply enable TLSv1 or higher only, and simply refuse to let older clients connect at all. They just would not get a nice error message unless the browser decided to detect the SSL version mismatch error and display its own pretty message about it.
Firstly, nowadays, you can generally forget about clients that don't support at least SSLv3. SSLv3 has been widely available for many years.
The TLS Client Hello message, sent when the connection is initiated by the browser, should contain the highest TLS version it supports:
client_version
The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this
version of the specification, the version will be 3.3 (see
Appendix E for details about backward compatibility).
Appendix E is of course worth looking at.
(The Client Hello message will also contain the list of cipher suites the client supports, which is possibly relevant for the general idea of your question.)
Of course, this specification is just a "SHOULD", so a client supporting TLS 1.2 could still send a Client Hello for TLS 1.1, but what would be the point? By doing so it would have no chance ever to use TLS 1.2 anyway. It could be a preference box that is turned off, but that would effectively make it a client that doesn't support the highest version anyway. (If you want anything more subtle, you'd need to build a database of known user agents, which will be partly unreliable, and for which you'd need to analyse the full user agent string to know everything possible about the platform.)
Now, how to convey the content of the Client Hello message to your application is another matter, and depends very much on which SSL/TLS stack you use. It might not even be directly possible without modifying that SSL/TLS library or the server you're using.
This being said, you can generally get the negotiated TLS version during the current session quite easily. Since that version is the "lower of that suggested by the client in the client hello and the highest supported by the server" (i.e. "min(max(client), max(server))"). If your server supports SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2, and since the latest version is TLS 1.2 anyway, what you'll get during your current connection will also be the max currently supported by the client. As long as your server supports the latest version, you should be able to know what the client supports at best from any live connection.
If you're behind Apache HTTP server's mod_ssl, you should be able to get that from the SSL_PROTOCOL environment variable. You should also be able to get the protocol from the SSLSession in Java.
(If you are willing to write a more bespoke service, you could pass further details like the cipher suites more directly to your application, like this service from Qualys SSL Labs does, although I'm not sure if it's meant to be widely available or just a test service.)
I'd have to agree with Remy about it being a bit challenging.
However, a good starting point may be to retrieve some SSL (certificate) information.
Something similar to this:
X509Certificate certChain[] =
(X509Certificate[]) req.getAttribute("javax.net.ssl.peer_certificates");
Another way of getting more information is to retrieve the cipher_suite attribute (similar to the code snippet above).
javax.net.ssl.cipher_suite
I hope this (at least) gets you closer.
Good luck.