Since its inception in 2014, the OpenSSL 1.0.2-chacha fork [1] has been used as standard OpenSSL distribution for numerous SSL/TLS pentesting tools. It includes default support for ciphers that are deemed insecure, and has extensive starttls support.... in comparison with the vanilla 1.0.2 branch.

However, even though 1.0.2 is deemed a Long Term Supported (LTS) version, no new ciphers or functionality will be added to it.

The initial reason to start the fork was a lack of ChaCha20 / Poly1305 support in the 1.0.2 branch. After that, more and more features and insecure ciphers were added or ported back in from other branches.

As ChaCha20 / Poly1305 support has been added to the 1.1.1 branch, which also contains (preliminary) TLS 1.3 support, it might be time for the insecure OpenSSL version to be rebased onto a new branch. The initial goals will still be the same:

• Add as much ciphers and functionality as possible
• Keep the source aligned as much as possible to the vanilla version
• Keep the patches atomic, transparent and maintainable
• Write as little custom code as possible

This will be quite the challenge, as the architecture and …

If you're around in Las Vegas during BlackHat / BSidesLV / DefCon, I'll be presenting at BSidesLV 2016 together with Melanie Rieback on an open source pentest reporting framework.

The talk will announce a new OWASP project: PenText, a fully open-sourced XML-based pentest document automation system. The PenText system is a document automation framework that supports the entire pentesting lifecycle: from the initial inquiry, through pentest scoping, quotations, pentesting, and reporting, through the final invoice.

During this talk, Melanie and I will demonstrate the OWASP PenText system live, in the context of our larger Pentesting ChatOps infrastructure (RocketChat, Hubot, and Gitlab). We will describe the basics of how the OWASP PenText system is architected (XML, XSLT, XSL-FO), and show how the system can be used to manage the entire lifecycle of pentesting data, including the automatic generation of documentation at various points in the process (including quotations, pentest reports, and invoices).

Lots of ChatOps in combination with pentesting and open source.

See https://bsideslv2016.sched.org/event/7azc/are-you-a-pentexter-open-sourcing-pentest-reporting-and-automation

See you there ?

A post back I wrote about the 'design goals' of the 1.0.2-chacha fork of OpenSSL - see https://www.onwebsecurity.com/openssl/the-work-flow-of-the-full-featured-openssl-fork-chacha20poly1305.

The ChaCha20 / Poly1305 code in the 1.0.2-chacha fork is originally from the OpenSSL repository, but has since been abandoned there. BoringSSL became its new home, where it's actively being maintained by Google (primarily Adam Langley and David Benjamin). Over time I applied several patches that BoringSSL applied to the ChaCha20 / Poly1305 code, to keep it as up to date as possible.

The issue now is that BoringSSL diverges more and more from the OpenSSL code, which makes it more difficult to maintain (error-prone), and, more important, makes the fork itself diverge too much from OpenSSL.

That's why it's my intention to replace the current ChaCha20 / Poly1305 code from 1.0.2-chacha with more recent attributions that align better with the official OpenSSL code. As far as I understood the official OpenSSL distribution will add ChaCha20 / Poly1305 at some time in the future, which of course would be the best possible outcome. Official support.

Until that time I will do my best to maintain the 1.0.2-chacha branch.

As you might know I maintain a fork of OpenSSL at https://github.com/PeterMosmans/openssl 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 …

February 2015 update: read …

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 https://www.onwebsecurity.com/cryptography/openssl for the Windows 32 and 64 bit binaries, and more information.

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

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

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.

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