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">
            <Item>SSLv2Hello</Item>
            <Item>SSLv3</Item>
        </Array>
    </Set>
</New>

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">
            <Item>SSLv2Hello</Item>
            <Item>SSLv3</Item>
        </Array>
    </Set>
</New>

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@0.0.0.0:9031
...
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 and IIS

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 Cipherli.st:

Apache

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

nginx

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;

Lighttpd

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.

Conclusion

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

DFS ships with an LDAP attribute store that queries directories for data that the federation server should assert as claims. As it says in the documentation, Microsoft's attribute store only works with LDAP servers that support Integrated Windows Authentication (IWA). If the LDAP directory does not support this method of authentication, the data in it cannot be accessed with the stock attribute store. Due to this limitation, organizations needing to provide data to their federation partners which is housed in incompatible directories have been faced with undesirable choices. It is for this reason, that we have created the Twobo LDAP Attribute Store for ADFS. As we'll explain in this and subsequent blog posts, our new attribute store includes more functionality than Microsoft's without the limitations.

read more

Yesterday we, announced that we are continuing to lead the advancement and adoption of APIs in Europe by sponsoring and co-organizing the only all-API-related series of events in Northern Europe. Over the next few months, we will be touring Europe to explain API security, and wanted to let you know in hopes that you can join us.

read more