Cryptographie

Qu'est-ce que c'est?

Plusieurs définitions importantes.

x509 : utilitaire OpenSSL permettant d'afficher ou de signer des certificats

-req : indique qu'on veut utiliser une demande de signature de certificat

-days <durée> : indique la durée de validité du certificat

-in <csr> : indique la demande signature de certificat qu'on utilise

-out <clé_priv> : indique le fichier de sortie dans lequel va être enregistrée le certificat signé

-CA <cert_ca> : indique le certificat de la CA qu'on utilise

-CAkey <clé_priv_ca> : indique la clé privée de la CA qu'on utilise

-CAcreateserial : créer le fichier de numéro de série de la CA, il n'est obligatoire que la première fois qu'on signe un certificat

•     Cryptographie : C’est la protection d’un message à l’aide d’une clé de chiffrement.
•     Cryptogramme : C’est un message chiffré auquel on a appliqué une technique de cryptographie.
•     Cryptanalyse : C’est la science qui consiste à tenter de déchiffrer un cryptogramme sans posséder la clé de chiffrement. Dans ce cas on peut alors parler de décryptage.
•     Cryptage, Crypter et encrypter : Ces mots sont des anglicismes qu'il est préférable de bannir de votre vocabulaire. Toutefois il est courant de les retrouver utilisés par des personnes qui font de la vulgarisation ou qui ne savent forcément pas très bien de quoi elles parlent.
•     Steganographie : La steganographie est l'art de cacher les informations. Il s'agit de passer inaperçu, souvent en faisant passer une information pour une autre. Par exemple, cacher du texte dans des images ou des mp3.
•     Encoder : Il s'agit ici de changer le format des données. Il n'y a rien de secret par ici. Un format souvent utilisé en sécurité et réseau est le Base64
•     Obfusquer : C’est le fait de rendre difficile à comprendre un message (typiquement du code informatique).L'objectif est de rendre laborieuse la compréhension du message.
•     Compresser : Enfin, les algoritmes de compression sont utilisés pour réduire la taille d'un message.

A quoi ça sert?

La cryptographie assure plusieurs services :

• Intégrité : S'assurer que les données n'ont pas été modifiées lors de leur transmission
• Confidentialité : S'assurer que l'information n'est accessible qu'aux personnes autorisées
• Authenticité : Vérifier l'identité d'une personne ou d'une machine

Comment fait-on?

Pour atteindre ces objectifs, on utilise plusieurs techniques de l'univers de la cryptographie :

• L'intégrité repose sur les fonctions de hachage
• La confidentialité repose sur le chiffrement des données.
• L'authentification se fait par aposition d'une signature numérique.

Le hachage

Une fonction de hachage est une fonction qui convertit un grand ensemble en un ensemble plus petit, appellé empreinte. Il est impossible de déchiffrer l'empreinte pour revenir à l'état d'origine; ce n'est donc pas une technique de chiffrement. Quelques exemples de fonctions de hachage connues : MD, SHA, SHA-1, SHA-2... Le hachage permet de s'assurer de l'intégrité des données : on pourra par exemple recalculer l'empreinte d'un fichier donné pour s'assurer que celui-ci est conforme, en la comprant avec une empreinte donnée.

Exemple de hachage d'un fichier :

justine@Justine-pc:~/Documents$ sha256sum lorem.txt
56293a80e0394d252e995f2debccea8223e4b5b2b150bee212729b3b39ac4d46  lorem.txt

 

Différents types de cryptographie

Il existe deux grandes familles d'algorithmes de cryptographie : symétrique et asymétrique. Chacune à ses utilités. On peut aussi les combiner à différents niveaux pour en tirer le meilleur parti, c'est la cryptographie asymétrique.

Cryptographie symétrique

On utilise des algorithmes symétriques qui sont publics, avec des clefs qui sont, elles, secrètes. Afin de pouvoir chiffrer et déchiffrer les données, tous les participants à la communication doivent partager la même clef secrète. Exemples connus : AES, IDEA, 3DES, Blowfish, etc... Comparée à sa consoeur, la cryptographie symétrique présente les avantages suivants :

• Simple à mettre en oeuvre
• Léger en consommation CPU
• Chiffrement robuste

L'inconvénient est cependant de taille :

• L'échange de clefs

En effet, si on envoie les clefs en même temps que le cryptogramme, on laisse les clefs sur la serrure...

Exemple en action ! Je repars du fichier lorem ipsum :

justine@Justine-pc:~/Documents$ openssl enc -e -a -nosalt -aes-256-cbc -in lorem.txt -out fichier.txt.enc

Détail de la commande :

• openssl : le programme en lui-même
• enc : On précise que l'on va faire du chiffrement symétrique
• -e : Indique que l'on va chiffrer (encrypt)
• -a : Permet d'indiquer qu'on veut la sortie en base64, sinon la sortie serait illisible
• -nosalt : Pas de sel (donc pas d'aléatoire) dans le chiffrement, on utilisera pas cet argument dans la réalité car le sel améliore la force du chiffrement
• -aes-256-cbc : Indique l'algorithme utilisé, ici AES256 en mode CBC
• -in le fichier en entrée
• -out la sortie

Pour le déchiffrement, on remplace -e (encrypt) par -d (decrypt):

justine@Justine-pc:~/Documents$ openssl enc -d -a -nosalt -aes-256-cbc -in fichier.txt.enc -out loremdecode.txt
justine@Justine-pc:~/Documents$ cat loremdecode.txt
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

 Cryptographie asymétrique

On utilise des algorithmes asymétriques publiques, avec une paire de clefs : une publique, et une privée. La particularité de ces algos est qu'un message chiffré avec une clef publique n'est lisible que par le propriétaire de la clef privée. Exemples connus : RSA, El Gamal, etc...

Les avantages :

• On peut communiquer depuis un canal non sécurisé

Les inconvénients :

• Complexité de mise en oeuvre
• Davantage consommateur en ressources
• Chiffrement moins robuste

Cryptographie hybride

Pour faire de la cryptographie hybride, on chiffre le contenu par chiffrement symétrique avec une clef de session aléatoire, et on chiffre la clef de session par chiffrement asymétrique avec la clef publique du destinataire. Exemples : PGP, TLS, etc.

Les avantages :

• Communication via un canal non sécurisé
• Consommation de ressources raisonnable
• Chiffrement robuste

Inconvénient :

• Une complexité encore plus grande.

La signature numérique

Grâce au hachage et à la cryptographie asymétrique, il est possible de signer numériquement des données. Pour ceci, on génère une empreinte des données à signer, et on chiffre ensuite cette empreinte avec notre clef privée. Cette empreinte chiffrée est la signature. Elle peut être apposée aux données, ou mise dans un fichier distinct. Cela nous permet de prouver auprès de toutes les entités qui possèdent notre clef publique que les données émises sont authentiques, puisque la clef publique permet de déchiffrer ce que l'on a chiffré avec la clef privée. Il n'y a plus qu'à recalculer l'empreinte pour voir si elle est identique.

Si les empreintes sont différentes, c'est que les données sont corrompues, ou qu'elles ont été modifiées.

Introduction aux infrastructures à clefs publiques

Nous allons ici voir comment fonctionne une ICP (Infrastructure à Clefs Publiques, ou PKI en anglais).

Terminologie

• Public Key Infrastructure (PKI) : Décrit la collection de fichiers et les associations entre les CA, les demandes, les paires de clés, et les certificats.
• Authorité de Certification (CA) : Tiers de confiance à la racine d'une PKI.
• Certificat : Un certificat est un fichier contenant une clé publique, plusieurs informations sur l'émetteur et le bénéficiaire du certificat et une signature numérique de l’autorité de certification.
• Demande de certificat : Ou demande de signature de certificat (CSR pour Certificate Signing Request). C’est une demande de certificat qui est ensuite envoyée à une CA pour être signée. Une demande contient les informations de certificat (nom, clé publique, etc.) signées numériquement grâce à la clé privée du demandeur.
• Paire de clés : Cryptographie asymétrique : la clé publique et la clé privée. La clé publique est incluse dans la CSR et dans le certificat.

La PKI

Il s'agit d'un ensemble de composants physiques, de procédures humaines et de logiciels permettant de gérer le cycle de vie des certificats. Elle fournit des garanties permettant de faire confiance aux autorités. Elle permet de mettre en oeuvre les moyens suivants :

• Confidentialité (chiffrement) : les données restent secrètes
• Authentification : des utilisateurs
• Intégrité : les données ne sont pas modifiées, et non-répudiation (l'émetteur ne peux pas dire que ses données ne sont pas à lui)

Elle agit au niveau du stockage et/ou du transport des données, et repose sur des outils de cryptographie (clefs symétriques, asymétriques, hachage).

La CA

Il s'agit d'un tiers de confiance permettant d'authentifier les utilisateurs. Elle délivre des certificats qui décrivent des identités numériques, et elle met à disposition les moyens de vérifier la validité des certificats.

Au coeur d'une PKI, elle est la plus sensible en matière de sécurité. Sa clef privée sert à signer tous els certificats émis, et du coup sa sécurité à elle met en jeu la sécurité de toute la PKI. Il est du coup recommandé de conserver sa structure sur un système sécurisé, séparée de l'entité finale demandeuse de certificats.

Lors de sa création, la paire de clefs de la CA est créée, ainsi que les fichiers nécessaires à la mise en oeuvre des certificats délivrés. Une fois créée, elle peut recevoir les demandes de certificats; les certificats d'entités sont destinés aux "consommateurs" de certificats X509, comme un client, un serveur VPN, etc... Les demandes et les certificats ne sont pas confidentiels et peuvent transiter par n'importe quel moyen; mais il vaut mieux vérifier que le certificat reçu correspond bien à celui envoyé, en comparant son empreinte avec celle fournie par l'expéditeur.

Exemples de CA publiques : LetsEncrypt, CAcert, StartSSL, Comodo...

L'avantage d'une PKI/CA est qu'on peut centraliser a gestion des clefs publiques; cependant, il faut faire confiance à tous les maillons de la chaîne. En effet, Une CA peut "certifier" d'autres "sous-CA", par exemple; Et si la sécurité de la CA root est mise en cause, c'est le cas de tout le reste de la chaîne. Les navigateurs web par exemple ont une liste de CA auxquelles ils font confiance, et dont ils ont les clefs publiques (pour pouvoir vérifier les certificats X509 auxquels ils sont confrontés); si une CA compromise se mets à délivrer des vrais-faux certificats, on aura un problème !

Une contre-mesure efficace est l'utilisation du protocole DANE, que l'on verra plus loin.

Paire de clefs, demande de certificat, et certificat

Les entités n'ont besoin que d'une clef privée et d'une demande certificat associée (mieux vaut prendre un bon mot de passe sur cette clef : si elle est volée, on peut se faire passer pour l'entité en question !). La clef privée ne doit jamais quitter le système de l'entité. Une fois la paire de clefs générée, la demande de certificat est créée et signée numériquement avec la clef privée. La demande est alors envoyée à une CA pour être signée et le certificat signé est retourné.

Le certificat est comme une carte d'identité. Il sert à identifier et authentifier une personne (physique/morale), et aussi à chiffrer des échanges. La signature du tiers de confiance atteste du lien entre l'identité physique et l'identité numérique. Le standard généralement utilisé est X509.

Pour résumer, un certificat veut dire : "Moi, CA untel (comme le prouve ma signature numérique), certifie que unautre (dont voici la clef publique), est bien celui qu'il prétend être".  Les clients peuvent ensuite vérifier la signature de la CA, et voir que la clef publique de unautre est bien la bonne.

Types de certificats

Il existe trois types de certificats : DV, OV,EV

• DV : Domain Validation. La validation par domaine est le niveau le plus élémentaires de la validation SSL. La CA vérifie que l'on est bien le porprio d'un domaine à l'aide d'un WHOIS. On a alors aucune informations sur l'entreprise dans le certif: on sait juste que la personne qui a demandé le certif possède bien le domaine en question. Utile si la sécurité n'est pas trop de mise, mais malheureusement exploitable pour du phishing par exemple, alié à du DNS squatting.
• OV : Organisation Validation. Nécessaire pour les entreprises et organisations quand un utilisateur doit rentrer des données sensibles (CB, etc). Ils sont notamment utiles pour les sites de commerce électronique ou les ventes en ligne. Un certificat OV authentifie le propriétaire du site et exige des informations commerciales légitimes relatives à l’entreprise concernée. La procédure de validation applicable à ces certificats est plus longue et plus précise. L’autorité de certification vérifie que vous êtes bien non seulement le propriétaire du domaine, mais également le propriétaire de l’entreprise. L’entreprise doit figurer dans la base de données du registre du commerce correspondant et dans un annuaire en ligne fiable (par exemple, dnb.com). Les fraudeurs ne peuvent pas obtenir un certificat OV parce que leur entreprise ou organisation ne peut pas être validée. Le principal avantage d’un certificat OV est que votre entreprise est indiquée sur le certificat.
• EV : Extended Validation. Niveau de sécurité le plus élevé. Lors de la vérification d'un certificat EV SSL, le propriétaire du site web se soumet à un processus de vérification d'identité complet et normalisé au niveau mondial (un ensemble de principes et de politiques de vérification ratifiés par le CA/Browser forum). Il doit prouver qu’il a les droits exclusifs d'utilisation d'un domaine, confirmer son existence légale, opérationnelle et physique, et prouver que l'entité a autorisé l'émission du certificat. Ces informations d'identité vérifiées sont incluses dans le certificat.

Comment une demande devient certificat...

Quand la CA a signé la demande de certificat, un certificat signé est produit. La clef privée de la CA est utilisée à ce moment pour signer la clef publique de l'entité finale : du coup, si on fait confiance à la CA, on fait confiance à l'entité. Le certificat signé est renvoyé à l'entité, il n'est pas confidentiel et peut être envoyé via n'importe quel canal.

Vérification d'un certificat délivré

La vérification peut se produire de deux façons :

• Seule une des extrémités de la communication doit être vérifiée (comme avec HTTPS, on vérifie uniquement le serv) : on parle d'authentification unilatérale.
• Les deux extremités sont vérifiées (un VPN, par exemple) : authentification "pair-à-pair".

Unilatérale

Le serveur a créé sa paire de clefs, envoyé sa demande à la CA, et reçu une copie en retour de son certificat signé (ainsi que celui de la CA). Elle peut alors s'authentifier auprès des clients faisant confiance à la CA. Le serveur n'as pas eu besoin d'échanger d'informations sensibles avec le client pour cela. Au cours du handshake TLS, le serveur présente sa chaîne de certificats au client, qui vérifie la validité des certificats reçus. Ensuite, le serveur prouve qu'il est vraiment lui en signant des données avec sa clef privée. Le client peut du coup valider la signature à l'aide du certificat (le serveur prouve qu'il a bien la clef privée relative à la clef publique du serveur dans le certificat).

Pair-à-pair

Les deux entités ont leur paire de clefs et leurs certificats signés, ainsi que celui de la CA. Elles peuvent donc s'identifier mutuellement sans avoir eu à s'échanger d'informations sensibles. Ensuite, c'est le même principe qu'en unilatéral, mais fois deux.

Au cours de la « poignée de main » (handshake) TLS, chaque côté de la connexion présente sa propre chaîne de certificats à l’extrémité distante. Chaque côté vérifie la validité du certificat reçu, contre sa propre copie du certificat de la CA. En faisant confiance au certificat racine de la CA, le pair auquel chacun est connecté peut être authentifié.

Ensuite, l’extrémité distante prouve qu’elle « est vraiment » l’entité identifiée par le certificat en signant des données à l’aide de sa propre clé privée. Seul le titulaire de la clé privée étant capable de réaliser cette opération, ceci permet à l’autre extrémité de vérifier la validité de la signature à l’aide du certificat récu préalablement et ainsi d’authentifier l’extrémité distante.

DANE/TLSA

Pour pallier aux attaques du type MITM ou au manque de confiance dans les CA, l'IETF à oncçu le protocole DANE. Il permet de publier dans le DNS (sécurisé avec DNSSEC) des enregistrements de type TLSA.

Une enregistrement TLSA peut indiquer/contenir la CA à interroger ou même le certificat en lui-même (ou son empreinte). Ainsi, un logiciel qui supporte TLSA/DANE peut vérifier à l'aide d'une requête DNS que les certificats présentés sont fiables.

Les avantages :

• Impose une contrainte sur la CA et évite les usuprations de certificats par une CA pourrie
• Permet même de se passer des CA en passant par les DNS

Malheureusement, il est peu supporté... Aucun navigateur ne le supporte nativement, alors qu'il permettrait de considérables avancées en matière de sécurité.

Fonctionnement de TLS (Transport Layer Security)

TLS, qui est le remplacant de SSL, est un protocole de sécurisation des échanges sur Internet. Dans la pile de protocole TCP/IP, il se situe entre la couche application et la couche transport TCP.

Une application utilisant TLS utilise un nouveau port (443 pour HTTPS au lieu de 80, par exemple). Certaines applications peuvent utiliser le même port gràace à StartTLS, on parle alors de "chiffrement opportuniste". La communication peut débuter en clair et passer en chiffré à l'initiative d'un des pairs ou des deux.

Lorsqu'un utilisateur se conncte à un site web via TLS, les étapes sont les suivantes :

1. Le navigateur demande une connexion sécurisée par TLS
2. Il se passe plusieurs choses avant et pendant cette "poignée de main" :
   1. Client et serveur se mettent d'accord sur le protocole et les suites de chiffrement à utiliser
   2. Si on utilise Diffie-Helman, ils s'échangent des nombres aléatoires pour calculer la clef de session
3. Le serveur envoie son certificat
4. Le navigateur vérifie le certificat auprès du CA
5. Le navigateur génère une clef de session, la chiffre et l'envoie au serveur
6. Le serveur déchiffre la clef de session avec sa clef privée
7. Connexion TLS établie : client et serveur échangent des donénes grâce à la clef de session
8. Une fois la connexion terminée/expirée, le serveur révoque la clef de session

Mise en place d'une authorité de certification et d'un serveur web HTTPS

Je pars de deux machines : une qui sera la CA et une qui sera un serveur web.

Autorité de certification

On génère une clef privée et un certificat qui y est lié sur le CA :

openssl req -newkey rsa:2048 -nodes -keyout clef.pem -x509 -days 365 -out certif.pem

• req : gestion de CSR (Certificate Signing Request) X.509
• -newkey rsa:2048 : on créée une clef
• -nodes : Si une clef privée est créée, elle n'est pas chiffrée
• -keyout : nom de la clef
• -x509 : On génère un certificat
• -days : durée de validité du certificat
• -out certif.pem : nom du certificat
• Attention à bien remplir les cases, surtout l'organisation, pour le retrouver facilement dans le navigateur !

Sinon, on peut le faire en deux fois (la meilleure méthode?):

openssl genrsa -out clefca.pem 2048
openssl req -new -x509 -days 365 -key clefca.pem > ca.crt

On peut voir le contenu du certificat :

openssl x509 -text -noout -in certif.pem

J'envoie ensuite le certificat sur mon PC (avec SCP ou autre...) puis je l'installe dans mon navigateur.

Dans Firefox :

• Préférences
• Vie Privée et sécurité
• Certificats > Afficher les certificats
• Importer

Demande de signature de certificat

Sur le serveur web :

On génère une clef privée :

 openssl genrsa -out clefweb.pem 2048

(on peut rajouter -des3 après genrsa pour y mettre un mot de passe)

Puis je créée une CSR (Certificate Signing Request) à partir de celle-ci :

openssl req -new -key clefweb.pem > demandeweb.csr

Je peux mettre un peu du bullshit pour tout ce qui est pays, province, etc... mais attentation au FQDN, à mettre le bon nom de site web !

J'envoie le csr vers mon CA.

Sur le CA:

On signe la CSR grâce à la clef privée de la CA, pour avoir un certificat signé :

openssl x509 -req -in demandeweb.csr -out certifweb.crt -CA ca.crt -CAkey clefca.pem -CAcreateserial -CAserial ca.srl

• Ici, les arguments semblent pour la plupart claire, sauf...
• -CAcreateserial et -CAserial génèrent un fichier "serial", un numéro de série, en gros. Obligatoire seulement la première fois.

Plus qu'à transmettre ce certificat signé au site web !

Mise en place de HTTPS

Sur serveur web

On va utiliser tout ça sur Apache. On commence par l'installer, puis on créée un vhost qui ne fonctionnera que en https, j'ai sécurisé du mieux que je pouvais...:

Apache:

<IfModule mod_ssl.c>
        <VirtualHost *:80>
                #On redirige le traffic http vers https
                Redirect permanent / https://web.assr.iutsf.org
        </VirtualHost>

        <VirtualHost *:443>
                #Le dossier de mon site
                DocumentRoot /var/www/test
        
                #Nom du site
                ServerName web.assr.iutsf.org

                #Les logs, par d�faut
                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                #On prendra en compte les fichiers .htaccess situ�s dans notre dossier de site
                <Directory /var/www/test>
                        AllowOverride All
                        Require all granted
                </directory>

                #On active SSL   
                SSLEngine on

                # Chemin du certificat et de la clef
                SSLCertificateFile      /home/vagrant/web_cert.pem      
                SSLCertificateKeyFile   /home/vagrant/web_priv_key.pem

                #Reglages SSL
                SSLProtocol All -SSLv2 -SSLv3
                SSLHonorCipherOrder On
                SSLCompression off

                #HSTS : On force l'utilisateur a utiliser https avec chiffrement (pendant 6 mois, pour tout le monde !)
                Header always set Strict-Transport-Security "max-age=15768000"
                
                #Suites Cryptograhiques
                SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA'
                

        </VirtualHost>
</IfModule>

Pour Nginx :

###On pourrait rajouter ce serveur dans un autre fichier pour rediriger
###les demande de http vers https

#server {                               #Serveur http; il ne sert qu'a tout renvoyer vers https
#
#        listen 80;
#        listen [::]:80;
#
#        server_name auth.google.fr;
#
#       return 301 https://auth.google.fr
#
#
#        }

server {                                #Serveur https
        listen 443 ssl;                 #On ecoute le port 443
        listen [::]:443 ssl;

        server_name auth.google.fr;     #Nom du site


        ###SSL

        #Clef et certificat
        ssl_certificate      /home/vagrant/google/certifgoogle.crt;
        ssl_certificate_key  /home/vagrant/google/cleffakegoogle.pem;

        #Securite TLS
        #On impose les suites de chiffrement du serveur
        ssl_prefer_server_ciphers on;

        #Protocoles SSL
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # not possible to do exclusive

        #Suites de chiffrement du serveur
        ssl_ciphers 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA';

        #HSTS : On force le traffic en https
        add_header Strict-Transport-Security max-age=15768000; # six months


        ###Fichiers

        #dossier du site
        root /var/www/fakegoogle/;

        #Fichiers d'index possibles
        index index.php index.html index.htm index.nginx-debian.html;

        #Renvoie la page de 404
        location / {
                try_files $uri $uri/ =404;
        }

        #Configuration de php
        location ~ \.php$ {
               include snippets/fastcgi-php.conf;
               fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        }
}

Recommandations en matière de cryptographie

Le document suivant contient des configurations recommandées.

https://bettercrypto.org/static/applied-crypto-hardening.pdf

Rapidement analyser une liste de machines pour voir les dates de certifs

<source> for i in $(cat serveurs); do echo "$i $(curl --insecure -vvI https://$i 2>&1 | grep expire)" ; done </source> Où serveurs est une liste de FQDN ligne par ligne

CT : Certificate Transparency

Source Source 2 Source 3 : précertificats

La transparence des certificats (CT) est un standard de la sécurité Internet et un framework open-source permettant de superviser et auditer les certificats numériques. Ce standard créée un système de logs publics, dont le but est d'enregistrer tous les certificats fournis par des autorités publiques, le tout afin d'identifier facilement les certificats attribués par erreur ou pour de mauvaises intentions.

Pour résumer : c'est un réseau de machines, servant à loguer de façon ouverte (ie, accessible à tout le monde) toutes les opérations concernant les certificats.

Ce processus est décrit dans la rfc 9162. Depuis 2021, c'est obligatoire pour tous les certificats TLS publics. Il permet donc de repérer facilement les certificats frauduleux et de se passer de communications à part, comme avec le procole OCSP (dont j'ai déjà parlé ICI).

Le processus est très bien détaillé ICI

CT Logs

La CT dépend des véritables logs. Une nouvelle entrée de log ajoute les nouveau certificats à un "Merkle hash tree" (une structure en arbre donc chaque nouvelle branche est validée par les précédentes via des hashes, en gros). Pour être correct, un log doit :

• Vérifier que chaque certificat ou pré-certificat possède une chaîne de signatures valide
• Refuser de publier un certificat sans cette signature
• Stocker l'entièreté de cette chaîne
• Présenter cette chaîne sur demande

Une entrée de log peut accepter les certificats pas encore valides ou périmés.

CT monitors

Les CT monitors agissent comme des clients des serveurs de log. Ils vérifient les logs pour s'assurer que ceux-ci fonctionnent normalement, et peuvent par exemple être utilisés pour surveiller les certificats d'un domaine en particulier.

CT auditors

Ils agissent aussi comme des clients; leur but est de vérifier des informations partielles qu'il possèdent.

Outils

Outils pour interroger les logs CT

• crt.sh
• https://certstream.calidog.io/ (Avec les logs en temps réel, pas mal)
• https://ct.cloudflare.com/ Merkle town, des graphiques issus des logs par CloudFlare
• Google a sa propre interface

Liste des CT monitors existants

https://certificate.transparency.dev/monitors/

Commandes diverses

Voir le certificat d'un serveur en connexion directe

openssl s_client -showcerts -servername vhost.domain.tld -connect host.domain.tld:443 2>/dev/null | openssl x509 -inform pem -noout -text

Créer un certificats avec des alias via un fichier

Créer une clef privée.

Créer un fichier "csr.txt" du type:

[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C=US
ST=New York
L=Night City
O=Best websites, Inc.
OU=IT
CN = site.best.nc 

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = siteeee.best.nc

Créer le csr:

openssl req -new -key private/best_key.key -config csr.txt > best.csr