The popularity of TLS has encouraged attackers to find vulnerabilities and develop exploits. The variety of known attacks is the result of (i) maintaining backward compatibility and (ii) evolving use case scenarios in which TLS is deployed.

One cannot “just deploy” TLS. Setting up a TLS server requires some amount of configuration, including

• Choosing a set of cipher(s)
• Choosing the versions of TLS to be offered
• Setting a certificate issued by a trustworthy CA
• Coping with implementation issues (e.g. vulnerable libraries)

Several tools have been developed to help administrators deploy secure TLS instances. While such tools are quite effective in automatically finding vulnerabilities and issuing warnings about possible attacks, the burden of finding adequate mitigation measures is left to administrators who must first collect information about the identified problem and related fixes. Typically, such information is distributed in several sources ranging from scientific papers to blog posts. Even disregarding the effort to collect enough material to enact a mitigation, administrators should have enough skills to understand the often-subtle details and turn the information into a concrete strategy to fix the problem. Additionally, each tool has varying degrees of coverage and does not specify mitigations for the issues identified. In other words, there is a problem in making the tools’ reports actionable.

TLSAssistant is an open source tool that combines state-of-the-art TLS analyzers with a report system that shows the full set of viable attacks and suggests appropriate mitigations. Its goal is to assist an administrator in securing TLS configurations by

• Detecting TLS and HTTPS misconfigurations;
• Providing :
  • A brief attack description;
  • A mitigation description;
  • Mitigation code snippets (for Apache and nginx web server).

At a high level, the goal of the TLSAssistant service in FINSEC is to provide server administrators with vulnerability reports and options for courses of action that they may choose to take to mitigate those vulnerabilities.
The currently planned functionality is as follows.

• The definition of vulnerabilities and courses of action will be uploaded to the data layer
• The sightings of vulnerabilities will be stored in the data layer and their generation will be published through the real-time message broker so that services consuming the sightings will be able to retrieve them.
• The Risk Assessment Engine may consume sightings to trigger a re-evaluation of the risk level in relevant scenarios.
• The Dashboard may consume sightings and retrieve the corresponding mitigating courses of action to display them.

The TLS Assistant is largely based on bash scripts. The original architecture of the tool is shown in the figure below. It leverages selected open-source TLS vulnerability scanners to generate reports; vulnerabilities are collected and included in a final report, together with attack descriptions, external references, suggested mitigations –code snippets and/or instructions, and highlighted attack trees.

The vulnerabilities detected and mitigation suggestions for sysadmins are provided as FINSTIX Vulnerability and Course of Action objects. Each scan generates Sighting objects for these vulnerabilities, added to the data layer.