10.8.x Clients, JSS 9.73+ API & sslv3 alert handshake failure



After being nerd sniped by @unknown_err in a channel on the MacAdmins.org Slack, I started writing some client side API scripts.

This lead to an issue with 10.8.x clients connecting to my JSS.

The below is why I saw these SSL errors & a two resolutions, one client side & another server side.

The Issue

When trying to connect 10.8.x clients to my JSS’s API, (running 9.8.2), I was receiving the following errors via cURL or urllib2:

curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

The same commands worked fine with 10.9+.

Running curl --version showed that the 10.8.x clients were running curl 7.24.0, whereas 10.9 was running 7.30.0 & 10.10+ 7.43.0.

Looking into curl’s man page on a 10.8 client shows that the options are:

-1, --tlsv1
(SSL) Forces curl to use TLS version 1 when negotiating with a remote TLS server.
-2, --sslv2
(SSL) Forces curl to use SSL version 2 when negotiating with a remote SSL server.
-3, --sslv3
(SSL) Forces curl to use SSL version 3 when negotiating with a remote SSL server.

Trying the above in various cURL commands resulted in the below for –tlsv1 & –sslv2:

curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

& the below for –sslv3:

curl: (35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

So what was going on here?



Due to the POODLE vulnerability, JAMF made a change to the JSS in JSS 9.61. This disabled  SSLv3 access & if you were running JSS 9.6 or earlier an advisory on how to disable & keep JDS’s communicating.

So, SSLv3 for this is a no-go.


I’m not sure if the JSS ever supported SSLv2, & cannot find anything advising it did. But SSLv2 connections failed too. However SSLv2 has been deprecated since 2011.

Also some more information found on this page, which is where the below was taken from:

SSLv2 has been deprecated and is no longer recommended. Note that neither SSLv2 nor SSLv3 meet the U.S. FIPS 140-2 standard, which governs cryptographic modules for use in federal information systems. Only the newer TLS (Transport Layer Security) protocol meets FIPS 140-2 requirements. In addition, the presence of an SSLv2-only service on a host is deemed a failure by the PCI (Payment Card Industry) Data Security Standard.



Not long after the POODLE vulnerability, another vulnerability called LogJam was announced.

JAMF again made some changes to the JSS.

If your JSS started with 9.73 or newer then the server.xml will have the changes, however if your JSS predates 9.73 you should have updated the ciphers manually, as per this article.



Ciphers are used as part of the data encryption process, if you receive some encrypted data & know the cipher.. you can “decipher” it, (as shown above).

Both vulnerabilities concerned the ciphers &/or the encryption used when clients would on the JSS.

With the cipher changes for the LogJam vulnerability, a number of weak ciphers are removed.

cURL has a ciphers option, & as per the man page:

--ciphers <list of ciphers>
(SSL) Specifies which ciphers to use in the connection. The list of ciphers must specify valid ciphers.
Read up on SSL cipher list details on this URL: https://www.openssl.org/docs/manmaster/man1/ciphers.html

NSS ciphers are done differently than OpenSSL and GnuTLS. The full list of NSS ciphers is in the NSSCipherSuite entry at this URL: http://directory.fedora.redhat.com/docs/mod_nss.html#Directives

If this option is used several times, the last one will override the others.

These ciphers are not named the same as those in the JAMF article for Tomcat as they are using OpenSSL.

However, the first link in the quoted text from the man page takes you to a page that gives the SSL or TLS cipher suites names from the relevant specification and their OpenSSL equivalents.

You can get a list of the client side OpenSSL ciphers via the below command

openssl ciphers

If you check the the client side cipher list against the top list in the JAMF article for Tomcat list & then translate the  OpenSSL equivalents, you’ll notice that the standard list are all “Elliptic curve cipher suites” & none are within the 10.8 clients cipher list.


As mentioned at the beginning of this post, there are 2 solutions, 1 client side, 1 server side.

Server Side

Within the JAMF article for Tomcat, there is an additional cipher:

In addition, if you are running Java 1.6 or a JDS instance in your environment, you must also include the following cipher:

NOTE: The JSS now requires Java 7, so not sure if that information is still valid for JDS

That cipher, when translated to OpenSSL is “AES-128SHA”, which is within a 10.8.x clients cipher list.

So you could add this to the JSS’s server.xml & then 10.8.x clients will be able to perform API scripts using cURL or urllib2 via TLS1.0.

However, TLS1.0 is considered insecure as TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0, thus weakening security.

So, if you’re implementing this server side “fix”. I’d advise only to amend the server.xml for those JSS you have that are internally accessible only (so if you have a clustered JSS, only amend the internal JSS & not the WAN accessible JSS’s).

You can then amend your API scripts to only make calls if the JSS resolves to an internal IP.


As the above mentions, you may already have this cipher in your server.xml if using JDS. I’m not a JAMFCloud customer but it may be something they add to the server.xml for this purpose.

Client Side

Shea Craigs python-jss which “aims to offer simple, elegant, pythonic access to the Jamf Casper JSS API” already has done all the leg work with it’s TLS Adaptor & allows a 10.8.x client to contact the JSS without adding the weaker TLS1.0 cipher.

Installing python-jss

The python-jss wiki has install instructions, the below is what I packaged in Composer:

Screenshot 2015-12-31 11.44.04

10.9+ Clients

With 10.9+ Apple made some changes in the version of cURL included within OS X, the below is taken from this page.

In Mavericks, Apple changed from curl 7.24.0 to 7.30.0, and in the process, they switched the TLS/SSL engine used by their curl, from OpenSSL to their own Secure Transport engine. Apple's OpenSSL is still at version 0.9.8 and I doubt they will ever upgrade it, so this change improves curl's security. This is because the new engine supports TLS 1.1 and 1.2, and many new-ish cipher suites not supported by that old version of OpenSSL.

2 thoughts on “10.8.x Clients, JSS 9.73+ API & sslv3 alert handshake failure

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.