Tech Blog

Today, Google has announced a vulnerability in the design of SSL v. 3, dubbed POODLE and CVE-2014-3566. This 15-year old protocol and its successor, TLS, underpin the security of the Internet, so these kind of security issues are very important ones to pay attention to. While v. 3 is more than a decade old, it is still used for 0.3% of all Internet transactions, warns Mozilla. For this reason, the browser makers are working to disable it in upcoming releases. In the meantime, we are advising all of our customers to take action now. We urge all of our customers to do the following:

  1. Disable SSL v. 3 in any client or server that you can.
  2. If you cannot disable SSL v. 3 in your server for compatibility reasons, enable support for the TLS_FALLBACK_SCSV mechanism.
  3. If it is not possible to disable SSL v. 3 in your client, upgrade it or use a different client.

While you may be using a reverse proxy to shield access to your internal network, we still encourage you to follow the above advice for all of your servers. Start with your reverse proxies, but then fix the others too.

Below are the instructions to implement this advice in the products that our customers are typically using.

Disabling SSL v. 3 in PingFederate

To disable SSL v. 3 (and v. 2) in PingFederate, you need to do the following:

  1. For each runtime node, open <PF_INSTALL_DIR>/etc/jetty-runtime.xml.
  2. Replace all occurrences of this line:
<New class="com.pingidentity.appserver.jetty.server.connector.ssl.RuntimeSslContextFactory"></New>

with this one:

<New class="com.pingidentity.appserver.jetty.server.connector.ssl.RuntimeSslContextFactory">
    <Set name="excludeProtocols">
        <Array type="java.lang.String">

Then, restart the PingFederate nodes.

For an admin node, do the following:

  1. Open the file <PF_INSTALL_DIR>/etc/jetty-admin.xml.
  2. Replace all occurences of this line:
<New class="com.pingidentity.appserver.jetty.server.connector.ssl.AdminSslContextFactory"></New>

with this one:

<New class="com.pingidentity.appserver.jetty.server.connector.ssl.AdminSslContextFactory">
    <Set name="excludeProtocols">
        <Array type="java.lang.String">

Then, restart the admin node.

Verify that it Worked

After restarting the server(s), you should see this in the log file:

19:26:18,523 INFO  [SslContextFactory] Enabled Protocols [TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]
19:26:18,639 INFO  [AbstractConnector] Started RuntimeSslSelectChannelConnector@
19:26:20,371 INFO  [AdminSslSelectChannelConnector] Starting listener class com.pingidentity.appserver.jetty.server.connector.ssl.nio.AdminSslSelectChannelConnector 9999
19:26:20,441 INFO  [SslContextFactory] Enabled Protocols [TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

If you see the following, it did not work:

19:20:42,713 INFO [SslContextFactory] Enabled Protocols [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

CA Layer 7 SecureSpan API Proxy

SecureSpan 8 and newer is secure and does not have this problem.


ADFS v. 2.x runs on IIS. So, disabling version 3 of SSL in that product can be achieved by disabling it in IIS. Making these sort of changes in IIS requires you to edit the registry as described in the Microsoft KB (see this other KB article if your Windows server is older than 2008). If you would rather not muck with the registry, you may also look into a GUI tool that can do it for you. The best way to push these updates to all your servers is using Group Policy preferences; then you won't have to mess with the registry on each server.

NOTE: All clients since XP have support for TLS 1.0, but older ones do not. If you make this change, those clients will not be able to establish a connection.

Nginx, Apache, and Lighttpd

If you are using Nginx, Apache, or Lighttpd, checkout this helpful series of posts explaining how to harden the SSL on those products. Here's the tl;dr version from


SSLCipherSuite AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLCompression off # Requires Apache &gt;= 2.4
SSLHonorCipherOrder On
SSLUseStapling on # Requires Apache &gt;= 2.4
SSLStaplingCache "shmcb:logs/stapling-cache(150000)" # Requires &gt;= Apache 2.4
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Frame-Options DENY


ssl_ciphers 'AES256+EECDH:AES256+EDH';
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache  builtin:1000  shared:SSL:10m;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
add_header X-Frame-Options DENY;
ssl_stapling on; # Requires nginx &gt;= 1.3.7
ssl_stapling_verify on; # Requires nginx =&gt; 1.3.7
resolver <i>$DNS-IP-1 $DNS-IP-2</i> valid=300s;
resolver_timeout 5s;


ssl.honor-cipher-order = "enable"
ssl.cipher-list = "AES256+EECDH:AES256+EDH"
ssl.use-compression = "disable"
setenv.add-response-header = (
    "Strict-Transport-Security" =&gt; "max-age=63072000; includeSubDomains",
    "X-Frame-Options" =&gt; "DENY"
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"

NOTE: Replace includeSubDomains with the real list of sub-domains.

Firefox and Chrome

You should enable auto-updates in Firefox. With this set, version 34 will disable v. 3 of SSL once it's pushed out at the end of November. We urge you not to wait until then, and to instead use Mozilla's browser extension to turn it off immediately.

Make sure Chrome also has auto-updates enabled. Chrome users should receive an update soon that will disable the antiquated SSL protocol.


With the number of vulnerabilities being found in transport-level security, it is prudent when designing systems to use multiple defenses. Make sure you are using a reverse proxy in your DMZ. Update that, and then quickly disable SSL v. 3 everywhere else. If you can support TLS_FALLBACK_SCSV do. After making changes, test your server with SSL Server Test by Qualys. Keep your clients updated as well by enabling auto-updates and applying any patches provided by the vendor. Steer clear of any v. 2 or 3. clients.

If you need more help than what is provided in this blog post, shoot us a message or leave a comment below.

Cross Site Request Forgery (CSRF) attacks were discovered over 10 years ago, as an alternative to the Cross Site Scripting (XSS) attack. There are not many known attacks, mainly due to it's hidden nature and because it requires an attacker to fly blind. As the number of claims-­based systems increases, however, this attack is becoming more relevant.

read more