On Web Security

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 https://onwebsecurity.com/cryptography/openssl for the latest Windows 32 and 64 bit binaries, and https://github.com/PeterMosmans/openssl for the latest sources.

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

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 …

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.

See http://tools.ietf.org/html/rfc7465

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 …

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

Note: see `http://www.onwebsecurity.com/cryptography/openssl <https://www.onwebsecurity.com/cryptography/openssl>`__ for the latest binary. The version below is obsoleted by newer builds

Windows 64-bit binary build from a 26-06-2014 snapshot of https://github.com/PeterMosmans/openssl/tree/1.0.2-chacha. 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

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)

Compiler used:

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

Note: see http://www.onwebsecurity.com/cryptography/openssl for the latest binary. The version below is obsoleted by newer builds

Build commands:

Configure mingw64 shared experimental-jpake enable-md2 enable-rc5 \
enable-rfc3779 enable-ssl-trace enable-ec_nistp_64_gcc_128 \
enable-static-engine --openssldir=c:/tools -DOPENSSL_NO_HEARTBEATS \
-mtune=native
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)

Note: see https://www.onwebsecurity.com/cryptography/openssl for the latest binary. The version below is obsoleted by newer builds

The main development branch of OpenSSL doesn't have support yet for the (relatively new) ChaCha 20 and Poly1305 ciphers. These can be found however on the 1.0.2-aead branch.

By slightly modifying some makefiles the source can be compiled for 64-bit Windows using mingw64 and msys.

Please find a binary build from a 27-05-2014 snapshot of the source code (1.0.2-aead branch) with assembly code enabled (imported from the 1.0.2 stable branch), and a lot of insecure, new and experimental ciphers enabled. I added the GOST engine gosteay32.dll as well.

The source code for this build can be found at https://github.com/PeterMosmans/openssl

Build commands:

• Configure mingw64 shared experimental-jpake enable-md2 enable-rc5 enable-rfc3779 enable-ssl-trace enable-ec_nistp_64_gcc_128 enable-static-engine --openssldir=c:/tools
• make depend
• make util/libeay.num
• make util/ssleay.num
• make
• make test

Enabled ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• ECDHE-ECDSA-AES256-SHA
• SRP-DSS-AES-256-CBC-SHA
• SRP-RSA-AES-256-CBC-SHA
• DH-DSS-AES256-GCM-SHA384
• DHE-DSS-AES256-GCM-SHA384
• DH-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-DSS-AES256-SHA256
• DH-RSA-AES256-SHA256
• DH-DSS-AES256-SHA256
• DHE-RSA-AES256-SHA
• DHE-DSS-AES256-SHA
• DH-RSA-AES256-SHA
• DH-DSS-AES256-SHA
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305
• DHE-RSA-CHACHA20-POLY1305
• DHE-RSA-CAMELLIA256-SHA
• DHE-DSS-CAMELLIA256-SHA
• DH-RSA-CAMELLIA256-SHA
• DH-DSS-CAMELLIA256-SHA
• GOST2001-GOST89-GOST89
• GOST94-GOST89-GOST89
• AECDH-AES256-SHA
• SRP-AES-256-CBC-SHA
• ADH-AES256-GCM-SHA384
• ADH-AES256-SHA256
• ADH-AES256-SHA
• ADH-CAMELLIA256-SHA
• ECDH-RSA-AES256-GCM-SHA384
• ECDH-ECDSA-AES256-GCM-SHA384
• ECDH-RSA-AES256-SHA384
• ECDH-ECDSA-AES256-SHA384
• ECDH-RSA-AES256-SHA …

Compiling OpenSSL on Windows using MSYS and mingw64 is pretty straightforward. However, one of the tests (test_bn) to verify OpenSSL fails: The temporary file that test_bncreates contains Windows newline characters (\r\n) instead of the Unix type newline charater (\n).

The original regular expression checks for a zero (0) at the beginning of a line, and a newline character (\n).

(!/^0$$/)

A change to the regular expression that test_bn uses fixes this problem, and can be used on Unix as well as Windows environments. This makes the Makefile more cross-platform friendly. The modified regular expression checks for a zero (0) at the beginning of a line, an optional Windows newline character (\r) and a newline character (\n).

(!/^0\r?$$/)

--- openssl-1.0.1g/test/Makefile 2014-04-07 16:55:44 +0000 +++ patched/test/Makefile 2014-05-06 00:07:20 +0000 @@ -227,7 +227,7 @@ @../util/shlib_wrap.sh ./$(BNTEST) >tmp.bntest @echo quit >>tmp.bntest @echo "running bc" - @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i tests passed\n"' + @) {if (/^test (.*)/) {print STDERR "\nverify …

If you're like me, you don't want to spend your precious memory on remembering awkward command line parameters. However, lots of tools require exactly that: awkward command line parameters.

Note that the latest version is the Python version - please use that one.

git clone https://github.com/PeterMosmans/security-scripts.git

usage: analyze_hosts.sh [OPTION]... [HOST]

Scanning options:
 -a, --all perform all basic scans
 --max perform all advanced scans (more thorough)
 -b, --basic …