Chiffrements non sécurisés d'OpenSSL : pourquoi est-ce si difficile de les activer, et comment y parvenir

Saviez-vous qu'il est presque impossible de régresser la sécurité TLS en activant des chiffrements dépréciés sur les versions récentes d'OpenSSL ?

Bien sûr, c'est une bonne chose : ainsi, les développeurs ne le feront pas par accident.

Mais quand on travaille dans le domaine de la cybersécurité et qu'on a besoin, pour une raison ou une autre, de choses « cassées », il est stupéfiant de constater que même en spécifiant explicitement l'option enable-weak-ssl-ciphers ou enable-rc4 lors de la COMPILATION d'OpenSSL, ça ne fonctionne pas le moins du monde.

Voyons comment le forcer.

Vous devez déjà savoir que simuler un serveur avec une compilation d'OpenSSL par défaut ou personnalisée ne fonctionne pas.

openssl s_server -cipher ALL:eNULL:aNULL -accept 4443 n'accepte que 40 chiffrements sur 80, malgré les efforts pour TOUS les inclure, même et surtout les plus faibles.

Faufilons-nous dans le code source d'OpenSSL.

Essai avec une ancienne version d'OpenSSL

En lisant le fichier CHANGES.md du code source officiel d'OpenSSL, on rencontre des changements importants entre les versions 1.1.1 et 3.0.0.

À quoi fait référence le « legacy provider » (fournisseur hérité) ?

Les providers (fournisseurs) dans OpenSSL sont comme des modules d'extension qui proposent différents ensembles d'algorithmes, et le legacy provider en est un. En plaçant des algorithmes comme CAST, IDEA, SEED, RC2, RC4, RC5, DESX et DES dans le legacy provider, OpenSSL les sépare de l'ensemble d'algorithmes par défaut, ce qui encourage les développeurs à éviter de les utiliser dans de nouveaux projets sauf absolue nécessité.

Pour utiliser ces algorithmes hérités, les développeurs doivent charger explicitement le legacy provider dans le code de leur application : c'est la façon qu'a OpenSSL de faire reconnaître aux utilisateurs qu'ils emploient des méthodes cryptographiques dépréciées ou moins sûres.

Donc, essayer avec OpenSSL 1.1.1 ou une version antérieure devrait marcher, non ?

Pour savoir si ça marche, il vous faudra télécharger et compiler la release vous-même ; pour autant qu'on s'en souvienne, certaines versions n'avaient pas publié de build pour OS X ni pour x86_64 : seulement i386.

S'il existait seulement un conteneur Docker qui compile les dépendances requises et effectue toutes les étapes nécessaires…

Dites bonjour à httpd-docker ! https://github.com/avineshk09/httpd-docker/tree/master est un projet qui fait tourner un ancien serveur Apache avec OpenSSL-1.0.2d ! Cinq ports sont configurés dans extra-ssl-hosts.conf, chacun activant une version différente de SSL/TLS.

Voyons s'il active vraiment d'anciennes suites de chiffrement.

Après avoir cloné le projet et suivi les instructions du httpd-docker/README.md, la sortie du terminal confirme que l'installation fonctionne.

Maintenant, vérifions si le serveur Apache local accepte des suites de chiffrement faibles qui ne seraient jamais actives dans une configuration OpenSSL à jour.

