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 ...

Patched vulnerabilities in OpenSSL with ChaCha20 and Poly1305 support

The OpenSSL team published a security advisory on August 6th 2014, see the OpenSSL site for more information. All vulnerabilities in that advisory have been patched in the latest versions of OpenSSL 1.0.1-chacha and 1.0.2-chacha:

  • Information leak in pretty printing functions (CVE-2014-3508)
  • Crash with SRP ciphersuite in Server Hello message (CVE-2014-5139)
  • Race condition in ssl_parse_serverhello_tlsext (CVE-2014-3509)
  • Double Free when processing DTLS packets (CVE-2014-3505)
  • DTLS memory exhaustion (CVE-2014-3506)
  • DTLS memory leak from zero-length fragments (CVE-2014-3507)
  • OpenSSL DTLS anonymous EC(DH) denial of service (CVE-2014-3510)
  • OpenSSL TLS protocol downgrade attack (CVE-2014-3511)
  • SRP buffer overrun (CVE-2014-3512)

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

more ...

DevOps 2014 Brisbane and security

DevOps is a worldwide phenomenon, which is reflected by the global popularity of its major event, the DevOps Days.

DevOps Days 2014 - Brisbane

I was fortunate enough to attend the DevOps Days 2014 in Brisbane.

The keynote speaker was Sidney Dekker, a Dutchman who has extensive experience on human factors and safety. He argued that a lot of major incidents don't have any precursor events.

You can have a clean track record with regards to security and still suffer a huge incident. Do I agree ? Not completely, but nonetheless thought provoking.

Personally I think that the inverse will always hold true: There is a higher chance on a major security incidents after a number of several minor security incidents. Cluttered desks mean cluttered minds after all.

Some buzzwords and issues that were (frequently) discussed:

  • Docker - A lightweight virtualization platform (can it live up to its sky-high expectations ?)
  • Microservices - Build small, independently deployable services
  • ChaosMonkey
  • Terminate random virtual machines to test (and improve) resiliency
  • Edwards Deming - The godfather of Devops ?

For me the key takeaway was that DevOps doesn't really changes your (level of operational) security. Whether system administrators deploy code built by developers or developers push their own code to an environment - in both …

more ...

Should you disable RC4 in SSL/TLS ?

I'm by no means a crypto expert. Still I'm frequently getting (and answering) questions regarding the use of RC4 in SSL/TLS. Should you disable it? Or keep it enabled?

March 2015 update - A 'new' attack method (Bar Mitsvah Attack) using a previously known RC4 vulnerability was presented, thereby reducing the RC4 security even more.

February 2015 update - RFC 7456 has been published, which effectively prohibits the use of RC4 in TLS.

This document requires that Transport Layer Security (TLS) clients
and servers never negotiate the use of RC4 cipher suites when they
establish connections. This applies to all TLS versions.


Here is my reasoning to disable all ciphersuites using RC4:

  • RC4 is a stream cipher that has been around since 1987. The number and quality of attacks on RC4 (in SSL/TLS) increases. Fact: Attacks on encryption algorithms only get better, they never get worse.
  • A lot of sites still enable RC4 in their ciphers, to support a wide browser base. Fact: Even Internet Explorer on Windows XP supports DES-CBC3-SHA (an alternative to one of the RC4 ciphers)
  • RC4 is one of the few ciphers that is resistant to the BEAST attack …
more ...

git on Windows - location of configuration files

Git is used as distributed version control system for the majority of projects I work on. On Windows I use the official Git for Windows version, as well as the 'native' mingw/MSYS2 git binary when using the MSYS2 shell.

The location of the system and global gitconfig configuration files varies, depending on which environment (native Windows command, Windows shell or MSYS2 shell) you're using, and depending on which binary (Git for Windows versus native git). There's a logic to it, but it can be hard to figure out...

Git version 2 introduced a much easier method of finding where the git configuration files are stored, the --show-origin flag. This parameter tells you exactly where each of the configuration files can be found.

Retrieve the locations (and name value pairs) of all git configuration files:

git config --list --show-origin

Retrieve the location (and name value pairs) of the system git configuration file:

git config --list --system --show-origin

Retrieve the unique locations of all git configuration files:

git config --list --show-origin | awk '{print $1}' | uniq


Regardless from where you use git on Windows, the repository (local) configuration always resides at the same location, in the root directory of your repository …

more ...

OpenSSL 1.0.2-chacha

Note: see ` <>`__ for the latest binary. The version below is obsoleted by newer builds

Windows 64-bit binary build from a 26-06-2014 snapshot of This is the official 1.0.2 branch (OpenSSL_1_0_2_stable), merged with support for the ChaCha20 and Poly1305 ciphers. Some minor build patches for Windows compatibility were applied. See the git repo for the full source.

Build commands:

  • mingw64 shared experimental-jpake enable-md2 enable-rc5 enable-rfc3779 enable-ec_nistp_64_gcc_128 enable-static-engine --openssldir=c\:/programs/openssl -DOPENSSL_NO_HEARTBEATS
  • make depend
  • make util/libeay.num
  • make util/ssleay.num
  • make
  • make report

Compiler used:

gcc version 4.9.0 (x86\_64-posix-seh-rev1, Built by MinGW-W64 project)

All tests passed

more ...

OpenSSL 1.0.1-chacha

A Windows 64-bit binary build from the 1.0.1 branch of OpenSSL (OpenSSL_1_0_1-stable), including (assembly code for) ChaCha20, Poly1305, J-PAKE, NIST P-224, NIST P-256 and the relatively unsafe ciphers MD2 and RC5 and broken protocol SSLv2. All available engines are provided as separate DLLs.
If you're using this in a production environment, don't forget to explicitly enable only ciphers that are considered safe.
The code for this build can be found at
Example openssl.cnf cipher string:

Build commands:

  • Configure mingw64 shared experimental-jpake enable-md2 enable-rc5 enable-rfc3779 enable-ec_nistp_64_gcc_128 enable-static-engine --openssldir=c\:/programs/openssl -DOPENSSL_NO_HEARTBEATS
  • make depend
  • make util/libeay.num
  • make util/ssleay.num
  • make
  • make report (all tests passed)
md5sum: d890de1ab4eba13c7d39139c5726144f

Compiler used:

  • gcc version 4.9.0 (x86_64-posix-seh-rev1, Built by MinGW-W64 project)
more ...