I have installed an SSL certificate I generated from Let's Encrypt using Nginx Proxy Manager. The cert works great on everything except Safari! I get a "cannot parse response" in Safari.
My setup is as following:
I have ports 80/443 open to my NPM instance, where I then proxy over to the correct machine running the web server. I have HTTPS forced for eataupa.com and also HTTPS forced between NPM and my web server. I am not sure if Im suppose to run this inside connection between NPM HTTPs or HTTP.
Either way eataupa.com works fine unless its safari and im tearing my hair out trying to fix it!
Please help, thanks so much!
I see some error produced here I just dont know how to interpret and fix it.
https://www.ssllabs.com/ssltest/analyze.html?d=eataupa.com
This is an answer from a TLS stand point, I cannot tell you which config to change since I am not familiar with your applications.
The Safari versions that could not connect to your website probably do not support the security requirements such as the protocol version and many other things such as cipher suites.
This most likely occurs because of the ciphers, as Safari 8 seems to support TLS 1.2 but it still fails to perform the TLS handshake.
Here are the list of Safari 8 ciphers: https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=8&platform=iOS%208.4
And you would sometimes need the OpenSSL interpretation of them: https://testssl.sh/openssl-iana.mapping.html
You need to configure your server to use one of the cipher suites that those safari versions support.
Related
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 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.
Quite often I have to access old sites using Sslv3 or other old, deprecated, SSL protocols.
Most of them are appliance that are not easy to update (storage controllers, tape controllers...).
Unluckily latest browsers on Linux (chrome and firefox) refuse to connect to this kind of sites, even with advanced options (SSLv3 support has been totally removed from Firefox).
What I need is a tool that can do such a thing:
tool --listen HTTPS:9050 --connect HTTPS://oldsite:443/
Obviously the "connect" part should accept any SSL version and the "listen" part should expose commonly accepted SSL versions.
I saw mitmtool and polipo but I could not configure them properly.
The key here is that the target site is not a proxy, but a simple https site.
Is it possible?
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 working with Delphi and using Indy components for SSL connection. I had Fiddler2 running and was able to see SSL traffic, but had to upgrade Indy to newer version because it had some errors. For compatibility between Indy and OpenSSL I also upgraded to OpenSSL1.0.2a. After this upgrade it seems that it has switched to SSL3.3 a newer protocol than what was used before. I installed Fiddler4.5, .NET framework 4.5 and enabled TLS1.2 as descriped on http://blogs.telerik.com/fiddler/posts/13-02-11/fiddler-and-modern-tls-versions. I also reimported Fiddler's certificate to my trusted root certificates, however i can still not decrypt the SSL traffic.
Following is written in Fiddler:
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
Fiddler's HTTPS Decryption feature is enabled, but this specific tunnel was configured not to be decrypted. Session Flag 'X-No-Decrypt' was set to: 'PeekYieldedUnknownProtocol'.
A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
I tried to search Indy and OpenSSL source for the string "X-No-Decrypt", but it does not seem to be included anywhere. Accoring to fiddlers documentation it seems to be a string that you can include if you dont want fiddler to decrypt this particular session, but i have no idea where this string is included from.
Any suggestions?
Thanks /Rune
The text PeekYieldedUnknownProtocol indicates that when Fiddler looked at the first bytes sent by the client within the CONNECT tunnel, those bytes were not those of a HTTPS handshake. To avoid breaking whatever type of traffic is flowing through the tunnel, Fiddler simply passes the bytes back and forth without interpreting them.
To debug this further, your best bet would be to contact me using Help > Send Feedback in Fiddler. If you can send me a SAZ File (File > Save Session Archive) containing the traffic, I can investigate this problem further.
If you can't share a SAZ file, please at least right-click on the CONNECT in the Web Sessions list and choose Properties. Update your question with the value of the x-CONNECT-Peek flag.