Utilisons des outils de cybersécurité conçus pour reconnaître les communications TLS non sécurisées. Il en existe beaucoup (SSLyze, SSLscan, pour n'en citer que quelques-uns).

Essayons avec le célèbre énumérateur de suites de chiffrement SSLscan, en cherchant par exemple le très déprécié algorithme RC4 :

sslscan localhost:1204 a donné des résultats montrant des occurrences de RC4 pour l'un des deux seuls protocoles TLS sûrs : la v1.2 !

Au fait, comment SSLSCAN parvient-il à détecter ces anciennes suites de chiffrement, en même temps que les plus récentes… ?

La réponse sera un peu décevante.

Inconvénients et limites de cette approche

Dans l'exemple, on utilise OpenSSL-1.0.2d. La version la plus récente est la 3.4.0.

De nombreux changements majeurs ont été publiés depuis, pour n'en citer que quelques-uns :

• TLSv1.3, introduit dans openssl-1.1.1
• Le moteur GOST
• Pre-Shared Key (PSK) et PSK avec Early Data (0-RTT) (RFC 8446)
• Encrypted Server Name Indication (ESNI) / Encrypted ClientHello (ECH)
• Renegotiation Info (RFC 5746)
• etc…

Donc, on gagne d'un côté ce qu'on perd de l'autre.

Comment SSLSCAN détecte-t-il et implémente-t-il le legacy provider ?

En regardant SSLscan de plus près, on remarque 3 choses :

• Dans le Makefile, il récupère et compile les bibliothèques statiques d'OpenSSL version 3.0.15.
• Il utilise l'option enable-weak-ssl-ciphers
• Mais… Il code en dur les chiffrements faibles dans missing_ciphersuites.h.

En réalité, il n'a pas besoin de contenir le code lié aux suites de chiffrement faibles : il ne fait que des handshakes SSL. Il dit seulement aux serveurs qu'il peut chiffrer la communication avec cet algorithme, il ne le fait jamais.

Juste après le handshake, SSLscan ferme la connexion.

Alors… Est-il même possible d'activer le legacy provider sur OpenSSL 3.0.0 ?

La réponse est oui, avec le fichier **openssl.cnf**.

Pour être honnête, cela a été découvert en se débattant avec ChatGPT. C'est en fait assez normal. Comme on l'a vu plus tôt avec le concept de legacy provider, l'équipe d'OpenSSL le rend difficile, exactement comme si vous tentiez de modifier le noyau Linux : vous ne devriez jamais le faire, sauf si vous savez ce que vous faites.

Le fichier de configuration devrait ressembler à ceci :

HOME
# These must be in the default section
config_diagnostics = 1
openssl_conf = openssl_init

[openssl_init]
oid_section = oids
providers = providers
alg_section = evp_properties
ssl_conf = ssl_configuration
engines = engines
random = random

[oids]
... new oids here ...

[providers]
... -> Providers as legacy providers ??? <-

[evp_properties]
... EVP properties here ...

[ssl_configuration]
... SSL/TLS configuration properties here ...

[engines]
... engine properties here ...

[random]
... random properties here ...

Et, comme l'indique la documentation officielle, dans le openssl.cnf de votre machine (dont le chemin se trouve avec openssl version -d), la ligne qui active la section provider est commentée.

La recommandation est de récupérer ce script, qui télécharge la dernière version d'OpenSSL dans un dossier nommé openssl-deprecated/ afin de tester :

# 1. Download OpenSSL source
set -euox pipefail

wget https://www.openssl.org/source/openssl-3.4.0.tar.gz
tar -xzf openssl-3.4.0.tar.gz
cd openssl-3.4.0

# 2. Configure OpenSSL with weak ciphers and custom directory
mkdir -p ~/openssl-deprecated
./Configure enable-weak-ssl-ciphers --prefix=$HOME/openssl-deprecated

# 3. Build and install in the custom directory
make -j 10
make install

# 4. / ! \ The most important part: editing openssl.cnf
echo "[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

[default_properties]
security_level = 0

# Enable legacy ciphers
CipherSuites = LEGACY" >> ./ssl/openssl.cnf

# 5. Set environment variables for the current session
export PATH=$HOME/openssl-deprecated/bin:$PATH
export OPENSSL_CONF=$HOME/openssl-deprecated/ssl/openssl.cnf
export OPENSSL_DIR=$HOME/openssl-deprecated

# 6. Test weak ciphers
./bin/openssl ciphers -v "ALL:@SECLEVEL=0"

Et en simulant un serveur avec OpenSSL, on peut obtenir des résultats.

Et en énumérant les chiffrements qu'il accepte avec sslscan localhost:4443, on observe une détection réussie des chiffrements hérités.

Voilà ! (La coloration rose dans SSLscan indique que le serveur chiffre des suites vraiment non sécurisées.)