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.
Related
I would like to seek for your advice if you have any idea or you have already encountered this issue “SSL/TLS handshake Issue” ?
To give you a summary, we’re getting an error the error below when connecting to Coupa (ERP) through HTTP.
Remote host closed connection. Possible SSL/TLS handshake issue. Check protocols, cipher suites and certificate set up. Use -Djavax.net.debug=ssl for further debugging.
We have several HTTP requests using the same HTTP config, but there’s this only one specific request that gives the said error. Also, this HTTP request works in postman. This occurs only in one Mule environment (UAT Environment). It works fine in our sandbox environment.
We are not sure whether the SSL connection/Handshake is closed on our end or server end.
If ever its on our end, how do we identify the fix for that?
If it’s on the server end, what should be the proof that we need to provide to them to say that the issue is on their end.
The server -Coupa in this case- is closing the connection just after it was opened by the client -a Mule application- probably before the client can send the HTTP request. The server could do this by any of a number of causes and the client does not receive any error messages or codes to indicate a reason. You will need to learn the reason from the server side.
Usual reasons are because an HTTPS connection doesn't match thee required ciphers suites or protocol versions accepted by the server, or because the client IP is not whitelisted. In those situations documentation from what's acceptable to the server side is useful. There could some other reasons that are known only to the server side.
A method to troubleshoot TLS connection issues is to do a traffic capture of the TCP packets, ideally from both sides, but if you don't control the server it will be only possible from the client. Another option if you are using HTTPS is to enable Java SSL Debug log in the Mule runtime to print the HTTPS connection information. You need to understand how to troubleshoot TLS to use these tools.
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.
Recently, I tried to access one special bizarre https server with python requests library and it always reported handshake_failure. However, I can access it with browser.
After some debugging with wireshark, I found the server refused the first clientHello directly. I knew there may be some bizarre behavior for that server.
What i ask is that how to customize ssl handshake routine to identify what exactly caused the server to refuse my clientHello?
For example,
I want to add some extensions as the browser does during ssl handshake.
Thanks!
I try to submit my RSS feed:
https://www.ahcafr.com/feed/
To feedvalidator.org and I get error:
Server returned [Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
It happens with all my Cloudflare sites. Why is that?
Trying to use feedvalidator.org against my own site and doing a packet capture shows that feedvalidator.org uses a modern TLS version (TLS 1.2) but fails to use the server_name TLS extension (SNI) to indicate which specific host it wants to access. This extension is set by all modern web browsers and many sites rely on the client using this extension, as does your site behind Cloudflare.
A failure to use this extension by a client results in the handshake failure got. To fix the problem you either need to make your site accessible without SNI (some more expensive Cloudflare plans might offer this) or just ignore this feedvalidator and try to find one which uses more up-to-date behavior regarding HTTPS.
We are attempting to allow a client to access one of our QA environments. They are seeing the following error in IE:
This page can't be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://oursite.com again. if this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Pelase contact your site administrator.
I am not asking stackoverflow users to solve this problem.
I am asking the following very specific question:
Because we are seeing this error, does this prove that connectivity exists, i.e. our firewall is letting them through? I am thinking if they were blocked at the firewall they would simply get a timeout or perhaps a 403 or 500 error. since they are getting so far as to be able to see what TLS protocols are supported on the web server, I infer that they must be able to communicate with it on OSI levels 1-4. Am I correct? (I need to know whether to engage the networking team, which runs the firewalls, or to engage the application support team, which sets up the TLS configuration).
Note that SSL terminates on our IIS web server (we don't have SSL offloading).
Unfortunately we have port 80 blocked so we can only test on 443; otherwise I would suggest using http access to help isolate the problem.
... if they were blocked at the firewall they would simply get a timeout or perhaps a 403 or 500 error.
In order to send back a 403 or 500 error the firewall must have successfully done the SSL handshake with the client because the HTTP response (which includes the status code, i.e. 403, 500..) will only be sent inside the encrypted connection. There is no way to return a 403 or 500 inside the SSL handshake already.
Typical behavior with a firewall in between would be a timeout (firewalls drops packet) or more likely a connection reset or close (firewall resets or closes the connection). With a simple packet filter firewall it will usually block the TCP connection already, resulting in connection refused. But a firewall using DPI might actually let the TCP connection establish and only block after it gets actual data based on the content of this payload (i.e. application detection).
The last case might result in the error you see. But exactly the same behavior can be seen if there is a problem on the server side where the server simply closes or resets the connection. Some TLS stacks show such behavior (instead of sending back a TLS alert) when they cannot find a shared protocol version or cipher. Insofar you can neither conclude from this error message that the firewall is blocking the connection nor can you conclude that the server is causing the error.