Dwolla is constantly striving to improve the platform, including cryptographic protections for data. A significant layer of data protection is provided by Transport Layer Security (TLS).

TLS provides authentication for services through the use of Digital Certificates and ensures data is protected in-transit via an encrypted channel between the client and the Dwolla platform. TLS is the current version of the legacy Secure Sockets Layer (SSL) protocol. SSL is not used or supported by the Dwolla Platform, therefore we wanted to ensure TLS standards were being upheld.

A plan to promote and upgrade Dwolla clients to TLS v1.2 is underway, as earlier versions of TLS may no longer meet the minimum security requirements.

What has been done to upgrade Dwolla clients to TLS v1.2?

First, we did some initial analysis to understand the amount of traffic using weak TLS connections. Our analysis of the Dwolla platform TLS negotiations demonstrated that approximately 2% of the traffic on our platform required TLS improvements.

To further analyze the data and to find out what applications were behind the weaker connections, we wrote our own tools to help identify who was behind the connections, how often they were using them, and what they were using them for based on the Cloudflare Enterprise Log Share.

We analyzed TLS versions for both of Dwolla’s APIs, v1 and API v2 including the following destinations: API v1 (legacy):

  • www.dwolla.com

API v2 (current):

  • api.dwolla.com
  • api-uat.dwolla.com
  • api-sandbox.dwolla.com

As an added challenge, the log files are not available until 30 minutes after the request takes place, and then retained for 72 hours.

In order to fully analyze all of the data, we built a tool to analyze approximately 50 hours of logs at a time, automatically running every 48 hours. After several months, we were able to collect the data of all the partners who were still using weak TLS, and have worked closely with them to develop a plan to implement TLS v1.2.

The API call we made to understand the version of TLS in use is similar to the following:

To save the memory during execution, every API call grabs the logs for 6 seconds, analyzes the 6 seconds of log files and repeats the process. To fully analyze the 50 hours of log files, we needed to make 30,000 API calls each time to our Cloudflare edge.

The data we collected from Cloudflare logs included:

  • Request TLS Version
  • Hostname
  • Request URI
  • Client IP

What will Dwolla do to upgrade Dwolla clients to TLS v1.2?

Dwolla is collaborating with impacted partners to develop appropriate plans for converting all network connections to TLS v1.2.

Since Dwolla has already updated its platform components to meet the requirements of TLS v1.2, we wanted to be proactive in notifying our partners so they’re in a better position to improve their own integrations. Integrations may require updates to the following components to support TLS v1.2 connections:
.NET Framework >= 4.5

  • v4.6 uses TLS v1.2 automatically
  • v4.5 requires configuration to enable TLS v1.2

Java >= 7

  • Java 8 uses TLS v1.2 automatically
  • Java 7 requires configuration to enable TLS v1.2

OpenSSL (PHP, Ruby, Python) >= 1.01

  • Dynamic languages such as PHP, Ruby and Python rely on the underlying operating system’s OpenSSL version. The OpenSSL version can be obtained by running the `openssl version` command.

At our core, Dwolla recognizes that security is never done, rather, it is a iterative and continuous process to improve.

We will continue to focus on providing a platform to safely move money through continuous improvements, such as this TLS version update. Please reach out to security@dwolla.com with questions and comments.

Start building in our sandbox for free, right now. Get a feel for how our API works before going live in production.


Stay Updated