Add support for legacy clients using SSLv2 and SSLv3

[no0be]

Use a local build of OpenSSL in order to add support for legacy clients using SSLv2 or SSLv3 (s.a. Windows 7) while maintaining support for modern systems, without compromising the integrity of the attacker's operating system.

Since OpenSSL needs to be compiled with special flags for this to work, this also adds a small script to automate the building process.

This is completely based on s0lst1c3's recent update to eaphammer for which details can be found here:

• http://solstice.sh/wireless/eaphammer/2019/01/31/adding-sslv23-support-to-eaphammer/
• Legacy crypto support sslv3 s0lst1c3/eaphammer#53

[adde88]

This caught my interest. I'm following Sensepost for updates to the project, as i'm porting it to OpenWRT.
I've added these changes to a branch of my project, just for testing.
I also compiled openssl-1.1.1b with the custom arguments successfully.

If people are interested in testing this on OpenWRT, feel free to head to my repos below:
hostapd-mana (hostapd source)
hostapd-mana-openwrt (openwrt Makefiles, and packages)
Just checkout the branch "ssl-testing"

[singe]

I’ve been thinking about this. I’d like to make it optional. I wouldn’t want to force an old version of SSL as the default purely for some legacy clients. I’m just not sure how yet. Ideally as a runtime option, but I don’t see how to build against both, alternatively as a build option but then I need to maintain two binaries. Any ideas?

[adde88]

Yeah, i understand the issue.
Ideally would properly be as a run-time option (perhaps providing an argument), but i think that would be tough to implement.
The easiest options sounds like a build option, as compiling this was relatively straight forward, and didn't require much changes to the source files.
I'll definitely be giving it some more thought.

[no0be]

As @adde88 pointed-out, I think that you could successfully use the latest OpenSSL version (1.1.1b). The key part is to compile it to support legacy ciphers and to link hostapd-mana with the local build. You would have to manually upgrade the OpenSSL submodule used by the repo with every version upgrade though.

[no0be]

Upgrading the OpenSSL submodule is quite straight forward and I confirm that hostapd-mana builds fine with the latest OpenSSL 1.1.1b version. Check-out my last commit on no0be:openssl-patch.

[singe]

Ok, this came back to bite me all these years later in a training course. A student helped me with an idea to use a custom configuration file:

cat > /tmp/openssl-legacy.cnf <<'EOF'
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1
EOF

export OPENSSL_CONF=/tmp/openssl-legacy.cnf

This was we don't need to recompile mana against an older OpenSSL, and can selectively enable it when needed.