Entries in SSL/TLS (2)


Insights from the Crypto Trenches

At GDS we are in the particularly advantageous position of working with a wide variety of products, spending time understanding their security and often uncovering their flaws. Given this experience, we decided to share some of our thoughts on the cryptographic aspects of building modern software.

It should come as no surprise to anyone in the field of security engineering that working with crypto is a perilous business, and even highly experienced engineers can get it wrong sometimes. Sophisticated attacks come along once in awhile, partially breaking OpenSSL and other well-respected security libraries. However, for those who have spent enough time in the trenches of cryptographic security, it is clear that the vast majority of crypto issues don’t stem from the underlying vulnerability of a well-respected library. Instead, they by far stem from incorrect design and implementation-specific issues of well-built crypto components. In this blog post we try to expand on why design and implementation goes wrong and give advice on making things go better.

Modern, agile software development processes generally merge some of the stages of requirements analysis, architecture, design, implementation and testing. However, in the case of cryptography it is dangerous to conflate these distinct stages. Cryptography must be considered at all these stages, and because of its difficulty and importance for securing important data and decisions, it must be given higher priority than most other elements. As such, it is typical for a software house to discuss crypto-related decisions for longer, and entrust cryptographic aspects of the system to be implemented by one of the most senior engineers. Both of these help, as do checklists such as those implemented by [1] or guidance such as that provided on Martin Fowler’s blog [2].

However, no checklists or easy guides exist for hand-rolled cryptographic constructs. When it comes to designing systems that use cryptography to achieve an end goal, one of the fundamental mistakes made by designers is to reinvent the wheel in the crypto design space. This is not necessarily because anybody needs the burden of designing something new. Instead it’s because it is hard to know what class of problems can be solved with a certain cryptographic construct. It also doesn’t help that cryptographic terminology can be very confusing. For example, Pseudo Random Functions (PRFs) are always implemented as a deterministic function that neither uses, nor exhibits, any random behaviour [3]. For this reason, GDS recommends bringing in experts, either internal or external, to early crypto design discussions. An expert can not only help mitigate the risk of misusing cryptography, but may also offer ways of reusing existing crypto constructs, reducing the overall cost and time budget of the project.

When it comes to writing code, those who are entrusted to implement the agreed-upon design often find themselves in a tight spot. They have to battle with two separate issues: what crypto library to use for a particular crypto construct and in what way should it be used.

At GDS, we advise our clients to use very few, battle-hardened crypto libraries with strongly restricted configuration sets to meet a large set of generic requirements. Unfortunately, cryptographic agility [4], as implemented by OpenSSL, is often at odds with restricted configurations and hardening. Although OpenSSL is the default go-to crypto library of choice, politics such as government-mandated cryptographic primitives (CAMELLIA from Japan, ARIA from South Korea, GOST from Russia, etc) and misguided optimizations (such as 27,000 lines of Perl generating assembly in OpenSSL) also makes it the elephant in the room that no one really wants to question. However, there is very little else to opt for. The obvious other choice is libnacl [5], written by a team led by Dan Bernstein that tries to significantly limit the number of implemented crypto constructs and hence configurations, reducing the cognitive load and simplifying the job of the person charged with implementation. Although libnacl is a great library, its restricted functionality is often an issue — but it excels at what it does implement. This is true for other specialized libraries as well, such as scrypt [6] that can be used for storing salted and hashed passwords or to derive keys from passwords. The library libsodium [7] builds on libnacl, attempting to address some of its portability and usability concerns. However, it is relatively new and mostly written by a single developer without the crypto pedigree of the nacl team. We therefore caution against using it in production environments. It’s not easy when it comes to working in code with cryptography, which leads us to our next topic.

The second biggest headache that developers face at the implementation stage is the actual code around the use of the chosen crypto library and its constructs. It is not unheard of to see developers surprised to see their sensitive memory-cleaning code being optimised away by smart compilers [8]. As such, GDS recommends using high quality standards around crypto code. In all instances, the actual standards enforced are a function of language, developer familiarity, and a number of business factors such as coding language and culture, however, [9] and [10] are good starting points for C/C++. For example, when coding in C11, using secure version of functions that typically end with “_s” are good practice. The C11 standard requires that memset_s never to be optimised away. Given the number of pitfalls such as these, internal code reviews and a final, third-party code review by an expert is important and highly recommended. Whether the third party is internal or external to the organisation, an expert will pick up problems that those less well versed around the use of crypto may not.

Finally, before software is shipped to customers, an overall, system level review of all elements of the cryptographic system is in order. As the above examples show, it is not easy to get crypto right even if the bits and pieces fit well together. Unfortunately, holistic security of a product depends on intricate interactions of the cryptographic subsystem with the rest of the application, its users, the cultural and social environments it will get deployed in, and the business’ goals. The points where these meet are an ample source of confusion and error. As such, a final review is always recommended.

