We have a web service running on JBOSS EAP7 which is behind IIS 8.5. The webservice works fine on the Internet Explorer using both http://webservice and https://webservice. We have another application running on IBM WAS 7 which consumes this web service. The application has no issues when it uses http://webservice. However the SSL handshake fails when application on WAS 7 uses https://webservice. Below is the error we are seeing in application logs.
Below is a ClientHello message from WAS
We do not see ServerHello message in the logs. Below are the Ciphers on IIS 8.5 Earlier we thought that this was an issue with unmatched Ciphers but as per IBM Support, TLS_RSA_WITH_AES_128_CBC_SHA is equivalent to what is being sent in ClientHello SSL_RSA_WITH_AES_128_CBC_SHA. Also, unfortunately we do not see any errors in IIS logs or in the Event Viewer of the Server. We used MessageAnalyzer as well to capture network traffic on Server but didn't help much. Is there any way to capture SSL Handshake logs on the IIS/Server? Any other help or suggestions you could provide will be much appreciated.
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.
I'm trying to access an SSL URL from a Windows browser to another machine running Tomcat and I am seeing error 36887 from Schannel in the System event log on the Windows machine with this description:
The TLS protocol defined fatal alert code is 70
According to MS documentation:
I've turned up Schannel logging (max=7) on the Windows machine and I can see that an SSL handshake was negotiated correctly, this from the event log:
An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.
Protocol: TLS 1.2
CipherSuite: 0xC028
Exchange strength: 256
This seems to contradict the code 70 error.
Cipher suite 0xC028 is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. I've checked on the Tomcat machine and can see that this is available, and TLS1.2 is also enabled on both machines so the successful handshake makes sense.
The process ID associated with the code 70 error belonged to lsass.exe - my Windows knowledge is quite limited so I have no idea what that does.
I can find nothing in the catalina.out log on the Tomcat machine, the code 70 seems to be happening before the request is actuall sent. I am certain that the certs are all configured correctly as I can access the URL successfully from other machines.
How can I progress from here?
The issue turned out to be that one of our client apps was using .NET 4.5.2 and defaulting to TLS1.1, which had been disabled at the server end by some patching. Ultimately a .NET update to 4.7.2 fixed the issue.
It means communication with the server was attempted using a recognized but unsupported TLS version. If your server is set to accept only communications using TLS 1.2 or newer, for example, then anything that tries to communicate via TLS 1.1 or lower will throw this error.
Two computers have to agree on a method of communication before they can actually do the communication. That is why this error message can occur and then the computers appear to communicate just fine... the first method was tried and rejected, and then a newer one was tried and succeeded, that's all.
There is a windows 10 server in which tls1.0,ssl3 are disabled by IISCrypto for refusing weak ssl protocol from client requests. tls1.1 and tls1.2 are disabled on the client system and just ssl3 is enabled on it and will be expected any requests from client to server be refused.I'm using IIS10 and an asp mvc project website that is loaded on .I've searched and figure out there is no way to reject these request in asp mvc.The only way was using something like this System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
but doesn't work at all.By using wireshark and just look at Client Hello I realized the connection between server and client is stablished by tls1.2. I think my question is clear and no need to give code anymore.
Is there any help ?
Our company currently have an application created in VB6 running on a Windows 7 desktop computer. This application needs to connect to a web service using HTTPS.
For some reason this application can not connect to the target server. The target server is behind an Apache web server that also acts as a load balancer.
I traced the connection via wire shark and it seems that after the Client Hello the server responded with [FIN, ACK] than a Server Hello. Can anyone tell me what the problem is.
Client Hello & Server [FIN, ACK]
[![Client HEllo][1]][1]
[1]: https://i.stack.imgur.com/btXyX.jpg
[![enter image description here][2]][2]
[2]: https://i.stack.imgur.com/O5WDq.jpg
However, we can connect successfully in the following scenarios
If we use the same application under Windows 10. Please note when using Windows 10 our SSL version is TLS1.2.
If the application connect directly to the Application Server instead of the Apache Web Server. In this case our SSL protocol is still TLS1.0
I am guessing that we need to configure the Web Server to allow our application to connect. Our Administrator told us they already activated the TLS1.0 protocols so I am not entirely sure what is wrong now.
Why the server closed the connection, or any ideas what part of the logs or Web server configuration should I check to find out?
Please note that we are aware that we are using TLS1 protocol for this connection but this application is only for internal use and its replacement is already in development. However, there is a business need to make this work for the current environment.
In the case the Server doesn't support any of the Cipher-Suites suggested in the "Client Hello" packet, it may just close the connection.
You can check what is the returned Cipher-Suite in the case it works (when you use Windows10) and then investigate how to enable this Cipher-Suite in Windows7
We are facing a problem and I am sure this is the right place. We have a load balancer (cisco's) and for various reasons the SSL configuration on the load balancer (the server) side is set to use "SSLv3" protocol version. Now after setting the same, when I access the load balancer in CHROME browser, I am able to access the pages but I do see the below message when I click on their security icon.
"connection had to be retried using ssl 3.0" - I looked at the packet capture using wireshark and I see that browser tries TLSv1 and receives a "fatal alert" from the server saying "protocol_version" and then immediately browser tries SSLv3 version and finishes the handshake. So browser is able to negotiate this as a client.
However when I set up a stand alone java (tried using 1.6 as well as 1.7) client from eclipse and try connecting to the server I am getting the below exception.
: Received fatal alert: protocol_version javax.net.ssl.SSLException: Received fatal alert: protocol_version
As per various documentations, I saw two options I have
to set https.protocol system property to SSLv3. [this works for us, but the problem is it is affects the outbound SSL calls globally. I have another outbound SSL call to another server which does not work with SSLv3]
setEnabledprotocols() - this works as well but sometimes, we dont have access to the socket directly (sometime we generates stubs using third party and the stub takes care of the low level connection stuff, so no access to that socket).
But my actual question is, If by default TLSv1/SSLv3 and SSLv2Hello(just the format I believe) are enabled in java, why is JSSE implementation not able to negotiate like how chrome browser is able to negotiate. Is this expected? If browser is doing it, I believe it should be part of some SSL RFC and if that is the case, same functionality of this "negotiation" should be provided by java itself right?
I did go through this http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java and was not able to find any part for this negotiation during handshake.
Is there a possibility of issue from the server side (load balancer) that i. I see that server sends fatal alert but that being cisco I believe the ssl implementation should be perfect and that is expected. Am I wrong?
Issue happens both in java 1.6 and 1.7. Do let me know if more information would be required to answer, will be happy to help.