The workflow of the Full-Featured openssl Fork (ChaCha20/Poly1305) 1.0.2-chacha

As you might know I maintain a fork of OpenSSL at The 1.0.2-chacha fork started out of adding the ChaCha20/Poly1305 ciphers to the official fork, and slowly more and more ciphers and features were added.


The main goals of the fork are

  1. add as much ciphers and (test)functionality as possible
  2. to keep the source as aligned to the original as possible
  3. keep the patches transparent (easily applicable to the original source)
  4. keep the patches maintainable
  5. write as little custom/new code as possible

For 2 (to keep the source as aligned to the original as possible) I try to merge and test the code as often as I can, so that the fork is never too far behind the official repository.

As it was my first idea to start a feature branch I used no-fast forwarding git merges. This kept it transparent when I merged the code, and what the history of the commits was. However, since I'm probably going to maintain this fork besides the official fork I'm going to use fast-forwarding merges from now on (March 2014) whenever possible. I think this will keep the commit history cleaner - see …

more ...


As you probably read somewhere else, and on another place, and another... on March 3rd 2015, another attack on SSL/TLS was published. Following the tradition of BEAST, CRIME, Heartbleed, LUCKY13 and POODLE this one also has a catchy name: FREAK (Factoring RSA Export Keys).

It's a man-in-the-middle attack where a man in the middle can decrypt a SSL/TLS connection between a client and a server.


Vulnerable *servers* are servers that accept export-grade ciphers (RSA-EXPORT). Checking whether a server is vulnerable can be done in many ways.

analyze_hosts --ssl HOST

If you see any EXPort ciphers, the server is vulnerable.

cipherscan HOST:443

If you see any EXPort ciphers, the server is vulnerable.

  • Yet another way is by using nmap:
nmap --script ssl-enum-ciphers -p433 HOST

If you see any EXPort ciphers, the server is vulnerable.

You get the idea...

Mitigate this vulnerability server-side by making sure that your server doesn't allow export ciphers in the OpenSSL configuration: add the following expression


There are also vulnerable clients...

Clients using OpenSSL are not vulnerable if they were built after CVE-2015-0204 was published.

The …

more ...

Us versus them: CrikeyCon 2015 review

I had the chance to visit CrikeyCon February 2015, which was held in Brisbane


It was the second time this event was held, but it already got the looks and feel of a professional organization behind it. The program was really diverse, from social engineering and awkward hugs to iOS runtime hacking, and everything in between.

Takeaway ? Well, it surprised me to hear that there's still a general feeling of us versus them. We the security gods who lay bare all the faults and stupid mistakes the others make.

As a security professional, especially as a pentester, it's your job to find vulnerabilities and weaknesses. It's your job to hunt for other people's mistakes, lack of knowledge, or constrained security budgets. Security falls into the quality assurance department.

This means that most of the time you're telling other people what's wrong with an application. Unfortunately it's not your job to tell them how awesome their web application is, how well it scales, or the nifty features it has.

One of the more challenging issues when for instance presenting a pentest report to a group of developers is to get everybody on board, to get everybody to work together. And if …

more ...

OpenSSL 1.0.2 - now with less whitespace!

On January 22 2015, version 1.0.2 of OpenSSL was released. Besides some new bugfixes and features, the biggest change under the hood was a complete reformatting of the source code. An official coding style document was published, and as a result primarily buckets and lots of tabs and newline characters have been converted into whitespaces.
Personally I hope that this action, which affected the majority of lines(!) of code, will help the project for the best and will make it easier to maintain the project in the future.
One disadvantage of reformatting code for instance however is that it makes it a lot harder to spot differences in code between certain versions, as almost all files have most of their lines changed.
Another disadvantage is that merging additional patches (like the ChaCha20 and Poly1305 ciphers) back into OpenSSL took a great deal of extra time. Unnecessary time, one might say.
The OpenSSL 1.0.2 fork including the ChaCha20 and Poly1305 ciphers has been pushed to the github repo at
As always, you can find compiled Windows 32 and 64 bit binaries at

February 2015 update: read …

more ...

CVSSv2 rating of new vulnerabilities patched in OpenSSL

On January 8th, 2015, the OpenSSL team published an OpenSSL Security Advisory containing 8 previously unknown vulnerabilities in OpenSSL.

Unfortunately, as with most large software suppliers/vendors nowadays, OpenSSL uses its own severity classification system for vulnerabilities. There are many classifications systems out there, which results in less transparent patching policies and procedures for system administrators and end users. Fortunately NIST publishes the CVSSv2 Severity Base Score of most, if not all vulnerabilities with a CVE entry. This makes it easier to classify.


Two of the eight vulnerabilities (CVE-2014-3571 and CVE-2015-0205) have the OpenSSL vulnerability rating 'moderate'. This corresponds to a CVSSv2 base score of 5.0 (MEDIUM) for CVE-2014-2571 as well as CVE-2015-0205 Both of these vulnerabilities could be exploited for a Denial of Service attack of the OpenSSL service. The remaining six vulnerabilities have a lower rating.

The 1.0.2-chacha and 1.0.1-chacha branches of the ChaCha20 - Poly1305 fork of OpenSSL have been patched for all of the published vulnerabilities.

As always, see for the Windows 32 and 64 bit binaries, and more information.

