Is Ice affected by the FREAK security vulnerability?

The FREAK attack refers to a vulnerability in SSL/TLS in which a remote attacker can intercept communication between a client and server and force them to downgrade to a weakened "export"-grade cipher suite.

On this page:

Is Ice affected?

This is not a vulnerability in Ice but rather in the SSL/TLS implementations that Ice uses for secure communication on all supported operating systems. The exact dependencies vary based on the Ice version and the language mapping(s) that you use:

  • Ice 3.5.1 and earlier
    • Ice for C++ uses OpenSSL on all supported operating systems.
    • Ice for Python, Ice for Ruby, and Ice for PHP are all based on Ice for C++ and therefore use OpenSSL on all supported operating systems.
    • The IceGrid, IceStorm, Glacier2 and IcePatch2 services are implemented in C++ and as a result they also rely on OpenSSL.
    • Ice for Java uses its own SSL/TLS implementation.
    • Ice for C#/.NET uses the platform's native SSL/TLS implementation.
  • Ice 3.6
    • Ice for C++ performs SSL/TLS communication using OpenSSL on Linux, SecureTransport on macOS, and SChannel on Windows.
    • Ice for Python, Ice for Ruby, and Ice for PHP are all based on Ice for C++ and therefore have the same dependencies as Ice for C++.
    • Ice for Java uses its own SSL/TLS implementation.
    • Ice for C#/.NET uses the platform's native SSL/TLS implementation.
  • Ice 3.7
    • Ice for C++ performs SSL/TLS communication using OpenSSL on Linux, SecureTransport on macOS, and SChannel on Windows. Users can optionally build a Windows version of IceSSL that uses OpenSSL.
    • Ice for Python, Ice for Ruby, and Ice for PHP are all based on Ice for C++ and therefore have the same dependencies as Ice for C++.
    • Ice for Java uses its own SSL/TLS implementation.
    • Ice for C#/.NET uses the platform's native SSL/TLS implementation.

Is my Ice application affected?

Your Ice application is only affected if you use SSL/TLS for secure communication.

Will operating system updates correct the problem?

It depends on the operating system, Ice version, and language mapping(s) that you use:

  • Linux
    Ice for C++ links dynamically with the native OpenSSL libraries on Linux. Updating your OpenSSL packages will correct the problem.
  • macOS
    Ice for C++ up to and including version 3.5.1 links dynamically with the native OpenSSL libraries on macOS, and Ice for C++ 3.6 beta uses the native macOS SecureTransport facility. Operating system updates will correct the problem.
  • Windows (Ice 3.5.1 and earlier)
    All Ice binary distributions for Windows include OpenSSL libraries that Ice for C++ uses for SSL/TLS communication. You will need to take additional action to correct the problem.
  • Windows (Ice 3.6)
    Ice for C++ 3.6 uses Windows SChannel for SSL/TLS communications, therefore operating system updates will correct the problem. The binary distributions for Windows no longer include any OpenSSL library.
  • Windows (Ice 3.7)
    Ice for C++ 3.7 uses Windows SChannel for SSL/TLS communications by default, therefore operating system updates will correct the problem. The binary distributions for Windows no longer include any OpenSSL library. A user who built a version of IceSSL that uses OpenSSL should review their build environment to ensure an unaffected version of OpenSSL was used.
  • Java
    Updating your JVM will be necessary to correct the problem.
  • C#/.NET
    Windows updates will be necessary to correct the problem.
  • Python/Ruby/PHP
    The corrective actions you take for Ice for C++ will also address the problem for these languages.
  • JavaScript
    Node.js users will need to upgrade their interpreter. Browser users are dependent on the operating system or browser vendor. 

You should also modify your IceSSL configuration to prevent the use of export ciphersuites.

Which Ice binary distributions are affected?

All Ice binary distributions for Windows released prior to March 9, 2015 contain OpenSSL binaries affected by this vulnerability, including the Windows third-party binary and source distributions. Users of these distributions should update their installations.

On all other supported platforms, the Ice distributions up to and including version 3.5.1 depend on the OpenSSL packages provided by the operating system vendor and therefore no Ice updates are necessary.

On March 9, 2015 we released Ice 3.5.1-5 packages for Windows to address the FREAK vulnerability.

As of Ice 3.6, Ice uses OpenSSL only on Linux. OpenSSL libraries are no longer included in any Ice binary distribution.

What should I do if I am using a Windows binary distribution of Ice 3.5.1 provided by ZeroC?

You should:

  • install the latest Ice 3.5.1 binary distribution for Windows, which contains updated OpenSSL DLLs
  • replace the OpenSSL DLLs (libeay32.dll and ssleay32.dll) included with your Ice applications with version 1.0.1l


Please note that the Ice binary distribution includes multiple builds of these OpenSSL DLLs (for different C++ compilers, and for 32 and 64 bit); we recommend that you replace all OpenSSL DLLs included with your Ice-based applications. You can replace these DLLs without recompiling or relinking anything, in particular neither Ice nor your Ice applications need to be rebuilt.

What should I do if I built Ice myself?

You should upgrade to OpenSSL 1.0.1l (or later).

What else can I do to mitigate this problem?

You should also modify your IceSSL configuration settings to prevent the use of weak, export-grade ciphersuites. This is only possible for the Java, C++, and C++-based language mappings (Python, Ruby, and PHP).

The IceSSL.Ciphers property allows you to specify which ciphersuites the application can use. In general, you should be as selective as possible to ensure the highest level of security.

It's important to keep in mind that the ciphersuites you enable must be compatible with the certificates you use. For example, limiting IceSSL to DSA-based ciphersuites won't work if you're using RSA certificates.

To get started, you should familiarize yourself with the symbols that represent the ciphersuites. The symbol names have slightly different formats in Java and C++. To see a complete list of the supported ciphersuites, run a server (either your server, or one of the sample servers included with Ice) while defining IceSSL.Trace.Security=1 but without defining the IceSSL.Ciphers property. When a client establishes a secure connection, the server logs all of the enabled ciphersuites as well as the ciphersuite that was negotiated for the connection. The list of all enabled ciphersuites typically includes many of the weakened, export-grade suites that should be disabled in a production application.

Now that you have the list of ciphersuites, you can disable all but the few that you actually want to allow. As a starting point, you can use a configuration such as:

  • IceSSL.Ciphers=DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK (OpenSSL)
    This setting enables just one ciphersuite and disables several categories of weak ciphersuites. Mozilla provides a configuration generator that may be useful for OpenSSL users; although it's intended for configuring web servers, the generated ciphersuite setting can be copied directly into your Ice configuration.
  • IceSSL.Ciphers=NONE (RSA.*AES_128) (Java)
    The use of NONE as the leading selector disables everything, and the regular expression that follows enables only those ciphersuites whose symbols match the expression.

Again, you'll need to adjust these settings based on your own certificate requirements. As you experiment with different configurations, you can review the IceSSL log output to verify that they're correct.