Join us at Fortnox App Market today!

Clarification regarding the recent change in requirements to establish SSL-connections


My name is Oscar, I work here at Fortnox within our Server Operations Team.

I’m writing this blog post to clarify our recent change in the required bit-strength for establishing an SSL-handshake with our system. First some background; two days ago a new vulnerability targeting a very common method for establishing secure connections over TCP/IP was made public. More specifically, the vulnerability attacks the way clients and servers negotiates about method of encryption, bit-strength, and shared key. This vulnerability was dubbed “Logjam” by the researchers whom discovered it, it’s likely you already heard of this attack if you’re a bit tech-savvy like myself.

The implications of this attack makes it possible for a malicious user to decrypt and read traffic otherwise considered as secure. This means that an attacker targeting Fortnox or one of our API customers, could potentially extract accesstokens, client-secrets and other sensitive information sent over the API.

Luckily, the Logjam vulnerability can be mitigated by;

1. Disabling export-grade (512 bit) cipher suites
2. Enforcing strong key-exchange algorithms
3. Using a strong (2048 bit) & unique Diffie-Hellman groups.

We already had 1 & 2 covered, however we did allow the usage of sub-2048 bit Diffie-Hellman groups, which meant clients connecting to us could potentially end up establishing an SSL connection vulnerable to the attack.

In order to ensure the confidentiality and integrity of the data sent over our API, testing began on our internal servers with this fix applied. No issues were found using any form of common, updated & vendor-supported framework. However, we did discover that the standard implementation for network communication in the deprecated framework Java version 6 and older, did not work properly using higher than 1024 bit of DH-group strength.

We choose to maintain our high standard of security rather than continued support for a deprecated framework. Unfortunately, since the vulnerability was already public, we had to apply the fix to our production-servers within a very short time-span, to minimize the window of possible attacks. Knowing that this change could affect some of our API-users, we did send a mail with the information available to us at the time. In hindsight, we could have been more clear and descriptive with the information posted here and elsewhere. Please take into the consideration that staying relevant with online security and the constant new threats emerging requires us to quickly act upon these matters.

If possible, we always provide an extensive time-span for API-users to adapt to any changes in our systems.

While we strongly encourage all affected integrators to upgrade to newer frameworks with better security levels, we might be able to provide some assistance to get your current solutions up and running again temporarily in order to avoid heavy impact for our customers. Please contact our support at if this is the case. Also, I updated the original blog-post with a workaround for any java 6 users out there, found here.

For anyone interested in more information regarding this vulnerability, please see the following link;

Server-administrators looking for a how-to on implementing high-security SSL, not vulnerable to Logjam can take a look here;