more ...

MSYS2 - successful successor of MSYS ?


MSYS can best be described as a Bash shell and some GNU tools, which facilitate compiling sources under and for a Windows environment. It's the environment to use when compiling for instance OpenSSL or Emacs on Windows.

MSYS2 is the 'new and improved' version of MSYS.

One of its biggest advantages is better package management. MSYS2 has pacman, a package manager from Arch Linux. Upgrading can finally be done from within the shell session itself, with only a few basic commands.

# download package descriptions from the remote repositories
pacman -Sy
# upgrade MSYS2 core components and the shell itself
pacman --needed -S bash pacman msys2-runtime
# restart MSYS2 if any package needed updating, then update the rest
pacman -Su

This was 'somewhat more difficult' under MSYS.

Another advantage is the Bash version - currently at 4.3.30 versus 3.1.17 on MSYS. Bash 4 means support for functions like associative arrays and fancier redirections:

# redirect stdout and stderr at the same time
command &> output

# same command in Bash 3 syntax
command > output 2>&1

# pipe stdout and stderr at the same time
command |& someothercommand

# same command in Bash 3 syntax
command 2>&1 \| someothercommand

The third big plus is that it's …

more ...

OpenSSL: Fatal SSL alert number 47 (Illegal Parameter)

As a pentester, I regularly test the configuration of SSL servers. For this purpose I use my customized OpenSSL fork which contains a lot more ciphers than the official version, and wrapper scripts (easier than remembering command line options).
Last month I ran into an issue with servers behind a SSL terminator from a well-known network equipment supplier. As soon as the SSL Client Hello offered 128 or more ciphers to the server and the tls1_2 protocol was specified, the handshake was aborted with the following error message
9304:error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:s3_pkt.c:1481:SSL alert number 47 9304:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:636:

The supplier hadn't heard of this bug yet - I suspect that not that many browsers or generic SSL clients offer 128 or more ciphers. A bugreport has been filed.

To facilitate the testing of SSL/TLS handshakes I created a script, which can be found at GitHub. Currently 3 handshake bugs are identified.

Of course you can test for this bug using a version of OpenSSL with enough (128 or more) ciphers, and the command

openssl s_client -connect host:port -tls1_2
more ...

Black Hat Europe 2014 review

Black Hat Europe was held in Amsterdam in October, 2014. The so called Briefings (tech talks) were extremely versatile, ranging from Android pentesting to SCADA hacks. It was difficult to choose which talk to attend - there were around 50 or so, each title vying for your attention ("Hack Your ATM with Friend's Raspberry.Py" [sic], or "Endrun - Secure Digital Communications for Our Modern Dystopia").

Black Hat Europe 2014

I really enjoyed the technical depth of some talks, and it was great to hear someone like Adi Shamir, one of the inventors of the famous RSA algorithm, talk about his current research.

Because of the sheer size I couldn't find one generic takeaway, or see the, or a current bigger picture in information security land. Even all of the vendors' offerings looked similar.

Now that I come to think of it, that actually IS the key takeaway: Genericity.

more ...

Creating and verifying digital signatures of files

Digital signatures can be used to establish the authenticity and integrity of a (binary) file. These signatures can also be used for non-repudiation purposes, but that's usually not the intention when you're distributing or receiving files. (Note: non-repudiation means impossible to reject; to make sure beyond a doubt that the signer's key has been used to create that signature).

The easiest and most secure way of creating and verifying digital signatures is by using PGP. The following commands assume that you have downloaded and configured GPG, the free and complete implementation of the OpenPGP standard.

Create a digital signature of FILENAME

gpg --armor --detach-sig --output FILENAME.sig FILENAME
--armor make sure that the file is ASCII armored (Radix-64 encoded)
--detach-sig create a separate signature file
--output the name of the signature file

Paranoid options

--no-version don't show which software version has been used to create the signature
--comment don't show which software has been used to create the signature

Verify a digital signature

gpg --verify FILENAME.sig

This command assumes that the original file is FILENAME and resides in the same location as the signature file FILENAME.sig. To verify a signature you also need the signer's public key. If …

more ...

Patched openssl SSLv3 downgrade attack (POODLE) with ChaCha20 and Poly1305 support

The OpenSSL team published a security advisory on October 15th 2014, see the OpenSSL site for more information.
In short, SSLv3 using Cipher Block Chaining mode (CBC) has a weakness, which can be exploited using the POODLE attack having CVE entry CVE-2014-3566.
The POODLE attack depends on SSLv3 and tries to downgrade a connection to that specific, really old protocol. This downgrade can be mitigated by using the signaling cipher suite value (SCSV) TLS_FALLBACK_SCSV, which is implemented in the/this latest version of openssl. Please be advised that not only the server, but the client itself also has to support this relatively new method.

All vulnerabilities in the advisory have been patched in the latest versions of OpenSSL 1.0.2-chacha. Moreover, the new binaries/source are aligned with the latest beta release (3).

  • SRTP Memory Leak (CVE-2014-3513)
  • Session Ticket Memory Leak (CVE-2014-3567)
  • SSL 3.0 Fallback protection
  • Build option no-ssl3 is incomplete (CVE-2014-3568)

As always, check for the latest Windows 32 and 64 bit binaries, and for the latest sources.

more ...