Has anyone had success disabling TLSv1.0 in Tomcat?
The new PCI DSS 3.1 requirements require that not only SSLv2 and SSLv3 be disabled, but TLSv1.0 as well (leaving only TLSv1.1 and TLSv1.2). This is problematic for the JSS, because disabling TLSv1.0 appears to break connectivity between the jamf binary and the JSS:
Checking availability of https://<JSS>:8443/... 2015-06-08 20:34:36.310 jamf[4097:6966036] CFNetwork SSLHandshake failed (-9824) 2015-06-08 20:34:36.344 jamf[4097:6966036] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
Before I put in a feature request and/or open a support case, has anyone found a combination of non-TLSv1.0 protocols and ciphers that the jamf binary is happy with?
I think you edit Tomcat's server.xml and remove older TLS protocols from your 8443 connector by editing the sslEnabledProtocols key. That should prevent the server from allowing the client to negotiate SSL/TLS with older protocols. Be sure to make a backup of the file before modifying the config and be sure to restart Tomcat afterwards.
<Connector URIEncoding="UTF-8" clientAuth="false" sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" .... port="8443" </connector>
I understand how to remove older SSL variants; that isn't the issue (especially because they've been removed by default for a while now). The issue is that "TLSv1" is not permitted on new PCI DSS-compliant deployments. To be compliant, that key needs to look like this:
However, doing so breaks communication with the jamf binary. The JSS web interface is fine, which indicates to me that it's likely the binary itself that's having an issue.
If no one else has found a solution, or if no one else reading this has had to set up a JSS in a PCI environment, then I'll just open a case. I figured it was worth a shot here first.
I finally got around to testing and sure enough, once I remove TLSv1 the jamf binary on my Mac can no longer communicate.
However, the website still loaded and Chrome shows it's using TLS 1.2.
2015-07-09 18:10:40.985 jamf[39305:3334743] CFNetwork SSLHandshake failed (-9824)
2015-07-09 18:10:41.207 jamf[39305:3334743] CFNetwork SSLHandshake failed (-9824)
2015-07-09 18:10:41.440 jamf[39305:3334743] CFNetwork SSLHandshake failed (-9824)
2015-07-09 18:10:41.508 jamf[39305:3334743] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9824)
Waiting 5 seconds to try again...
FWIW, Apple has a KB on this error in regard to servers (DPs): https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/
"All connections using the NSURLConnection, CFURL, or NSURLSession APIs use App Transport Security default behavior in apps built for iOS 9.0 or later, and OS X v10.11 or later. Connections that do not follow the requirements will fail. For more information on various the connection methods, see NSURLConnection Class Reference, CFURL Reference, or NSURLSession Class Reference.
These are the App Transport Security requirements:
The server must support at least Transport Layer Security (TLS) protocol version 1.2.
Connection ciphers are limited to those that provide forward secrecy (see the list of ciphers below.)
Certificates must be signed using a SHA256 or greater signature hash algorithm, with either a 2048-bit or greater RSA key or a 256-bit or greater Elliptic-Curve (ECC) key.
Invalid certificates result in a hard failure and no connection."
In OS X v10.11 and later /usr/bin/nscurl can help diagnose connection issues that are due to App Transport Security.
Actually we have the same issue here on a Red Hat based JSS ...
2015-10-08 15:27:52.074 jamf[2146:14829] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9813) The network connection was interrupted while downloading the package from https://jss.our.domain/JSSShare/Packages/TextWrangler50Build3766v2.pkg.zip. Attempting to reconnect...
Any news about it?
We are still using 9.73, should we upgrade to 9.80 and 9.81 to fix this issue?
Or is D-009291 still open?
PS: All clients are still on 10.10.5 and it worked until Tuesday this week without any problem … Also "jamf policy verbose" shows no more details. A workaround right now is to force the distribution point to AFP/SMB (we use SMB) but of course we would prefer to go on using https SharePoints for the distribution.
Firefox, Safari and Chrome can access the https-Share with capserinstall and it's using TLS 1.0, so the jamf binary should work fine normally but it doesn't.
Is there a solution to the windows issue? We run JSS on windows, and turned TLS 1.0 off. Now the jamf binary on mac clients says:
The SSL Certificate for https://jss.example.com:8443/ must be trusted for the jamf binary to connect to it. Error enrolling computer: unable to establish trust with the JSS – Connection failure: ‘The Internet connection appears to be offline.’