I have configured my Tomcat 8.5 cipher suites as below
<Connector
....
sslEnabledProtocols="TLSv1.2"
ciphers="
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
... />
While testing the site with www.ssllabs.com I find strange result in Server Supported Cipher Suites section. The list is as below :
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 .... OK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 .... WEAK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA .... WEAK
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 .... OK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 .... WEAK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA .... WEAK
Where are the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 come from, I have not configure them in server.xml ?!
Is it any default list of cipher suites in tomcat ?!
When you specify ciphers, no additional ciphers will be made available, regardless of the capabilities of the cryptographic provider being used (e.g. JSSE, OpenSSL, etc.).
If you are seeing a different set of cipher suites being negotiated, I would check two things:
Your configuration is actually being used. Try adding a syntactic error to your XML configuration file to see if Tomcat still starts. Tomcat should refuse to start if the file is not well-formed, confirming that you are in fact changing the right configuration file.
If you are not directly connecting to Tomcat, you may be negotiating your TLS handshake with another network component such as a reverse proxy which is terminating TLS. If that's the case, the configuration of Tomcat is not relevant; the client is really talking to the reverse proxy and not to Tomcat, so the list of ciphers will be different as far as the client can tell. You will need to reconfigure the reverse proxy in this situation. The cipher suites list in Tomcat is still important, as you want to be using a secure cipher suite even "inside" your own network.
Related
Only some (not all) users are receiving ERR_SSL_PROTOCOL_ERROR in Chrome when attempting to visit my express site. I am not receiving this error, so it is proving a pain to debug.
I am creating a https server using a PFX file I downloaded from my provider (1&1):
var options = {
pfx: fs.readFileSync('./mysite_private_key.pfx'),
passphrase: 'MYPASSPHRASE',
};
https.createServer(options, app).listen(443);
https://whatsmychaincert.com tells me that the chain is correct but complains about the handshake:
[mysite] has the correct chain.
[mysite]: TLS handshake error:
error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error SSL Labs might be able to tell you what went wrong
I've googled this with no success, does anyone know what the problem could be? Ty.
In the end I ditched 1&1 and used GoDaddy's CA service and the problem went away.
A possible source of failed handshake could be the lack of an intermediate certificate, ca option of tls.createSecureContext. It should by public on your provider's website.
Hope this helps.
nowadays , when our server (e.g. 1&1) is securely configured , only tls v1.2 and tls v1.3 are supported ..
so how you debug this:
scan your site with SSL Labs Test too see which ciphers are supported , or alternately see in our nginx/apache config
tail -f the server logs , especially the catchall/other_vhosts log files,since ssl protocol errors might be in the site logs and the generic catchall log when the server cannot decide on the name
try to update the users chrome to support at least tls 1.2
chrome has the some command line switches to change its cipher behaviour:
--ssl-version-max Specifies the maximum SSL/TLS version ("tls1.2" or "tls1.3"). ↪
--ssl-version-min Specifies the minimum SSL/TLS version ("tls1", "tls1.1", "tls1.2", or "tls1.3"). ↪
DANGER ZONE:
as last resort you could try to accept legacy ciphers in your nginx-config ( ssl_ciphers directive) like socat OR (very last resort) socat23 to check which version your clients support,
remember to disable everything below tls v1.2 in production environment
I work on a software application that uses gRPC to establish a bi-directional stream between client and a server.
I'm looking for something similar to this ticket's answer only in java: How to enable server side SSL for gRPC?
I would like to configure my application so that they can choose what TLS scenario they want to use:
Scenario 1: plaintext (no encryption)
Scenario 2: Server-side TLS
Scenario 3: Mutual TLS
For TLS setups, I am using Java on non-Android environments, so I will only be considering the OpenSSL installed scenario using https://github.com/grpc/grpc-java/blob/master/SECURITY.md#openssl-statically-linked-netty-tcnative-boringssl-static
Configuring the server side seems pretty straight forward because it is documented quite well: https://github.com/grpc/grpc-java/blob/master/SECURITY.md#mutual-tls
Here would be the steps for the corresponding TLS options:
Sever-side configuration for Scenario 1: Use builder.usePlaintext
Sever-side configuration for Scenario 2: Add a NettyServerBuilder.sslContext built by SSL Context Builder with GrpcSslContexts.forServer and set the cert chain and cert key (and password if needed)
Sever-side configuration for Scenario 3: Add a NettyServerBuilder.sslContext built by SSL Context Builder with GrpcSslContexts.forServer and set the cert chain and cert key (and password if needed), and also set a trustManager on the sslContextBuidler set to the trust cert file.
The server-side part is well documented which is excellent.
Now I want to configure a NettyChannelBuilder on the client side. The only thing I can find information on this is in this unit test: https://github.com/grpc/grpc-java/blob/master/interop-testing/src/test/java/io/grpc/testing/integration/TlsTest.java
Here are the configurations I think are needed, but need to get confirmation on.
Client-side configuration for Scenario 1: Use nettyChannelBuilder.usePlaintext(true). This will disable TLS on the netty channel to grpc.
Client-side configuration for Scenario 2: Set the sslContext using nettyChannelBuilder.negotiationType(NegotiationType.TLS).sslContext(GrpcSslContexts.configure(SslContextBuilder.forClient(), SslProvider.OPENSSL).build()). This will configure the channel to communicate through TLS to grpc server using the default ciphers and application protocol configs.
Client-side configuration for Scenario 3: Set up TLS for the netty channel using nettyChannelBuilder.negotiationType(NegotiationType.TLS).sslContext(GrpcSslContexts.configure(SslContextBuilder.forClient(), SslProvider.OPENSSL).sslContextBuilder.trustManager(clientAuthCertFile)
.clientAuth(ClientAuth.OPTIONAL).build()) where clientAuthCertFile is the trust cert file and ClientAuth.OPTIONAL can also be ClientAuth.REQUIRED if you require mutual TLS.
Is there anything incorrect with my client-side configurations? Do I need any tweaks? I will add this as a PR to the security.md file after getting some blessing from the community on this post.
I added a hello world TLS PR to the grpc-java project here https://github.com/grpc/grpc-java/pull/3992
the latest version of grpc-java as soon as this pr is merged will have a really nice working hello-world example. So all you have to do is git clone that project from master, and look at the example/README.md.
My understanding is that that 3DES can be configured to use multiple modes including cipher block chaining (CBC) and electronic code book (ECB).
Does anyone know which one is used by IIS whenever 3DES is configured in the machineKey?
In SSL connections. As far as I understand that the the order of the cipher suit that the client offers to the server matters. How can I know what is the order of the client's offered cipher suit in my Firefox or IE browsers?
In FF, I tried to type about:config and then filtered the output to: security.ssl, I got:
Is this is the exact order that the client offers to SSL servers? Does this means, my browser prefers DHE and ECDHE over RSA key exchange because the DHE and ECDHE ciphers came first?
There is nothing in the TLS RFC that says the order matters. Specific servers may choose to honor the order provided by the client as an order of preference, but it isn't required, and neither JSSE not OpenSSL does so to the best of my knowledge.
How can I identify the cipher strength of an active https connection to a linux redhat apache webserver. I want to harden my web server by removing lower strength ciphers and would like to check if clients are even using them.
EDIT
My goal is to avoid negative impact of removal of a lower security cipher that a client relies on. Worst case scenario there is a stupid non browser (or old browser) app that is using an old insecure cipher, when I disallow the use of this cipher his/her app could break. I'm trying to proactively identify if there are any apps/browsers using any of the ciphers I'm going to disable.
You can identify unsuccessful handshakes by enabling the appropriate level of logging on mod_ssl. See the Custom Log Formats section on http://httpd.apache.org/docs/2.2/mod/mod_ssl.html, notably
CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
This should enable you to make a list of ciphers requested by clients and configure Apache accordingly.
Your question and your goal aren't necessarily related. Each active connection may use a difference cipher based on the combination of: (a) the capabilities on the server (b) the capabilities of the client (c) cipher preference of the server and client. Looking at any individual connection will not tell you if your SSL configuration is optimal.
If your goal is to harden your SSL configuration, I suggest you use
the SSL Server Test from SSL labs. It grades your server configuration based on known SSL vulnerabilities and best practices.
The last time I updated my SSL configuration I used the configuration tips from this blog post. Note that understanding of SSL vulnerabilities is constantly changing so I suggest you rerun the test every once in a while to ensure your configuration is the best that is currently known.