I have a website using tls1.2,1.1 and 1.0(ssllabs) . I am using websense proxy to access it. Have enabled tls1.1 and tls1.2 on the WCG. I am still getting Peer disconnected error. The website worked once and is giving the error randomly. I have websense 8 and the URL in question is https://rem2.piiapps.com/site/login. It works fine with websense 7. I dont have a ssl bypass option due to security restrictions. Sometimes the browser indicates that the certificate is broken and sometimes it is healthy.
I did some analysis and found that this URL was using a real time communication protocol which is not supported by deafult in websense. It has to be tunneled in the incident list.
Related
When attempting to access my Apache Tomcat v9 site via HTTPS in Firefox, I am met with:
An error occurred during a connection to localhost:8443. SSL received an alert record with an unknown alert description.
Error code: SSL_ERROR_RX_UNKNOWN_ALERT
The Tomcat server has a certificate that is trusted by my Firefox. The Tomcat server is configured to require client certificates, of which I have one installed, but Firefox is not prompting me to select one.
There are no errors (or messages of any kind) in any logs in Tomcat. The strange thing is that this used to work last week but has stopped. I tried issuing the server a new certificate but that did not resolve this.
It turns out this is the cryptic error you get in Firefox when it cannot find a client certificate to send the server. In my case the client certificate I had installed expired a couple days ago (which is why it used to work) and so Firefox was not sending it to the server and was thus getting that response.
Generating a new client certificate and loading it into Firefox resolved the issue.
I was able reproduce the error later on by selecting "Cancel" when Firefox asks me what client certificate to use.
I am not sure if it's Tomcat giving the weird SSL response of if it's Firefox not able to understand what's going on but I hope this answer helps others facing this issue in the future.
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 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?
Posting this for anybody else running across the same problem.
I was working on a browser client that used stanza.io to connect to an XMPP server (Prosody, in my case). I was using a wss:// connection by default. At some point during development, my client failed to connect at all - it would immediately disconnect silently, without providing any kind of useful error information.
There were no error logs, no error codes, no confirmation dialogs or bars, no indications of what might be wrong.
After hours of debugging, I eventually found the problem; as I was messing around with the configuration of my XMPP server, I had re-generated the SSL certificates for the XMPPd. Since I was using self-signed certificates, this would cause an SSL error. Because I had visited that same URI over HTTPS before, I'd already manually approved the old self-signed certificate - but obviously that approval was no longer valid after regenerating the SSL certificate.
The key to the problem is this: If your SSL certificate causes a warning of any sort, wss:// WebSocket connections will immediately fail, and there is no canonical way to detect this.
As stated above, there appears to be no standardized way to even detect that this problem is occurring, let alone solve it. The best solution to this problem that I have been able to find, is as follows:
If the WebSocket disconnects prior to having received a login confirmation (XMPP-specific), try to make a plaintext ws:// (without SSL) connection to the non-SSL port.
If the plaintext connection succeeds, this means that the server is up - thus the problem is with the SSL certificate. (If the plaintext connection also fails, the server is simply unavailable.)
Display an error to the user, indicating that there was an SSL problem, and that they should check the certificate, with instructions on how to manually approve it.
Provide a target="_blank" link to the wss:// URL, but replacing the protocol with https://. This might be Prosody-specific, but by visiting that URL you will see the SSL warning page. Prosody will display a text that starts with "It works!" after approving the certificate - if the server-side is a custom application, you should display a message saying that "the problem has been solved, you can close this tab now".
In the background, in the main application, keep attempting to reconnect over wss:// every few seconds. Once a connection succeeds, this means the user has approved the certificate. Hide/remove the error and continue the normal connection/login process.
It's far from a smooth process, UX-wise, but it's the smoothest approach I've found. It is not possible to iframe the error page (this was one of my first ideas) - Chrome will refuse to load it at all, Firefox will hide the "Add exception" button, and I'd imagine other browsers exhibit similar behaviour.
Remember that modern browsers do not like self-signed certificates.
Therefore, if your secure WebSocket connection dies before ending the handshake, it could mean that the certificate has not been accepted.
In order to solve the issue, you can:
buy a certificate signed by a Central Authority
simply open in a new
Tab or Window the link of you WebSocket's URI and tell the browser to
trust the connection.
Come back to your WebSocket and it should work.
This is what I did and it worked:
1 - Generate self signed certificate
2 - Create an https websockets server this way
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.