Vérifications du bundle eMudhra

https://emudhra.we-have-a-problem.com/

Bien sûr, vos navigateurs font ce qu'il faut, mais TLS intervient à bien plus d'endroits que dans le navigateur. Vous devez donc vérifier tous les endroits où un bundle pourrait se cacher. Quelle galère !

Je n'ai pas de solution pour vous, désolé. Mais si vous voulez simplement vérifier si un langage donné fait ce qu'il faut par défaut, voici quelques programmes d'exemple simples. Chacun retournera silencieusement rien (parce que c'est la façon Unix) si tout va bien et signalera une erreur s'il peut se connecter aux sites malveillants connus.

L'outil utilisera ce qui est par défaut pour le framework/langage donné, mais vous pouvez aussi spécifier un autre bundle à vérifier. S'il sait comment, il affichera quel bundle / chemin il a utilisé.

Exemples

Go

$ go run emudhra.go
$ go run emudhra.go /tmp/cert.pem.bad 
BAD: successful connection to https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
BAD: successful connection to https://dv-g3b-emudhra.we-have-a-problem.com/
exit status 2
$

Java

$ java emudhra.java 
Using CA file: /opt/homebrew/Cellar/openjdk/23.0.2/libexec/openjdk.jdk/Contents/Home/lib/security/cacerts
BAD: successful connection to https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
BAD: successful connection to https://dv-g3b-emudhra.we-have-a-problem.com/
$ java emudhra.java  /etc/ssl/cert.pem
Using CA file: /etc/ssl/cert.pem
$

Envisagez d'ajouter les intermédiaires à votre blocked.certs comme expliqué ici.

Node

$ node emudhra.js
$ node emudhra.js /tmp/cert.pem.bad 
BAD: successful connection to https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
BAD: successful connection to https://dv-g3b-emudhra.we-have-a-problem.com/
$

Perl

$ perl emudhra.pl 
Using SSL_ca_file: /private/etc/ssl/cert.pem
$ perl emudhra.pl /tmp/cert.pem.bad 
Using SSL_ca_file: /tmp/cert.pem.bad
BAD: successful connection to https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
BAD: successful connection to https://dv-g3b-emudhra.we-have-a-problem.com/
$

Python

$ python3 emudhra.py
Using CA file: /opt/homebrew/etc/openssl@4/cert.pem
$ python3 emudhra.py /tmp/cert.pem.bad 
Using CA file: /tmp/cert.pem.bad
BAD: successful connection to https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
BAD: successful connection to https://dv-g3b-emudhra.we-have-a-problem.com/
$

Ruby

$ ruby emudhra.rb 
Using CA file: /usr/lib/ssl/cert.pem
$ ruby emudhra.rb /tmp/cert.pem.bad 
Using CA file: /tmp/cert.pem.bad
BAD: successful connection to https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
BAD: successful connection to https://dv-g3b-emudhra.we-have-a-problem.com/
$

Curl

$ sh emudhra.sh 
Used CA file: /etc/ssl/certs/ca-certificates.crt
$ sh emudhra.sh
/tmp/cert.pem.bad 
Used CA file: /tmp/cert.pem.bad
BAD: successful connection to https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
BAD: successful connection to https://dv-g3b-emudhra.we-have-a-problem.com/
$

Remarque : sur macOS, vous pouvez demander à curl(1) d'utiliser le backend natif, qui rejette alors la connexion dans tous les cas :

$ CURL_SSL_BACKEND=secure-transport sh emudhra.sh /tmp/cert.pem.bad 
Used CA file: 
$ 

Rust

$ cd rs
$ cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
     Running `target/debug/rs`
$ cargo run -- /tmp/cert.pem.bad 
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s
     Running `target/debug/rs /tmp/cert.pem.bad`
$

Quelque part dans ses dépendances, Rust effectue une véritable vérification de liste de blocage sur les intermédiaires compromis, donc même avec un bundle qui fait confiance à la racine d'eMudhra, il échoue à se connecter.