Discussion :

[petitours]

Bonjour

Je tente de combler mes lacunes concernant les certificats en général et le TLS en particulier.
Après des heurs de lecture je comprends de mieux en mieux les principes mais je bute complètement sur un maillon important du schmilblick : la validation de la confiance de l'AC.
partout je lis que le client SSL "possède une liste de certificat d'AC de confiance", OK mai
>>D'où sort cette liste de CA de confiance ?
>>Comment son intégrité est elle garantie ?ne suffit il pas de mettre un petit fichier qui va bien au bon endroit pour dire que n'importe quelle signature est "de confiance" ?
>>Si je dois échanger en SSL entre une machine A (qui fait tourner un service client de ma conception) et une machine B (qui fait tourner un service serveur de ma conception) et que B possède un certificat auto signé, comment puis-je faire admettre ce certificat comme étant de confiance ?


Si mes questions sont trop vagues et si ça peut aider mon "monde" est essentiellement windows...

Un peu dans le même registre de la validation du certificat serveur je suis intrigué par le risque d'attaque "man in the middle"
>>Le client doit vérifier que le nom de domaine présent dans le certificat serveur correspond bien au nom de domaine du serveur. Mais si le hacker choppe le certificat du serveur pour le passer ensuite au client, quel mécanisme l’empêche de filer au client des informations qui satisferont ce test ?



Petite question subsidiaire concernant la durée de validité du certificat :
>> à part risquer une panne (certificat obsolète) et faire du cash pour les CA qui les re-fournissent (à des prix exorbitants de ce que j'ai vu), ça sert à quelque chose ? J'ai lu que si le certificat était compromis ça servait à limiter dans le temps l'exposition... mais un hacker qui fracture un certificat d'une durée de vie de plusieurs mois ou années a tout le temps qu'il veut pour faire tout ce qu'il veut ; il faudrait une durée de vie de quelques secondes pour empêcher le hacker de faire ce qu'il a à faire...non ?

Merci par avance pour vos lumières

[jopopmk]

Salut,

je vais tenter de répondre à tes questions avec mes faibles connaissances.
N'hésite pas à ... attendre les réponses d'autres contributeurs

>> D'où sort cette liste de CA de confiance ?
Dans l'absolu c'est l'application qui décide à quels AC il fait confiance.
Dans les faits je crois que pas mal d'appli s'appuient sur une liste commune d'AC.

>> Comment son intégrité est elle garantie ?
Les AC sont officialisées après une brouettée d'audits stricts et onéreux pour vérifier qu'on peut leur faire confiance.
L'AC qui certifira l'assoç clé/identité apposera sa signature avec sa clé privée.
Il suffira alors à l'appli de vérifier cette signature avec la clé publique fourni à tous par l'AC.
Pour finir l'appli contact l'AC pour voir si ce certif n'a pas été révoqué.
AC de confiance > signature de l'AC validée > check révocation > ayez confiaaaaaance !

>> Comment puis-je faire admettre ce certificat comme étant de confiance ?
Alors là, ça va un peu dépendre de comment tu gères les certif, y'a peut-être une astuce à trouver.
De plus je suis pas familier avec les fonctionnalités proposées par le framework .NET à ce sujet.

>> Quel mécanisme l’empêche de filer au client des informations qui satisferont ce test ?
Si quelqu'un chope ton certif server alors il faut le faire révoquer par ton AC.
Maintenant n'oublions pas que l'idée est de chiffrer un message, et le méchant pirate n'a pas la clé privée.

>> Ça sert à quelque chose [un certif] ?
Certifier une identité.

PS1 : si le coût te chagrine regarde du côté de Let's Encrypt (ça peut aussi aider pour ta 3ème question : avec un certif associé à un vrai CA tu peux conserver la méthode de check d'origine pour être sûr que B est bien B).
PS2 : un certif peut-être révoqué pour différentes raisons, pas uniquement après sa période de validité.

[petitours]

Merci pour la réponse

>> D'où sort cette liste de CA de confiance ?
Dans l'absolu c'est l'application qui décide à quels AC il fait confiance.
Dans les faits je crois que pas mal d'appli s'appuient sur une liste commune d'AC.

oui sous windows on y accède avec MMC https://fr.wikipedia.org/wiki/Micros...gement_Console
Il y a une banque de CA dit de confiance.
Ma question c'est d'où Microsoft sort cette liste et dans les autres , comment aller y coller mon propre certificat à l'installation.

Pour finir l'appli contact l'AC pour voir si ce certif n'a pas été révoqué.

donc pour que ça marche windows a un mécanisme qui va tout seul comme un grand consulter les CA et des banques de CA de confiance sur le Web ?
Et si la machine n'a pas accès à internet ? (dans mon cas c'est des machines qui parlent régulièrement que sur des réseaux locaux)
Et comment elle se connecte à internet pour vérifier que le certificat est pas révoqué ? avec un autre certificat lui même vérifié auprès d'un autre CA grâce à une connexion via un certificat lui même vérifier auprès d'un autre CA dont le certificat est vérifié auprès d'un autre....

>> Quel mécanisme l’empêche de filer au client des informations qui satisferont ce test ?
Si quelqu'un chope ton certif server alors il faut le faire révoquer par ton AC.
Maintenant n'oublions pas que l'idée est de chiffrer un message, et le méchant pirate n'a pas la clé privée

dans le cas du Man in the middle je parlais du fait que le hacker écoute ce qu'envoi le serveur et le redonne au client pour lui faire croire que personne est sur la ligne. Qu'est ce qui empêche le hacker de faire en sorte que le certificat serveur qu'il retransmet vers le client soit accepté par le client (nom certificat = hostname du hacker) ? C'est le fait qu'il n'a pas la clef privée ce qui l’empêche de modifier le certificat sans perdre la cohérence de sa signature ?

>> Ça sert à quelque chose [un certif] ?
Certifier une identité.

Ce n'est pas l’intérêt du certificat ma question c'est l’intérêt de sa durée de vie. A part avoir une durée de vie très courte (quelques secondes), je ne vois pas du tout son intérêt et je ne trouve pas d'explication là dessus (à part des mauvaises langues qui parlent de pompe à fric, ce que je vais finir par croire )

PS1 : si le coût te chagrine regarde du côté de Let's Encrypt (ça peut aussi aider pour ta 3ème question : avec un certif associé à un vrai CA tu peux conserver la méthode de check d'origine pour être sûr que B est bien B)

je regarde...

Merci

[Jimmy_]

Ma question c'est d'où Microsoft sort cette liste et dans les autres , comment aller y coller mon propre certificat à l'installation.

Ce sont des entreprises qui ont demandé à Microsoft pour y être, après une grosse enquête, Microsoft les a accepté.
Tu peux y ajouter ton certificat à la liste mais que localement.

donc pour que ça marche windows a un mécanisme qui va tout seul comme un grand consulter les CA et des banques de CA de confiance sur le Web ?
Et si la machine n'a pas accès à internet ? (dans mon cas c'est des machines qui parlent régulièrement que sur des réseaux locaux)
Et comment elle se connecte à internet pour vérifier que le certificat est pas révoqué ? avec un autre certificat lui même vérifié auprès d'un autre CA grâce à une connexion via un certificat lui même vérifier auprès d'un autre CA dont le certificat est vérifié auprès d'un autre....

Non pas tout à fait, pas besoin d'internet, sauf pour la révocation.
Ca dit juste : ma machine à confiance dans cette liste de certificat. Si vous voulez me parler vous devez y être ou être signé par l'un d'eux.

Imagine que je suis un méchant pirate et j'essai de te faire aller sur mon site google contrefait. Je vais te présenter un certificat signé, toi tu vas consulter ta liste et tu verras que ma signature est fausse, donc je ne peux pas me connecter chez toi.

dans le cas du Man in the middle je parlais du fait que le hacker écoute ce qu'envoi le serveur et le redonne au client pour lui faire croire que personne est sur la ligne. Qu'est ce qui empêche le hacker de faire en sorte que le certificat serveur qu'il retransmet vers le client soit accepté par le client (nom certificat = hostname du hacker) ? C'est le fait qu'il n'a pas la clef privée ce qui l’empêche de modifier le certificat sans perdre la cohérence de sa signature ?

Oui

Ce n'est pas l’intérêt du certificat ma question c'est l’intérêt de sa durée de vie. A part avoir une durée de vie très courte (quelques secondes), je ne vois pas du tout son intérêt et je ne trouve pas d'explication là dessus (à part des mauvaises langues qui parlent de pompe à fric, ce que je vais finir par croire )

La durée de vie est un sujet à part en tière, disons qu'en sécurité tout est une question de temps pour se faire hacker. Qui peut garantir qu'au bout de 10 ans un certificat encore en RSA1024 ne soit pas compromis ? Personne, il vaut mieux en changer.
Pompe à fric , oui et non , la confiance a un prix , difficile de l'estimer.

Certains pseudo-gourou de la sécurité te diront qu'un certif SSL à 10€ est aussi sûr qu'un certif SSL à 1 Million. Au sens strict du terme oui.
Mais est-ce qu'une société low-cost pourra protéger ses certificats racines aussi bien qu'une boite plus riche avec plus de moyen ?
Pas si sûr ...
Car le jour ou un CA est piraté, c'est toute la pyramide de ses certificats qui est compromise.

[petitours]

Merci beaucoup pour ces explications et confirmations

Car le jour ou un CA est piraté, c'est toute la pyramide de ses certificats qui est compromise.

c'est le sentiment que j'ai eu en m'intéressant au mécanisme des certificats....Comme les feux rouges, le jour où la signalisation tombe en rade, tout le monde cartonne au milieu sans avoir regardé sur les cotés !
C'est l'art de faire confiance à des inconnus.

