Sommaire
Si tu es en pleine session de dé/bug SSL/TLS, cet article peut t'éviter quelques désagréments ;-)
SSL Labs, l'incontournable
On ne le présente plus, le site de Qualys permet de tester la configuration de son serveur facilement avec une interface web bien faite. Le test permet d'avoir un rapport concernant les points suivants :
- Authentification : validité du certificat (nom du site, période de validité…),
- présence et validité de la chaîne de certificat (chain)
- Protocoles disponibles (SSLv2, SSLv3, TLS 1.0, 1.1 et 1.2),
- Cipher suites disponibles,
- Simulations de connexions avec de nombreux clients (Android, Firefox, IE, Java, Safari, …),
- détails (Forward Secrecy, HSTS, utilisation du protocole RC4, etc etc…).
Le tout avec des notes allant de A à F et les pistes à suivre pour améliorer sa connexion. Si vous ne l'avez pas encore fait c'est la première étape parfaite. À noter que SSL Labs permet aussi de tester son navigateur et fournit de la data sur l'écosystème HTTPS sur Internet.
Création d'un .csr et d'un .key
Pour créer une Certificate Signing Request (.csr) et une nouvelle clé privée (.key):
openssl req -sha256 -out /etc/ssl/private/exemple.csr -new -newkey rsa:2048 -nodes -keyout /etc/ssl/private/exemple.key
Détaillons (il parait que c'est mieux pour comprendre) :
-
req
: permet de créer et de gérer les CSR -
-sha256
: Vous avez normalement vue les annonces concernant le passage de SHA1 à SHA2. Pour l'inclure dans votre CSR (Certificate Signing Request), il suffit de rajouter l'option-sha256
à OpenSSL -
-out /etc/ssl/private/exemple.csr
: indique le fichier où sera enregistrée la CSR -
-new
: génère une nouvelle CSR et demande à l'utilisateur les valeurs qu'il souhaite -
-newkey rsa:2048
: crée une nouvelle clé privée, de type rsa et d'une taille de 2048 bits -
-nodes
: la clé privée n'aura pas de mot de passe -
-keyout /etc/ssl/private/exemple.key
: indique le fichier où sera enregistrée la clé privée
c'est pourquoi déjà ce certificat ?
Quand soudainement (enfin disons quelques temps plus tard), le drame ! Vous ne savez plus quel certificat fait quoi et pour qui, ou jusqu'à quand il est valide :
openssl x509 -text -in VotreCertificat.crt -noout
et les deux fichiers, là, ils vont ensemble ?
Pour la clé privée :
openssl rsa -noout -modulus -in server.key | md5sum
Pour le certificat :
openssl x509 -noout -modulus -in server.crt | md5sum
Si le résultat est le même pour les deux commandes, alors votre clé privée et votre certificat sont bien pour le même nom de domaine, avec les mêmes caractéristiques (validité…)
configuration SSL/TLS sous Apache2 :
Lors de la présence de plusieurs vhosts différents sur un même serveur Apache2, il arrive que l'on puisse avoir des résultats étranges dans les algos de chiffrement, par exemple la présence de SSLv3 alors que l'on a bien mis (et vérifié beauc… trop de fois) que l'on a bien SSLProtocol all -SSLv2 -SSLv3
dans sa configuration.
Il faut savoir que l'on peut mettre sa configuration SSL/TLS dans deux fichiers différents :
Le premier (/etc/apache2/mods-enabled/ssl.conf
) sera le choix par défaut pour l'ensemble des vhosts, alors que le second (/etc/apache2/sites-enabled
) concernera seulement le vhost pour lequel la configuration est présente dans son fichier de configuration. L'idée est donc de mettre la configuration générale dans ssl.conf
et les points de configuration propre à chaque vhost dans sites-enabled
(ou dans sites-enabled
selon votre configuration), comme les certificats ou encore HSTS (Strict-Transport-Security) avec lequel je vous conseille de faire TRÈS attention.
- configuration générale :
/etc/apache2/mods-enabled/ssl.conf
SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES:+HIGH:+MEDIUM
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
NOTE de non bas de page : mon extrémiste préféré pour le ssl/tls aeris vous propose cette configuration un poil extrême (mais ô combien efficace) à la place de la précédente :
SSLCipherSuite EECDH+AES:+AES128:+AES256:+SHA
- configuration propre à un vhost :
etc/apache2/sites-enabled/
(entre les balises<VirtualHost>
et</VirtualHost>
) :
SSLEngine on
SSLCertificateKeyFile /etc/ssl/private/libwalk.key
SSLCertificateFile /etc/ssl/private/libwalk.crt
SSLCertificateChainFile /etc/ssl/private/libwalk.chain
SSLCompression off
Header set Strict-Transport-Security "max-age=31622400
</VirtualHost>
.chain ? késako
La directive SSLCertificateChainFile d'Apache2 permet d'indiquer l'emplacement du fichier comportant les certificats chaînés (merci mozilla pour l'explication), c'est à dire votre certificat ET les certificats de votre CA (comme startssl, gandi, comodo).
Quand vous faites une requêtes (CSR) chez une CA, cette dernière, au moment de vous fournir votre certificat (.crt), vous indique (normalement) où se trouvent ses certificats à prendre dans votre cas.
Nous allons prendre comme exemple ici startssl vu qu'ils permettent d'avoir des certificats gratuits assez facilement. Une fois que j'ai fait ma requête via le formulaire en envoyant ma CSR et qu'ils m'ont fournit ma clé, je peux faire la manipulation suivante :
IMPORTANT : l'ordre dans le fichier doit commencer par le certificat le plus bas (nous), puis remonter progressivement vers le plus haut.
Imaginons que nous avons déjà notre clé privée (exemple.tld.key
) et notre certificat (exemple.tld.crt
) :
- télécharger le certificat intermédiaire de startssl :
wget https://www.startssl.com/certs/sub.class1.server.ca.pem
- puis le certificat root :
wget https://www.startssl.com/certs/ca.pem
puis on forge le certificat chaîné (ne pas oublier les 2 >>) :
cat exemple.tld.crt >> /etc/ssl/private/exemple.tld.chain
cat sub.class1.server.ca.pem >> /etc/ssl/private/exemple.tld.chain
cat ca.pem >> /etc/ssl/private/exemple.tld.chain
Et le tour est joué* \o/
si vous n'avez pas oublié de rajouter la ligne suivante dans le fichier de configuration de votre vhost :
SSLCertificateChainFile /etc/ssl/private/exemple.tld.chain
s_client
Permet de faire des tests grâce à un client SSL (cf wiki.openssl.org)
openssl s_client -servername www.libwalk.so -connect www.libwalk.so:443
Attention à ne pas oublier -servername
et le nom du site que vous voulez tester, sinon la commande prendra le certificat présenté par défaut sur le serveur (et donc pas forcément le bon…).
Exemple :
-
avec
-servername www.libwalk.so
openssl s_client -servername www.libwalk.so -connect www.libwalk.so:443
CONNECTED(00000003)
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
[...]
0 s:/description=clwEqu9Rv2hyAXKy/C=FR/CN=www.libwalk.so/emailAddress=postmaster@libwalk.so
-
sans
-servername www.libwalk.so
openssl s_client -connect www.libwalk.so:443
CONNECTED(00000003)
[...]
0 s:/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.octopuce.fr
Pour plus de précisions, vous pouvez lire "Using OpenSSL’s s_client command with web servers using Server Name Indication (SNI)" pour faire connaissance avec notre ami le SNI (Server Name Indication).
OpenSSL sur mon système :
openssl ciphers -v 'ALL:COMPLEMENTOFFALL'
Ce qui est activé par défaut (vous pouvez noter la présence des suites d'EXPort) :
openssl ciphers -v 'DEFAULT'
openssl ciphers -v 'ALL:!aNULL:!eNULL'
openssl list-cipher-commands
openssl list-message-digest-commands
Vous pouvez "créer" votre suite avec les critères suivants (algo de chiffrement, de hashage, d'authentification…), la question que vous allez poser devrait donc être "ok, mais on fait comment ?".
Note : vous pouvez à tout moment regarder ce que contient un ensemble d'algos avec la commande que l'on vient de voir. Si par exempke vous voulez voir ce que
EXP
contient, vous pouvez le faire avec la commandeopenssl ciphers -v 'EXP'
.
On prend tout (ALL
), on enlève les algos qui ne permettent pas ni l'authentification (!aNULL
), ni chiffrement (!eNULL
), on continue en enlevant !LOW
(chiffrement avec 56 ou 64 bits, la norme est de 128 bits de nos jours), les algos d'export (!EXP
) et l'algo RC4 (!RC4
) qui est considéré comme dangereux.
pour aller plus loin (mais vraiment très, très loin) :
- un seul livre à lire : l'inégalable "Bulletproof SSL and TLS" d'Ivan Ristić.
- mais sinon, en plus court et en gratuit, il y a openssl cookbook du même auteur, ainsi que "SSL/TLS Deployment Best Practices" (merci matlink pour le rappel).
# Précisions et corrections
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Il ne semble pas que ce soit nécessaire. En tout cas, chez moi, sans cette option et sans rien à ce sujet dans la configuration,
openssl req
me sort spontanément des signatures avec hachage SHA-256.C'est pour quoi, comme dans « pour quoi faire » : c'est une question sur la finalité d'une action ou d'un objet. C'est pourquoi, c'est une question sur la cause d'une action, et c'est inapplicable à un objet, qui peut avoir une finalité mais en aucun cas de cause.
À noter que cette commande, qui permet de décrire un certificat, a un équivalent avec une demande de signature de certificat :
Non. Ça ne sert à rien, de mettre le certificat racine, auto-signé, de l'autorité de certification. La chaîne de certification, fournie par le serveur au navigateur client, doit lui permettre de remonter jusqu'à un certificat racine, et deux cas se présentent :
Dans les deux cas, fournir le certificat racine au navigateur, dans la chaîne de certification, n'apporte rien du tout, en effet :
[^] # Re: Précisions et corrections
Posté par gouttegd . Évalué à 8.
Ça peut servir dans le cas où ce certificat est épinglé comme trust anchor dans un enregistrement TLSA de type DANE-TA (RFC 6698), pour que le navigateur puisse comparer le certificat racine envoyé par le serveur avec le condensat publié dans le DNS.
[^] # Re: Précisions et corrections
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Joliment observé, je n'avais pas pensé à ça. Ceci dit, aucun navigateur Web ne prend en charge DANE à ma connaissance, et étant donné l'état de fossilisation avancé du Web, je doute que ça arrive jamais de mon vivant.
[^] # Re: Précisions et corrections
Posté par gouttegd . Évalué à 7.
Aucun navigateur ne le prend en charge de base (ce qui est regrettable et probablement pas près de changer, malheureusement).
Mais l’extension DNSSEC/TLSA Validator permet d’ajouter cette prise en charge à Mozilla Firefox, Internet Explorer, Chrome/Chromium, Opera et Safari — et je ne sais pas pour les quatre derniers, mais ça fonctionne très bien pour Firefox.
(Et j’ai aussi un plugin de mon cru pour uzbl, mais il faut mettre les mains dans le cambouis.)
[^] # Re: Précisions et corrections
Posté par gouttegd . Évalué à 3.
Ça dépend des versions (et/ou peut-être des options à la compilation). Chez moi, c’est du SHA-1 par défaut avec OpenSSL 1.0.1p sur Slackware, mais SHA-256 par défaut avec OpenSSL 1.0.1k sur Debian…
Mais attention, ce n’est pas parce que la requête de certificat est signée sur un condensat SHA-256 que le certificat le sera forcément. C’est l’autorité de certification qui décide seule de l’algorithme de condensation qu’elle utilise pour signer le certificat : elle peut très bien utiliser SHA-1 même si la CSR a été générée avec SHA-256.
[^] # Re: Précisions et corrections
Posté par lejocelyn (site web personnel) . Évalué à 2.
C'est pour quoi, comme dans « pour quoi faire » : c'est une question sur la finalité d'une action ou d'un objet. C'est pourquoi, c'est une question sur la cause d'une action, et c'est inapplicable à un objet, qui peut avoir une finalité mais en aucun cas de cause.
Bon, je sais que ce n'est pas vraiment le cœur de la discussion mais au vu du ton péremptoire de cette affirmation, je me permets de revenir dessus. De mon côté, je dirais qu'un objet possède forcément une cause (à sa création ou fabrication) mais qu'il n'a une finalité que s'il a été fabriqué. De plus, répondre à la question pourquoi un objet a été fabriqué répond souvent à la question pour quoi un objet a été fabriqué, la cause et la finalité étant souvent très proche dans nos raisonnements. Les objets résultant d'un processus «naturel» ne sont pas liés à une finalité, à moins de croire au supernaturel ou au divin.
L'étape d'après : citations et exemples (voire terrain) et dissertation ;)
[^] # Re: Précisions et corrections
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Bon, ma remarque ne valait probablement pas grand chose lue sous un angle philosophique, j'étais plutôt sur le sujet de la langue française, où seuls des actions, des verbes donc, peuvent avoir une cause : on ne peut pas demander pourquoi un objet, seulement pourquoi un objet existe, par exemple. On peut demander à quoi il sert, mais ce n'est pas la même chose, notamment pour les objets détournés de leur fonction originale !
# SSLCertificateChainFile obsolète à partir d’Apache 2.4.8 + HPKP
Posté par gouttegd . Évalué à 9.
Juste une précision, la directive
SSLCertificateChainFile
est obsolète à partir d’Apache httpd 2.4.8. La chaîne de certificat(s) intermédiaire(s) doit désormais être concaténée à la suite du certificat du serveur dans le fichier indiqué par la directiveSSLCertificateFile
.À part ça, on peut (doit ?) considérer aussi l’utilisation de HPKP (épinglage des clefs publiques dans les en-têtes HTTP, RFC 7469). Il suffit d’une ligne supplémentaire (ici, toujour pour Apache httpd) :
Le condensat d’une clef peut s’obtenir ainsi :
Attention, l’épinglage d’une clef de secours n’est pas optionnel : le RFC 7469 dit clairement qu’un navigateur doit ignorer tout en-tête HPKP qui ne mentionnerait pas de clef de secours.
[^] # Re: SSLCertificateChainFile obsolète à partir d’Apache 2.4.8 + HPKP
Posté par ohm . Évalué à 0.
Attention, tu ne peux pas mettre de commentaire après la barre oblique inverse, si tu veux échapper un retour à la ligne, il faut obligatoirement un EOL juste après.
# Question sur s_client
Posté par chimrod (site web personnel) . Évalué à 2.
Merci pour le journal,
J'en profite pour faire part d'un problème rencontré derrière un serveur proxy. s_client ne semble pas respecter les variables d'environnement HTTP_PROXY et HTTPS_PROXY. J'ai pu contourner le problème en ouvrant la connexion vers le serveur à travers le proxy, puis laisser la main à s_client pour tester la validité, mais ça n'est pas vraiment très simple..
Est-ce qu'il me manque quelque chose ou bien bien est-ce un manque dans l'appli ?
[^] # Re: Question sur s_client
Posté par gouttegd . Évalué à 3. Dernière modification le 21 juillet 2015 à 15:50.
s_client
n’a effectivement aucun support pour HTTPS_PROXY. Ce n’est pas très étonnant si on considère que c’est un client TLS générique, alors que HTTPS_PROXY (comme son nom l’indique) est spécifique à HTTPS.Une option
-proxy host:port
a été ajoutée à la version de développement il y a quelques semaines.# Autre outil intéressant
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
testssl.sh, disponible sur https://testssl.sh/.
Remarque : à compiler sur un OpenSSL brut de décoffrage !
# LibreSSL
Posté par Emmanuel C . Évalué à 5.
Qu'en est-il de libre ssl ? et de la qualité du code d'openssl ?
# SNI / Multiple certificat
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Pendant longtemps, cela n'a pas marché d'avoir plusieurs certificats mais j'ai fait un essai il y a un mois de cela et cela fonctionne très bien (sauf avec les vieux navigateurs mais on s'en fiche).
Pour avoir un certificat par virtual host par exemple, il suffit de mettre en global la directive
Et c'est tout ! Dans chaque virtual host, on peut ensuite mettre des certificats différents avec les directives classiques SSLCertificateFile, SSLCertificateKeyFile et SSLCertificateChainFile…# Multiple certificate / Only SNI https client
SSLStrictSNIVHostCheck on
[^] # Re: SNI / Multiple certificat
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Euh non. Cette variable de configuration, c'est pour interdire aux clients non SNI d'accéder à un hôte virtuel par nom en TLS.
Pour activer le SNI, c'est en fait le NameVirtualHost *:443, sous Apache 2.2.
[^] # Re: SNI / Multiple certificat
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Si ton client est non SNI, il ne peut pas accéder aux différents certificats. Donc si on veut avoir plusieurs certificats et que cela marche, il faut bien limiter aux seuls clients SNI ?
[^] # Re: SNI / Multiple certificat
Posté par kna . Évalué à 3.
Si le client supporte le SNI, dans tous les cas il recevra bien le certificat correspondant au servername qu'il a demandé.
Si le client ne supporte pas le SNI
- avec SSLStrictSNIVHostCheck no (par défaut), il recevra le certificat du vhost TLS par défaut.
- avec SSLStrictSNIVHostCheck yes, il est rejeté
# Avoir une meilleure note
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Afin de limiter le protocole SSL/TLS, supprimer les trucs moyens et avoir une bonne note au test Qualys, voila un début de configuration pour Apache. Si vous avez des recettes de meilleures qualités et facilement maintenables, c'est le moment de les partager.
SSLEngine On
SSLHonorCipherOrder On
SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1
SSLCipherSuite HIGH:MEDIUM:!DH:!aNULL:!RC4
[^] # Re: Avoir une meilleure note
Posté par chimrod (site web personnel) . Évalué à 4.
Le wiki de mozilla contient une page sur la configuration ssl à appliquer :
C'est une bonne référence.
[^] # Re: Avoir une meilleure note
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
En pratique, je ne suis pas si éloigné. Je garde ton lien dans un coin. Je spécifie les protocoles alors que Mozilla les accepte tous sauf et pour les ciphers, je fais l'inverse ;-) Ceci dis, la liste des ciphers à la Prévert, je trouve cela difficilement maintenable.
[^] # Re: Avoir une meilleure note
Posté par AgentSteel (site web personnel) . Évalué à 1.
J'aime bien cet article de blog, qui est aussi régulièrement mis à jour
https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# Un bonne source deconfiguration
Posté par ianux (site web personnel, Mastodon) . Évalué à 3.
https://cipherli.st/ propose des conf SSL blindées pour les principaux serveurs web ansi que d'autres softs tels que Postfix ou Dovecot.
[^] # Re: Un bonne source deconfiguration
Posté par Framasky (site web personnel) . Évalué à 2.
Il y a aussi https://bettercrypto.org qui est une vraie mine d'or. Serveurs web, mail, xmpp, ssh, routeurs, switchs (cisco et juniper de mémoire). Mis à jour selon l'actualité (genre la faille sslv3, etc)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# HSTS
Posté par rzx . Évalué à 2.
Pourquoi ? Je serais intéressé d'avoir plus de détails.
[^] # Re: HSTS
Posté par claudex . Évalué à 4.
Parce que si tu l'active sur un site où tu ne devrais pas (parce qu'il n'y a pas de certificat valide, parce le serveur n'écoute pas sur le 443…), tu vas avoir de gros problème avec tes utilisateurs parce qu'il n'est pas possible de le désactiver avant la fin du TTL spécifié (qui peut valoir plusieurs mois).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.