Hello I recently set up SSL on my server, and the clients that connect to it need to know what cipher suit to use. I use Let's Encrypt certbot on an Ubuntu 20 server and NGINX webserver.
I was following this tutorial from start to finish: MQTT Broker Setup but it doesn't really get into that level of detail. However, my client devices lists:
Is there a default cipher suit that I can expect or a way to look through the lets encrypt files on the server to see what it is using? In general who determines the cipher suit to be used?
Related
I'm trying to configure an embedded Tomcat server so that it can serve HTTP2 in FIPs mode, using BouncyCastle's FIPs libraries. I've set the accepted protocols to TLSv1.2+TLSv1.3. I've tried various suggested cipher suites, but it seems no matter what I set as the cipher suite, Chrome/FF rejects connections on the grounds of "Inadequate Security". If I disable HTTP2, it does not matter what I set as the cipher suite - it just works.
I'm a bit confused.
When BC is in FIPS mode, it requires PKIX as algorithm for the KeyManagerFactory and TrustManagerFactory:
Security.setProperty("ssl.KeyManagerFactory.algorithm", "PKIX");
Security.setProperty("ssl.TrustManagerFactory.algorithm", "PKIX");
Without these two lines the server will be unable to retrieve the keys required by the cipher suite.
We are getting weak cipher vulnerability during system scan and to resolve this I have negated them in string in openssl.conf, but still I am able to connect the local host using these ciphers, e.g. "RC4".
This vulnerability is reported on post 3128 and 8443 in the webserver.
ssl.conf output:
#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!RC4:!DES:!3DES
I'm still able to connect using the RC4 cipher to the local host.
[XXXXXXXXXX ~]$ openssl s_client -cipher 'RC4' -connect 127.0.0.1:3128
CONNECTED(00000003)
Is it the correct way to test, or I am doing something wrong?
Will this change in openssl.conf remove this weak cipher issue during the next scan?
Per the Apache SSLCipherSuite documentation (bolding mine):
This complex directive uses a colon-separated cipher-spec string
consisting of OpenSSL cipher specifications to configure the Cipher
Suite the client is permitted to negotiate in the SSL handshake phase.
Notice that this directive can be used both in per-server and per-directory context. ...
Without your entire ssl.conf file posted, it's impossible to know what's going on.
But I'd think the answer to your problem in any case is the easiest way to reliably configure SSL on a web server: get your ssl.conf values directly from the Mozilla SSL Configuration Generator. It's simple, repeatable, and well-documented.
Put in your system's specific software versions and required level of security, and you'll get back a set of configuration settings to place in your configuration files.
The site and its usage is full documented at Mozilla's Security/Server Side TLS page:
The goal of this document is to help operational teams with the
configuration of TLS on servers. All Mozilla sites and deployment
should follow the recommendations below.
The Operations Security (OpSec) team maintains this document as a
reference guide to navigate the TLS landscape. It contains information
on TLS protocols, known issues and vulnerabilities, configuration
examples and testing tools. Changes are reviewed and merged by the
OpSec team, and broadcasted to the various Operational teams.
...
Recommended configurations
Three configurations are recommended. Pick the right configuration
depending on your audience. If you do not need backward compatibility,
and are building a service for modern clients only (post Firefox
27/Chrome 22), then use the Modern configuration. Otherwise, prefer
the Intermediate configuration. Use the Old backward compatible
configuration only if your service will be accessed by very old
clients, such as Windows XP IE6, or ancient libraries & bots.
...
I am new to SSL/TLS topics, but I need to test the scenario where application deployed on WebLogic 12c (client machine, so to speak) communicates with the SOAP service deployed on WebLogic 12c (server machine). I need to make sure that specific cipher suites are used for this communication. In this regard, I have 2 questions:
Is there a way to set the specific cipher suite in the system properties on the server machine (by setting EXTRA_JAVA_PROPERTIES in one of the startup scripts) to make it choose this cipher suite to communicate to a client machine? If this is not how it can be done, can it be done at all and how?
I can see a lot of cipher suites in the ClientHello message sent by the client machine during the handshake, however when I execute nmap against this machine (nmap -sV --script ssl-enum-ciphers -p port_number machine_name), only a subset of the cipher suites from the ClientHello message is reported. Why? What is the source of truth here? ClientHello message or the result of the above mentioned nmap command?
Ok, I found the answer myself. In order to force the server (WebLogic12c in the above scenario) to choose very specific cipher suite to use in the handshake with the client, you will need to modify $DOMAIN_HOME/config/config.xml file. Search for ssl element and modify it for a server where your service is deployed to (either Admin or managed server). Re-boot WLS after that.
<server>
<name>AdminServer</name>
<ssl>
<name>AdminServer</name>
<enabled>true</enabled>
<ciphersuite>SSL_RSA_WITH_RC4_128_SHA</ciphersuite>
<listen-port>7002</listen-port>
...
</ssl>
Following a really outdated tutorial I managed to create an HTTPS server using OpenSSL with TLS1.2, and I'm very proud of it ;)
However TLS 1.2 is only supported in latest browsers and I would like to have some kind of negotiation of the protocol between the client and server, which I'm sure it can be done, but I'm not able to find how! So that if the client only supports TLS1.0, well use that. And if it only supports SSLv3, use that. Not sure about SSLv2, maybe better leave that...
The code I use right now is:
SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
ssl_method = TLSv1_2_server_method();
ssl_ctx = SSL_CTX_new(ssl_method);
Then the server certificates are loaded and the ssl_ctx is shared among all connections. When a client is accepted by the server socket it is encapsulated in an SSL object (whatever it represents):
ssl = SSL_new(ssl_ctx);
SSL_set_fd(ssl, client_socket);
SSL_accept(ssl);
So I guess that something has to be changed in the ssl_ctx creation to allow more methods... Any idea?
<rant> No decent, extensive documentation can be found for OpenSSL, the best available is a 10 years old tutorial! </rant>
Thanks in advance.
You do this by using SSLv23_method() (and friends) instead of a specific method (e.g. TLSv1_2_server_method() in your example). This sends the SSLv2 ClientHello but also specifies the highest protocol supported. The somewhat outdated man page says:
SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand
the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
client hello messages and will indicate that it also understands SSLv3
and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client
hello messages. This is the best choice when compatibility is a
concern.
This online man page doesn't discuss the newer TLSv1_1 and TLSv1_2 protocols, but I verified in the 1.0.1g source of s23_clnt.c that SSLv23_method() includes them.
You then limit the protocols you actually accept with SSL_CTX_set_options():
The list of protocols available can later be limited using the
SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the
SSL_CTX_set_options() or SSL_set_options() functions. Using these
options it is possible to choose e.g. SSLv23_server_method() and be
able to negotiate with all possible clients, but to only allow newer
protocols like SSLv3 or TLSv1.
Note, however, that you can't enable arbitrary sets of protocols, only contiguous protocols in SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2. For example, you can't choose only SSLv3 and TLSv1_1, omitting TLSv1. This comment in the source explains why:
SSL_OP_NO_X disables all protocols above X if there are some protocols below X enabled. This is required in order to maintain "version capability" vector contiguous. So that if application wants to disable TLS1.0 in favour of TLS1>=1, it would be insufficient to pass SSL_NO_TLSv1, the answer is SSL_OP_NO_TLSv1|SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2.
I'm working on adding SSL support into our existing application and have started to think about backwards compatibility.
The one special case that makes this different than other posts I've read is the server may not necessarily be updated with SSL code. So I'll have an SSL client connecting to a server that knows nothing about SSL.
For the sake of this discussion, the application sends keystrokes one at a time to the server, and for each keystroke a new socket is created. So I need to figure out a way to make this work on the existing port number and not use timeouts to determine if the server supports SSL or not.
Any suggestions on a graceful way to handle this?
(I'm using Winsock and OpenSSL)
Usually applications accept plain connections and direct SSL connections on different ports, e.g. smtp port 25 and smtps port 465, http port 80 and https port 443 etc. Other ways are to use the same port and then have a specific command from the client to upgrade to SSL, e.g. like STARTTLS with smtp or AUTH TLS with ftp.
If these common ways are not an option for you and the client sends the first packet in your protocol anyway (like with http, but not with smtp or ftp) you might do an recv(..MSG_PEEK) after the initial accept to see, what kind of data the client sends without removing the data from the socket buffer yet. If the peeked data look like your plain application protocol you continue there, if they look like a client hello from SSL (see https://security.stackexchange.com/questions/34780/checking-client-hello-for-https-classification) you do an SSL upgrade.