I've been fighting some random IOExceptiosn over SSL which we believe to be SSL handshake issues when dealing with a lot of connections at once.
I read that Session resumption might help with this.
Googling I found some information on adding a registry key and using some power shell commands to enable it on Windows and IIS
https://forums.iis.net/t/1239418.aspx?How+to+enable+TLS+session+resumption+or+Optimize+TLS+handshake+on+Windows+2016+
using https://ssllabs.com to test it still shows disabled so I'm not sure what I'm doing wrong or even if this is the correct approach to resolving the issues.
Related
I have, unsuccessfully, been trying to install RavenDB 5 on a Win 2012R2 server in secure mode, however, getting error messages that are not in Raven's documentation under troubleshooting. I have seen similar errors and applied all their suggestions - they blame port numbers being blocked on firewalls (disabled firewall completely - so no luck there) or IP address binding (when I set it up in unsecure mode, it worked fine - so no luck there).
I am using the downloaded version Free Community version. I think maybe that Windows Server 2012R2 does not support TLS1.2 or there's a configuration issue
Here's the message
Setting up RavenDB in Let's Encrypt security mode failed.
System.InvalidOperationException: Setting up RavenDB in Let's Encrypt security mode failed.
---> System.InvalidOperationException: Validation failed.
---> System.InvalidOperationException: Failed to simulate running the server with the supplied settings using: https://a.******.ravendb.community:60443
---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: Authentication failed because the remote party sent a TLS alert: 'HandshakeFailure'.
---> System.ComponentModel.Win32Exception (0x80090326): The message received was unexpected or badly formatted.
--- End of inner exception stack trace ---
Besides disabling the firewall in WinServer completely (tried opening every port that may be a problem including 60443, 38888, 8080 (I know, it's not there, but), 80, 443, but that did nothing, so I disabled the firewall (bad form - yes, I know).
Since I use Let's Encrypt on IIS for a couple of other sites with other port #s and have not had any problem with auto-renewals, I figure that maybe it's a Kestrel configuration issue (so looking into this). The ambiguity of this error: HandshakeFailure could mean hundreds of different things, so it's hard to determine what.
It looks like RavenDB is running a simulation "Failed to simulate running the server" and, perhaps it's a bug on their end (perhaps LetsEncrypt does not recognize the simulation?).
Anywho, before saying to heck with this DB (which has raving reviews) and moving on to another NoSQL database like FoundationDB or CouchDB, I'd love to figure out how to secure it. It DOES WORK in nonsecure mode fine!!
Any ideas?
The issue is that Windows Server 2012R2 lacks the ciphers that are required by RavenDB.
To fix that, please make sure you enabled TLS 1.2 and add the following ciphers:
You can use IIS Crypto to add the ciphers, please see:
https://stackoverflow.com/a/63274439/11341261
Turns out, Windows Server 2012R2 does not come with the following cipher suites:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Because of this, it's not possible to use Let's Encrypt (as configured for RavenDB) on a Windows 2012R2 Server.
We are running a legacy application on an Apache v7.0.47 server behind an Apache2 HTTPD proxy (v2.4.23).
I am trying to upgrade the Java version on the server (used by both the proxy as well as the tomcat) from v1.8.0_181 to v1.8.0_303.
After that upgrade the Tomcat does not respond any more to the Apache's passed-on requests (the application itself comes up and runs fine).
Both the Apache on its network facing side as well as Apache and Tomcat among each other were configured to "talk" TLS1.2 already for a while, so I don't think that the disabling of TLSv1.0 and TLSv1.1 in the later Java version is the cause of the issue here. And there is no error message in the logs giving any clue. The only indication is, that the Tomcat seems to close and tear down the connection without any response after having receiving the request. That seems to happen already in the SSL layer, since there is no entry in the access-log (of Tomcat).
Switching back to the "old" Java gets things going again, so firewall, network etc. are definitely NOT the issue here. With the newer Java version the connection setup fais again, causing the HTTPD to emit a "502 Bad gateway" error.
Any idea anyone what could cause the Tomcat to reject the HTTPD's requests just based on the Java version? Additional SSL verifications enabled by default in the newer stack? I searched extensively but didn't surface any suspect, yet.
Later addition: trying to identify the issue I found out that with Java v1.8.0_231 things are still working, with v1.8.0_241 and higher it fails.
Inspecting the release notes now to find a hint...
Any ideas or experiences with that upgrade anyone?
Just for the records - in case someone else stumbles over this question:
The issue here was that from Java v1.8.0_241 on upwards Java security verifies that a certificate chain read from a certificate store is rooted in a CA certificate that has a proper CA-flag. Since we were using an old certificate and trust store that had been generated with an old release of the java keytool back than this flag was missing and the new Java version thus rejected all the entries in that certificate file. It thus aborted the SSL connection setup and simply closed the connection without any response or indication.
There is a VM option -Djdk.security.allowNonCaAnchor=true that one can add to Tomcat's JAVA_OPTS variable (typically in a file setenv.sh) to disable this verification. After adding that our Tomcat was again responding to SSL-requests and worked OK again.
BTW: when trying to analyze SSL issues like the above the option -Djavax.net.debug=all:handshake:verbose proved to be a real live-saver! With this option one gets very details log output and can follow SSL handshakes and connection setups in detail. Once I had finally gotten a first useful error message pointing to this CA-flag issue searching for a solution (or rather workaround in this case) proved to be a snap compared to the initial search for what could be the issue here.
I'm testing SSL/TLS stream proxying within NGINX that will connect to a web server using gnutls as the underlying TLS API. Using the command line test tool in gnutls (gnutls-serv) the entire process works, but I can't understand the logic:
the NGINX client (proxying HTTP requests from an actual client to the gnutls server) seems to want to handshake the connection multiple times. In fact in most tests it seems to handshake 3 times without error before the server will respond with a test webpage. Using wireshark, or just debugging messages, it looks like the socket on the client side (in the perspective of the gnutls server) is being closed and reopened on different ports. Finally on the successful connection, gnutls uses a resumed sessions, which I imagine is one of the previously mentioned successful handshakes.
I am failing to find any documentation about this sort of behaviour, and am wondering if this is just an 'NGINX thing.'
Though the handshake eventually works with the test programs, it seems kind of wasteful (to have multiple expensive handshakes) and implementing handshake logic in a non-test environment will be tricky without actually understanding what the client is trying to do.
I don't think there are any timeouts or problems happening on the transport, the test environment is a few different VMs on the same subnet connected between 1 switch.
NGINX version is the latest mainline: 1.11.7. I was originally using 1.10.something, and the behaviour was similar though there were more transport errors. Those errors seemed to get cleaned up nicely with upgrading.
Any info or experience from other people is greatly appreciated!
Use either RSA key exchange between NGINX and the backend server or use SSLKEYLOGFILE LD_PRELOAD for NGINX to have the necessary data for Wireshark to decrypt the data.
While a single incoming connection should generate just one outgoing connection, there may be some optimisations in NGINX to fetch common files (favicon.ico, robots.txt).
I am using an iOS app and I get the below error when testing in iOS 9.
CFNetwork SSLHandshake failed (-9806)
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9806)
I found a number of links saying this could be due to the NSAppTransportSecurity suggesting to add exception for my domain or to disable ATS. But my server does support TLS1.2 and I get this issue only intermittently. Had this been due to the NSTransportSecurity I assume that the issue should be consistent.
Whats strange is that this is not consistent. The app works fine and is able to connect to server in most cases. But after a while I get the above error. I use NSURLCONNECTION. Most of the app interaction is like click on a button and it makes a network call to server(tomcat). Once the SSL failed error occurs, the only way to get the app to send requests successfully to server is by killing the app and starting again. I have tried changing the connection from wifi to 3g during the issue, and even restarting the server once the issue happens but I could find no luck. I am able to work fine with safari and other apps. I have been trying to find a solution for this for some time now. The server is not forward secrecy enabled.
To check the issue deeply I verified the SSL packets from the client.
When the issue occurs the client is sending a different list of ciphers compared to when the connection is working good.
When the connection is working good I could see the below list of ciphers being sent.
It was also seen that during the issue the client hello packet was shown as SSL where as when the connection is good the client hello packet is shown as TLS1.2
During issue
When there is no issue
I am using the same NSurlconnetion class to connect to server throughout the app. I am confused why and how there could be such a discrepancy and how the same server call that works once is not working later. Does the above data suggest that during the issue the client is trying to connect via tls1.0 or lower? The server supports TLS 1.1 and TLS 1.2 only. The issue is found only in iOS 9. Any help is much appreciated.
The app will probably start with TLS 1.2 and a will offer ciphers which are new with TLS 1.2 too (the ones with GCM in the name). Then I guess there is some handshake problem, maybe cause by temporary server problems, some middlebox (firewall) in between or something else. From then on the app assumes that there are problems with TLS 1.2 and will attempt to use a downgraded connection, i.e TLS 1.0. and stay this way because "it knows" that TLS 1.2 will not work.
This kind of downgrades is often seen in browsers too but usually they remember to do the downgrade only if it was at least once successful. Could there be some SSL intercepting middlebox (firewall) involved which causes the original TLS 1.2 to fail and the downgrade to succeed? I.E. does the problem happens only after the device connected once through this middlebox and then later tries to reconnect to your site?
I'm using a device that's got GPRS media to connect to a PC running stunnel. On TCPIP connections, the number of sessions is limitless. However, when it comes to SSL connections, it could only go as far as 1062 successful sessions. I've tried it like 3 times but makes no difference. I've checked the OpenSSL codes and I couldn't seem to find any code block that limits SSL connection to 1062. On SSL's point of view, is there anything that limits the number of connections?
Yes, I'm using a postpaid phone SIM, but there isn't any problem with TCPIP. It only happens with SSL connections. We've tried connecting to other PC's as well using same OpenSSL stunnel, but only ends up to 1062 connections.
I guess I'm not the only one having this kind of problem. I found out that Sun Java System Directory Server had a limit of opened ssl connection which only reached 1020 (FD_SETSIZE=1024). It was hardcoded though so you could obviously see the cause of the problem. In my case however, I couldn't seem to find the culprit... :(
Are you connecting via a phone provider - could that be the issue?