Another Home Page Blog - TLS

Vérifier les chiffrements disponibles sur un serveur HTTPS avec Nmap

2017-02-20T09:30:00+01:00

Je me suis retrouvé l'autre jour avec une alerte de sonde de détection d'intrusion, laquelle me signalait qu'une potentielle exploitation de la faille Heartbleed avait eu lieu sur un serveur web. L'autre détail que j'avais au niveau de l'alerte : le protocole utilisé pour cette exploitation était SSL v3.

N'ayant pas la main sur la machine, je n'avais pour seule option que de vérifier côté client si le serveur utilise ce protocole. Sur l'instant, j'ai pensé à utiliser OpenSSL, qui dispose d'options pour se connecter à un serveur en utilisant certains protocoles. Cela donne pour mon cas, l'exemple et le résultat suivant :

$ openssl s_client -connect blog.anotherhomepage.org:443 -ssl3
CONNECTED(00000006)
140187574654788:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/usr/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:1304:SSL alert number 40
140187574654788:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/usr/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:637:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1485895043
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Alors bon, je sais pas trop vous, mais pour moi, ce n'est pas très évident que le serveur ne prend pas en charge SSL v3. Il y a quand même écrit "CONNECTED" au début, avant de me sortir "handshake failure". Néanmoins, la mission est remplie, et on peut vérifier plusieurs protocoles via les options suivantes d'OpenSSL :

* -ssl2 ;* -ssl3 ;* -tls1_2 ;* -tls1_1 ;* -tls1 ;* -dtls1.

Peu satisfait de la solution, j'ai continué mon voyage dans les moteurs de recherche, avant de tomber sur une question similaire, disposant de la première solution, mais d'une autre visiblement plus lisible, utilisant le célèbre Nmap. Elle consiste à tirer parti d'une fonctionnalité assez intéressante du célèbre scanneur de ports, à savoir la disponibilité d'un langage de script permettant d'obtenir des détails supplémentaires lors d'un scan de port. Parmi les scripts disponibles, certains ont même pour but de mener des attaques par bruteforce. Là, il n'est pas question d'attaque, mais simplement d'énumération des ciphers disponibles. Comme plus haut, voici un exemple accompagné d'un résultat :

Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-19 09:30 CET
Nmap scan report for blog.anotherhomepage.org (163.172.46.128)
Host is up (0.0012s latency).
rDNS record for 163.172.46.128: vhost2.anotherhomepage.org
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 10.06 seconds

On remarquera, dans mon exemple, l'absence de SSLv3.

Et pour l'alerte de mon IDS ? Et bien comme dans mon exemple, SSLv3 n'est pas apparu dans mes résultats, ce qui m'a permis de conclure au faux-positif.

Un dernier détail : au moment de l'écriture de ce billet, NSE n'est pas activé par défaut dans pkgsrc, et pour NetBSD, son activation empêche de compiler Nmap.

Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !

dehydrated, un client alternatif pour Let's Encrypt

2017-01-16T09:30:00+01:00

Après quelques galères avec Certbot, j'ai découvert dehydrated, un client pour Let's Encrypt écrit en Bash.

Depuis plusieurs semaines, voire mois, le client officiel de l'autorité de certification Let's Encrypt, Certbot, ne fonctionne plus sous NetBSD. Cela semble venir du fait que Python, dont dépend Certbot, est compilé avec PaX MPROTECT. C'est tout du moins ce qu'indique ce rapport de bug.

N'ayant ni le temps ni les compétences pour voir ce qui bloque exactement du côté de Certbot, j'ai fait ce que pas mal d'autres ont fait : j'ai recherché une alternative. La première alternative qui a attiré mon attention est acme-client, en version portable, d'ailleurs disponible au moment où j'écris ces lignes dans pkgsrc-wip. Mais en fait celui-ci ne semble pas fonctionner sous NetBSD, me hurlant des histoires de droits et de suid bizarres.

J'ai ensuite jeté mon dévolu sur dehydrated, un client écrit en Bash. Celui-ci a l'avantage non-négligeable de fonctionner, contrairement au précédent. Je me suis donc lancé dans son empaquetage (wip/dehydrated au moment où j'écris ces lignes, mais j'espère l'importer dans pkgrsc-current dès que possible). Dehydrated est assez pratique à utiliser, il nécessite des dépendances assez classiques pour un script shell (sed, awk, curl), en plus d'OpenSSL. Bien qu'il dispose de fichiers de configuration, de nombreuses options peuvent être spécifiées sur la ligne de commandes. Dehydrated prévoit aussi des scripts "hook" pour pouvoir déclencher d'autres actions avant et après le renouvellement d'un certificat par exemple.

Le paquet est globalement fonctionnel sous NetBSD, le seul prérequis avant de se lancer dans l'édition des fichiers de configuration est d'avoir une configuration OpenSSL existante (ce qui se fait rapidement, en copiant simplement le fichier d'exemple fourni dans /usr/share/examples/openssl/), et de savoir dans quel répertoire le challenge ACME sera déposé. J'espère d'ici là avoir amélioré la prise en compte d'OpenSSL d'ailleurs (utilisation de celui de pkgsrc par exemple). Idéalement, ce serait assez cool que dehydrated puisse utiliser LibreSSL.

Il existe d'autres clients alternatifs que je n'ai pas essayés, comme getssl, mais lequel est votre préféré et pourquoi ? Le formulaire de commentaire n'attend que votre réponse !

Installation de mod_gnutls sur CentOS 5

2008-05-24T10:30:00+02:00

petit lien à garder sous le coude au cas où

Il y a quelques jours je voulais mettre plusieurs sites Internet en HTTPS, sur le même serveur dédié. Or, ceci n'est (presque) pas possible en utilisant mod_ssl avec Apache. Toutefois, ceci est rendu possible via l'utilisation de mod_gnutls. Pour ceux qui ont CentOS 5, voici un petit lien pour l'installer facilement. je crois que mod_gnutls est aussi disponible pour Mandriva. Sinon, il reste à compiler les sources ;-)

Mise à jour : certains auront pu remarquer que des liens de ce billet ne fonctionnent plus, et que les dernières versions de mod_gnutls nécessitent une version de gnutls plus récente que celle livrée sur CentOS. La petite astuce ne fonctionne donc plus vraiment, sauf à utiliser une autre distribution ou à installer un gnutls plus récent. Un ami s'y est essayé il y a quelques temps sous Gentoo, un ebuild étant disponible.

Commentaires

Le 30/08/2011 00:55 par fakessh @

j ai dernierement package les dernieres versions de gnutls et mod_gnutls

je fournis les rpm source sur la page de mon blog recompiler les rpm et bonnes mises à jour

http://fakessh.eu/2011/08/28/last-release-gnutls-et-mod_gnutls-pour-centos-5-6/