[yacinechaouche]

>>D'où sort cette liste de CA de confiance ?

Cette liste diffère d'un OS à un autre. Sous mageia par exemple, il y a une liste dans /etc/ssl/certs/ca-bundle.crt. Les navigateurs peuvent aussi avoir leur propres CA de confiance. Si on prend le cas de CACert par exemple il est accepté par certains mais rejeté par d'autres.

>> donc pour que ça marche windows a un mécanisme qui va tout seul comme un grand consulter les CA et des banques de CA de confiance sur le Web ?
Et si la machine n'a pas accès à internet ?

La vérification de non-révocation ne peut se faire que par Internet via le protocole OCSP (RFC6960). Le certificat désigne en général un serveur à consulter pour savoir si le certificat est révoqué ou pas.

>> Comment son intégrité est elle garantie ? ne suffit il pas de mettre un petit fichier qui va bien au bon endroit pour dire que n'importe quelle signature est "de confiance" ?

Tout à fait, mais c'est aussi ce qui permet aux certificats auto-signés de fonctionner car le CA racine créé à cet effet doit être ajoutée à cette liste.

>>Si je dois échanger en SSL entre une machine A (qui fait tourner un service client de ma conception) et une machine B (qui fait tourner un service serveur de ma conception) et que B possède un certificat auto signé, comment puis-je faire admettre ce certificat comme étant de confiance ?

1. Il suffit d'ajouter le certificat racine créé à partir de B à la liste des autorités de confiance de la machine A.
2. Quand la librairie SSL sera utilisée par l'application cliente pour vérifier votre certificat elle pourra remonter d'autorité en autorité jusqu'à ce qu'elle atteigne l'autorité racine que vous aurez péralablement ajoutée à la liste de confiance, rendant ainsi votre certificat valide.

>>Le client doit vérifier que le nom de domaine présent dans le certificat serveur correspond bien au nom de domaine du serveur. Mais si le hacker choppe le certificat du serveur pour le passer ensuite au client, quel mécanisme l’empêche de filer au client des informations qui satisferont ce test ?

Aucun; à supposer que le hacker arrive à avoir le même nom que le serveur, ce qui implique déjà peut être une attaque DNS réussie. Mais même en arrivant à se faire passer pour le serveur, l'attaque ne servira à rien puisque les communications ne pourront pas être décryptés car le hacker ne possède que le certificat, pas la clé privée qui, elle, est restée sur le serveur.

Petite question subsidiaire concernant la durée de validité du certificat :
>> à part risquer une panne (certificat obsolète) et faire du cash pour les CA qui les re-fournissent (à des prix exorbitants de ce que j'ai vu), ça sert à quelque chose ? J'ai lu que si le certificat était compromis ça servait à limiter dans le temps l'exposition... mais un hacker qui fracture un certificat d'une durée de vie de plusieurs mois ou années a tout le temps qu'il veut pour faire tout ce qu'il veut ; il faudrait une durée de vie de quelques secondes pour empêcher le hacker de faire ce qu'il a à faire...non ?

Ce qui ouvre aussi la question de savoir pourquoi nos documents d'identités (passeports, carte nationale) ont également une durée de vie ? si quelqu'un me vole mes papiers et se faisait passer pour moi la seule façon d'arrêter le massacre c'est de faire une déclaration de perte. Alors pourquoi une durée de validité sur ces documents ?

Imagine que je suis un méchant pirate et j'essai de te faire aller sur mon site google contrefait. Je vais te présenter un certificat signé, toi tu vas consulter ta liste et tu verras que ma signature est fausse, donc je ne peux pas me connecter chez toi.

Pour te faire passer pour google tu dois avoir leur certificat et arriver à leurrer le résolveur DNS de la machine cliente pour que, au niveau déjà du nom de domaine, tu sois bien google pour elle. Ensuite, comme dit précédemment pour l'attaque du MITM, si tu as le certificat de google le client va te valider sans problème car le certificat de google est signé par (exemple) VeriSign et VeriSigne est dans ta liste; c'est juste que tu ne pourras rien déchiffrer.

dans le cas du Man in the middle je parlais du fait que le hacker écoute ce qu'envoi le serveur et le redonne au client pour lui faire croire que personne est sur la ligne. Qu'est ce qui empêche le hacker de faire en sorte que le certificat serveur qu'il retransmet vers le client soit accepté par le client (nom certificat = hostname du hacker) ? C'est le fait qu'il n'a pas la clef privée ce qui l’empêche de modifier le certificat sans perdre la cohérence de sa signature ?

Oui

Pas tout à fait. Le hacker n'a pas besoin de modifier le certificat pour qu'il soit accepté. Donc non, rien ne l'empêche de se faire passer pour qui il souhaite une fois le cert obtenu.

Car le jour ou un CA est piraté, c'est toute la pyramide de ses certificats qui est compromise.

Certes, mais une révocation sur le CA = une révocation sur toute la pyramide aussi.