At GDS, we get to see a lot of crypto code, often only at the final stages of development or beyond, when it’s already in active use by end users. Fixing issues at this stage is costly to the business and frustrating to the developers. Sometimes, when looking at the issues, one wonders how much time could have been saved by using the correct crypto constructs from the right libraries, using good coding guidelines from the get go — no wasteful reinvention of the wheel and no costly retrofitting needed. When it comes to crypto, experience is key. Above, we have tried to put into writing some of the key recommendations that experienced crypto engineers give to solve real-world problems. Naturally, we have plenty more, but we always try to tailor them to needs of the application at hand. In a series of blog posts to follow we plan to go more in-depth into some of the crypto issues we highlighted above, and more.



Porting Existing Security Tools to IronWASP Modules

IronWASP is a high-extendable open source system for web application vulnerability testing. In this blog post I’m going to walk through the process of porting existing security tools (with available source code) into IronWASP modules. For this, I will be using TestSSLServer (, a simple command line tool that can be used to test the SSL/TLS security configuration of a remote HTTP server. The benefit of using this tool is that it does not require OpenSSL or any other dependencies. I’ll be using the .NET port for this example.

Lets begin by understanding what an IronWASP module is. IronWASP has a concept of plugins and modules. A module in this sense could be a standalone tool that may or may not use any of the built-in API methods provided by IronWASP. These could be tools that you may want to keep handy in your web security testing arsenal, which would not be categorised as plugins. Modules can be written in either Ruby, Python, C# or VB.Net. I will be coding my module in Ruby.

The various challenges we may face when creating such modules would include:

  • Exporting methods and debug events from the original tool to be consumed by our module

  • Building user friendly GUI elements for the module

  • Running the tool in a background thread so that the IronWASP UI does not hang while the module completes its task.

Lets go ahead and handle these step by step. To begin the process, use the built-in wizard to create a basic template. This can be found in ‘Dev Tools > Coding Assistants > Module Creation Assistant’.

After the basic template is in place, we can get to the original tool and prepare it to be ported into a module. First thing that I needed to do was to export certain information events from the tool that I could use within the module to display to the user what the tool was doing. In this case this can be done by creating an event in the C# code. Events can be created using a delegate. See the example code below for creating the delegate and event.

public delegate void OutputMessageEvent(string Output);

public event OutputMessageEvent OutputMessage; //remove static

public bool OutputEventSet




       if (OutputMessage == null)


           return false;




           return true;




public void DebugOutput(string Output)


   if (OutputMessage != null)







       { }



We then use the ‘DebugOutput’ public method to return the data as a string. I have used this method in various places in the code to create a run trace of the application. This will be later consumed from the module code and the return string will be displayed to the user.

The following code is used in the Ruby module to track these events and display in the output text box:

# Handle the output events thrown by the TestSSLServer dll and print the messages

if not @tss.output_event_set

 _outputText.Text = “”

 @tss.output_message do |msg|




Next I had to replace all the ‘Console.WriteLine’ calls and instead, collect them in a ‘Stringbuilder’ which will be used to store the results and return them at the end of execution. This should be sufficent to start building our module. I compiled the TestSSLServer.cs file into a DLL which I will be using in my Ruby module.

The next step is to create a GUI that the user would use to test the SSL/TLS server. IronWASP has a built-in GUI designer that provides the most frequently used GUI controls needed for creating modules. To begin, open the GUI designer from ‘Dev Tools > UI Designer’

Designing the GUI is straightforward and if you have designed a GUI using Visual Studio, then you will find it familiar. Once you have created a basic GUI that you are happy with, click the ‘Generate Code’ option in the UI designer. This will generate the required code for creating the GUI elements that can be included in the module code. The UI designer generates code in Ruby, Python and XML. The Ruby and Python code can be used directly in the module code whereas the XML is used in case you need to make any further changes to the GUI later, so remember to save the XML along with the Ruby or Python code. In this example, the GUI code can be found in the ‘startUI’ method of SSLSecurityChecker.rb

Here is a screenshot of the UI designer with the GUI created for this module.

The next challenge is to execute the module code in a background thread. IronWASP makes it very easy for module and plugin developers to handle threading code. I make use of the ‘IronThread’ class provided by the IronWASP API to execute the ‘RunChecks’ method. See for more details on IronThread class and how it can be used in your module code. In this scenario I use the ‘Run’ method from the IronThread class. This functionality is handled within the ‘Click’ event for the ‘Go’ button.

# Event handler for the Go button

_goBtn.Click  do

   # For running the code in a background thread, use the IronThread class

   IronThread.Run( do

           exec_checks(_hostNameValue.Text, _portValue.Text, _outputText)




Now our module is ready. This module can be executed from the IronWASP Modules tab.

Once the module is executed, the run trace created using the event in the original tool is displayed in the Output window.

When the module completes the execution of the tests, the final result is displayed in the Output window as shown below

This way we can port existing tools to IronWASP as modules or create out own modules using Ruby. Python, C# or VB.Net. Modules can make use of the full IronWASP API.

The complete code for this example can be found here: