Bonjour Emmanuel, Bonjour à tous,
Le 13/02/2019 à 23:11, Emmanuel Rens a écrit :
En surfant un peu sur le blog de S. Bortzmeyer j'ai trouvé le moyen de télécharger un certificat de github.com par openssl et de le charger dans Iceape, pourtant - malgré des algorithmes communs (sha256 with RSA - mais pas AES?), le navigateur continue à arguer du contraire. Il me semble pourtant que je vais dans la bonne direction. Qu'en penses-tu?
Il est possible que j’interprète de travers ce que tu écris, mais j'ai du mal à saisir où tu as importé ce certificat et de quel certificat il s'agit.
Une des fonctionnalités de l'infrastructure X.509 est justement de décharger l'utilisateur du besoin de configurer à la main sa connexion sécurisée avec tel ou tel serveur. Il ne devrait donc a priori pas être nécessaire de télécharger quoi que ce soit pour se connecter à github ou à tout autre, avec un canal de communication chiffré.
Par ailleurs, si ça "ne marche pas" alors que certains algorithmes sont restés inchangés (MD5 a été écarté définitivement au 31 décembre 2016, tandis que SHA256 reste d'actualité), ça peut-être parce que Lenny supporte des versions de protocoles de communication (SSL, TLS, etc.) qui ne sont plus acceptés, et ne supporte pas les plus récentes, qui les ont depuis remplacés.
Comme tu utilises cette Debian Lenny en divertissement, son adaptation pour y faire tourner une implémentation plus récente de SSL n'est peut-être pas autant nécessaire qu'on le croit. Si c'était un serveur, il faudrait mettre à jour openssl et ses dépendances. Mais si tu te limites à l'utilisation de la machine pour consulter le web, il suffit finalement peut-être qu'un seul navigateur moderne fonctionne, pas beaucoup plus.
Évidemment, tout se tient dans une distribution, et tricoter du neuf avec du vieux est tout un art. Mais je me demande si on ne peut pas compiler un navigateur qui soit "stand alone", c'est à dire qui utilise au minimum les ressources du système d'exploitation, et ne s'inquiète donc pas qu'elles soient obsolètes, parce que de toute façon, il les intègre déjà dans son propre code et ne dépend pas de celles de l'OS.
J'ai en tête l'exemple de Chrome, qui a longtemps intégré Flash player d'Adobe, ce qui lui permettait d'afficher des vidéos dans ce format, même sur les systèmes sur lesquels Flash n'avait volontairement pas été installé. Évidement, un truc comme ça ne réutilise pas les bibliothèques partagées, mais dans ton cas, ce serait un atout.
Tout ça est théorique, il faudrait passer du temps à regarder en détail pour être plus concret.
Une autre pensée me vient en lisant Bortzmeyer: le cryptage X.509 n'est en fin de compte pas moins sûr que les méthodes actuelles. Est-ce correct?
X.509 n'est pas à proprement parler une méthode de chiffrement, mais plutôt une infrastructure à clé publique, c'est à dire un ensemble de standards techniques permettant à des applications hétéroclites d'établir entre elles des canaux de communication sûrs, parce qu'elles s'échangent de la même manière des certificats. X.509 définit strictement la structure des certificats, mais laisse le choix des algorithmes utilisés pour signer et chiffrer; quand aux protocoles de communication eux-même (SSL, TLS), à ma connaissance, ils ne sont pas définis par X.509, mais plutôt utilisent X.509.
-- Frédéric Dumas [email protected] _______________________________________________ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
