Ce journal pour réagir à deux actualités récentes concernant SSL (mais sans aucun rapport l'une avec l'autre).
1) Les impôts
=========
Pour payer ses impôts en ligne, il faut utiliser une applet Java qui se charge se signer la déclaration et de chiffrer la transmission. Et naturellement, ça marche presque bien, presque partout... ou pas du tout, selon les gens. Et puis il faut que l'application soit signée, et patati, et patata.
Mais quand je lis, ici même, des gens qui affirment que « oui, ma bonne dame, c'est vrai que c'est malheureux ce trouc Java qui marche que pouic, mais c'est un mal nécessaire, SSL c'est juste pour le chiffrement, pas pour l'authentification » alors là, je dis STOP !
Oh, les mecs, faut se renseigner un peu : l'authentification mutuelle basée sur SSL, c'est un truc standard, ça marche vachement, et miracle, c'est portable à 100%, partout, indépendamment de la plate-forme. Magique. Deux liens (en anglais) pour ceux qui voudraient des détails : [http://en.wikipedia.org/wiki/Mutual_authentication] et [http://www.freebsddiary.org/openssl-client-authentication.ph(...)].
En pratique, comment ça marche ? Le scénario idéal : le contribuable génère un couple de certificats (publique/privé), il se connecte de manière chiffrée sur un serveur officiel où il soumet son certificat (publique) et des informations d'identification, et on lui renvoie le certificat signé. A partir de ce moment-là, il utilise ce certificat pour se connecter sur le site des impôts, où il est identifié formellement. Signature, chiffrement, tout en un !
Le scénario réel : comme c'est pas évident de faire générer le certificat par l'utilisateur (et puis il pourrait avoir une version non fiable de OpenSSL, qui sait ;-) ), c'est le serveur officiel qui génère le couple de certificats et envoie les deux à l'utilisateur (sur une connexion chiffrée). C'est un poil moins sécurisé, mais à peine. Au pire, on distribue une application qui tourne partout et qui sait générer des certificats (ça s'appelle OpenSSL par exemple, y'a qu'à coller un clickodrome dessus). Et Java signé de mes fesses, poubelle !
2) L'EEE PC
=======
Tout le monde a entendu parler de la faille OpenSSL qui affecte Debian et ses dérivés. Et bien dans les dérivés, il y a Xandros. La distribution fournie par défaut avec l'EEE PC d'Asus. A ce jour, je n'ai trouvé aucun avertissement de sécurité, et il n'y a pas de mise à jour sur le site d'Asus. A vrai dire, je n'ai même pas trouvé de liste de diffusion relative à la sécurité pour le Xandros upstream.
J'ai pas trop de conclusion sur la question, sinon que ça fait chier. Merci de votre attention, vous pouvez retourner hacker le serveur des chinois du FBI.
Journal SSL : impôts et EEE PC (en vrac)
15
mai
2008
# entretiens
Posté par jemore . Évalué à 3.
# Certificats
Posté par BabsOmatic . Évalué à 3.
Pour la génération du certificat, il existe une fonction sous firefox et un composant active X pour IE qui permet de faire générer une clef au client et de la faire ensuite signer par le serveur.
Ce système est utilisé notamment dans les banques (HSBC par ex), les organismes de certifications (Thawte, Verisign) et surtout CACert (projet de certification sur le principe du Web of Trust, et dont les sources sont disponibles histoire de jeter un coup d'oeuil / cacert.org ).
En pratique donc, le client clique sur 3 liens et il se met en place un système d'authentification mutuelle, basé sur du SSL :)
[^] # Re: Certificats
Posté par Boa Treize (site web personnel) . Évalué à 1.
Je crois que c'est ce que font les impôts. Je ne crois pas qu'ils ont ta clé privée, le couple clé privée / clé publique a donc été créé sur ton poste, puis ta clé publique a été signée par eux, ce qui forme ton certificat, qu'ils te remettent à la fin de la procédure.
[^] # Re: Certificats
Posté par Éric (site web personnel) . Évalué à 2.
# Justement
Posté par Éric (site web personnel) . Évalué à 6.
Justement, comme les navigateurs ne proposent pas tous de choisir correctement le certificat client, ils ont fait une appli qui gère la communication ssl avec un certif client. Oh, ils l'ont faite en java, comme ça ça tourne dans le navigateur de manière transparente pour le client.
Ben ouais, autant je suis d'accord pour dire qu'une partie de leur bouzin n'a ni queue ni tête, autant c'est pas tout incohérent non plus ;)
[^] # Re: Justement
Posté par ndesmoul . Évalué à 6.
MrLapinot propose d'installer Openssl, qui est certes portable mais qu'il faut tout de même installer et intégrer au navigateur. Je crois qu'il serait bon qu'il se renseigne lui-même un peu sur le fonctionnement de cette applet :)
Bien sûr que le protocole ssl permet l'authentification mutuelle. Mais la gestion des certificats clients au niveau des navigateurs n'est pas facile à gérer. D'autre part l'applet Java ne sert pas qu'à ça:
- le formulaire fait partie intégrante de l'applet et l'applet est signée donc tu es certain que l'appli n'a pas été modifiée par des tiers
- elle sert à signer numériquement ta déclaration et non ssl c'est pas fait pour ça! Je sais que certains protocoles d'authentification peuvent faire usage de schémas de signature, mais c'est pas ce "type" de signature qu'on veut.
- elle génère un pdf de ta signature
Bref la signature n'est qu'une des fonctionnalités de cette applet.
De plus avec l'applet, rien à installer côté client. Ca fonctionne quel que soit le navigateur et l'OS (à quelques exceptions près). C'est quoi le plus simple? Il y en a qui ont peut-être des soucis avec cette applet mais ces problèmes seront certainement prochainement corrigés. Pour ma part ça a fonctionné comme un charme (façon de parler quand on parle d'impôts!).
Le seul truc critiquable c'est la manière dont on te fournit le certificat puisqu'il suffit d'avoir accès à la feuille de déclaration de l'année précédente pour avoir toutes les données nécessaires. Mais l'utilisation d'OpenSSL n'y changerait rien!
Oh, et un "couple de certificats (publique/privé)" n'a aucun sens. Un certificat est par définition publique, et contient une clé publique. La clé privée correspondante n'en fait pas partie.
[^] # Re: Justement
Posté par MrLapinot (site web personnel) . Évalué à 3.
MrLapinot propose d'installer Openssl, qui est certes portable mais qu'il faut tout de même installer et intégrer au navigateur. Je crois qu'il serait bon qu'il se renseigne lui-même un peu sur le fonctionnement de cette applet :)
Tout à fait, j'aurais dû me renseigner plus avant sur le fonctionnement. Par contre, quand je disais d'installer SSL, ce n'était qu'un exemple de solution. Comme je l'ai dit, on peut aussi imaginer que le certificat soit généré directement sur le serveur, voire en utilisant les fonctions dédiée des navigateurs (comme évoqué dans un autre commentaire). Et ce qui me faisait surtout réagir, c'est que j'ai vu/entendu plusieurs personnes dire que SSL ne permettait pas de faire d'authentification.
Mais la gestion des certificats clients au niveau des navigateurs n'est pas facile à gérer.
En quoi l'applet change quoi que ce soit ? De ce que j'en ai vu (de loin et dans Firefox), le certificat est intégré au gestionnaire de certificats de Firefox, et c'est Firefox qui demande le mot de passe, non ?
Ensuite, pas du tout d'accord avec la suite :
D'autre part l'applet Java ne sert pas qu'à ça:
- le formulaire fait partie intégrante de l'applet et l'applet est signée donc tu es certain que l'appli n'a pas été modifiée par des tiers
Si tu es connecté en SSL, tu reçois les pages web (des formulaires tout ce qu'il y a de plus classique) sur une connexion sûre. Tu es également certain qu'ils n'ont pas été modifiés.
- elle sert à signer numériquement ta déclaration et non ssl c'est pas fait pour ça! Je sais que certains protocoles d'authentification peuvent faire usage de schémas de signature, mais c'est pas ce "type" de signature qu'on veut.
Franchement, si tu envoies des données (là encore via des formulaires web classiques) sur une connexion authentifiée, c'est que bien toi qui est à l'autre bout. Signer la déclaration ou envoyer la déclaration sur un canal authentifié, je vois la différence théorique, mais en pratique le résultat est le même : tu as la garantie que c'est bien toi (au sens de toi = le possesseur de la clef privée) qui a fait la déclaration. Le fait de considérer la "déclaration" comme un document unique, signé une fois, ou comme la procédure qui consiste à "déclarer" (envoyer petit à petit) les différents élément, sur un canal authentifier, ce sont deux points de vue équivalents, AMHA.
Après, peut-être que légalement l'un est valable et l'autre pas.
- elle génère un pdf de ta signature
Pour moi, c'est au serveur de générer ce pdf et de le signer, garantissant ainsi son authenticité. Certes, ça rajoute de la charge serveur.
De plus avec l'applet, rien à installer côté client. Ca fonctionne quel que soit le navigateur et l'OS (à quelques exceptions près).
Simplement s'il y a moyen de faire plus simple, autant faire plus simple. Pourquoi ne pas se passer de l'applet. Tous les navigateurs qui la supporte supportent aussi l'authentification SSL mutuelle, non ?
Le seul truc critiquable c'est la manière dont on te fournit le certificat puisqu'il suffit d'avoir accès à la feuille de déclaration de l'année précédente pour avoir toutes les données nécessaires. Mais l'utilisation d'OpenSSL n'y changerait rien!
Oh, et un "couple de certificats (publique/privé)" n'a aucun sens. Un certificat est par définition publique, et contient une clé publique. La clé privée correspondante n'en fait pas partie.
Tout à fait d'accord avec tout ça. J'ai volontairement simplifié (un peu trop, je l'admets) au moment de rédiger ce passage parce que je trouvais la phrase déjà trop lourde.
Le seul moyen vraiment propre de faire, ce serait un token matériel ou alors un certificat à aller faire signer physiquement par une entité de contrôle. Mais là, forcément, on perd tout l'intérêt de la simplicité et de la réduction des coûts. Sans compter que, finalement, la déclaration papier n'est pas franchement plus sécurisée (à part la signature manuscrite à contrefaire) : interception au niveau postal, etc.
[^] # Re: Justement
Posté par Boa Treize (site web personnel) . Évalué à 3.
En quoi l'applet change quoi que ce soit ? De ce que j'en ai vu (de loin et dans Firefox), le certificat est intégré au gestionnaire de certificats de Firefox, et c'est Firefox qui demande le mot de passe, non ?
Il n'y a aucun standard à ce sujet, chaque navigateur a sa propre manière de faire, extrêmement diverse (fonction dans Firefox, API Windows pour IE, dans certains cas il faut aller lire le magasin de certificats sur le disque dur, etc.).
D'où nécessité d'implémentation spécifique et parfois de code natif s'exécutant hors du navigateur. D'où Java et ActiveX, et non pas simplement JavaScript.
Si tu es connecté en SSL, tu reçois les pages web (des formulaires tout ce qu'il y a de plus classique) sur une connexion sûre. Tu es également certain qu'ils n'ont pas été modifiés.
Vraiment ? :-) Il n'y a jamais eu de bug à ce propos dans les navigateurs, d'injection JavaScript et autres blagues du même genre ?
Après, peut-être que légalement l'un est valable et l'autre pas.
Je ne suis pas expert sur ce point, mais je sais que ça a été un élément très déterminant dans les choix effectués par la Direction Générale des Impôts (qui en connaît un rayon, elle).
Ne pas oublier également deux aspects extrêmement importants que nous avons du mal à bien visualiser en tant que geek linuxiens :
- L'ergonomie (application utilisée par des gens qui ne savent pas ce qu'est une session web, dans quel état (bien sécurisé ou non) ils sont, ni même avec quel utilisateurs ils sont loggués sur leur poste de travail ;-))
- Les responsabilités juridiques : installer du code chez les utilisateurs, c'est prendre la responsabilité des éventuelles failles de sécurité dans ce code (surtout un code installé chez des millions de gens), gérer les versions du produit, gérer les mises à jour, etc. Java (ou ActiveX) résolvent ce problème en exécutant le code de manière encadrée et en assurant de l'exécution systématique de code à jour.
[^] # Re: Justement
Posté par Olivier Ponchaut . Évalué à 7.
1. Via un token papier (liste de code associée à ton user) -> Simple à déployer, mais chaque personne doit en faire la demande au préalable et attendre de recevoir ses codes (en plus ces codes sont personnel ->logique me direz-vous).
2. Via la carte d'identité électronique -> Donc un "token" matériel. Ici, en plus de devoir avoir la carte d'identité électronique, il faut aussi avoir un lecteur de carte.
Pour une fois, notre cher gouvernement a relativement bien fait les choses -> Ils fournissent tous les softs pour toutes les plateformes (y compris linux sous forme de code source à compiler -> les packages existe dans les dépots Ubuntu) + lecteurs de carte reconnus sous linux. Il y a en plus les composants pour Firefox, thunderbird, OpenOffice (notamment) pour signer ses documents, mails, ... avec la carte d'identité électronique.
Il y a encore un kit de développement mis à disposition pour créer des application qui utiliserait les possibilités d'authentification et de signature offerte par cette fameuse carte d'identité électronique.
Après, il reste le débat "pour ou contre la carte d'identité électronique" ... mais c'est un autre débat.
[^] # Re: Justement
Posté par ndesmoul . Évalué à 3.
Non! Il y a juste authentification mutuelle puis chiffrement du canal de communication. Rien ne te garantie que personne n'a réussi à modifier le site en douce. La page en elle même qui t'es envoyée n'est pas signée.
Franchement, si tu envoies des données (là encore via des formulaires web classiques) sur une connexion authentifiée, c'est que bien toi qui est à l'autre bout. Signer la déclaration ou envoyer la déclaration sur un canal authentifié, je vois la différence théorique, mais en pratique le résultat est le même : tu as la garantie que c'est bien toi (au sens de toi = le possesseur de la clef privée) qui a fait la déclaration. Le fait de considérer la "déclaration" comme un document unique, signé une fois, ou comme la procédure qui consiste à "déclarer" (envoyer petit à petit) les différents élément, sur un canal authentifier, ce sont deux points de vue équivalents, AMHA.
L'authentification est une procédure interactive qui ne peut être vérifiée après coup. La signature elle peut être vérifiée plus tard par n'importe qui a connaissance de la clé publique ad hoc. Elle ne peut être répudiée sauf si tu prouve que tu t'es fait volé ta clé privée. Elle a une valeur juridique. Cette signature est une preuve que tu as fait ta déclaration. Une authentification mutuelle + chiffrement ne permet pas cela.
Authentification et signature (de document) numérique sont deux actions très différentes même si elles utilisent des outils similaires.
Pour moi, c'est au serveur de générer ce pdf et de le signer, garantissant ainsi son authenticité. Certes, ça rajoute de la charge serveur.
Le PDF contient essentiellement ta signature et constitue donc une preuve. Je ne voit pas pourquoi ça serait au serveur de la fournir et encore moins pourquoi il devrait le signer. C'est toi qui certifie l'exactitude des infos (et donc signe), pas le serveur.
Simplement s'il y a moyen de faire plus simple, autant faire plus simple. Pourquoi ne pas se passer de l'applet. Tous les navigateurs qui la supporte supportent aussi l'authentification SSL mutuelle, non ?
En quoi la solution java est-elle complexe? Tu as juste besoin du plugin Java sous ton navigateur. Et OpenSSL tout seul c'est bien pour l'authentification mais à mon avis une signature numérique est indispensable, ce qui suppose des développements supplémentaires. On pourrait imaginer une extension Firefox, mais du coup ça fonctionnerait pas sous IE (pas grave), ni sous Konqueror, Opera, etc.
Pour moi la solution de l'applet Java me semble encore la meilleure solution.
[^] # Re: Justement
Posté par MrLapinot (site web personnel) . Évalué à 1.
Juste pour la signature du PDF, je voyais ça comme : tu as envoyé les infos de manière certifiée au serveur, et en retour il te fournit un récépissé à valeur officielle, donc signé par lui. Effectivement, si ça fonctionne dans l'autre sens (c'est la déclaration que tu signes et envoie, et non pas une sorte de trace à conserver), il faut que ce soit signé de ton côté.
[^] # Re: Justement
Posté par qstone . Évalué à 1.
[^] # Re: Justement
Posté par Éric (site web personnel) . Évalué à 3.
Ouais, enfin c'est vite oublier que ce sont ces mêmes impots qui authentifient le certificat. Techniquement rien ne les empêche de créer un certificat à ton nom, le marquer comme authentique dans leur base de données, puis signer une fausse déclaration avec.
Ca relativise d'un coup la "preuve" que donne le certificat. C'est une preuve parce que c'est marqué dans la loi et les décrets que la signature numérique se fait via ce système, mais il n'apporte pas grand chose ici côté sécurité.
Certes j'ai confiance dans le fait qu'ils ne font pas ce genre de choses, mais quitte à avoir confiance j'ai aussi confiance dans le fait qu'ils ne me présenteront pas de fausse déclaration en faisant croire que c'est la mienne, indépendamment des questions de certificat.
[^] # Re: Justement
Posté par ecyrbe . Évalué à 1.
[^] # Re: Justement
Posté par Éric (site web personnel) . Évalué à 2.
Authentifier quelqu'un pour après vérifier sa signature dans la même session, alors qu'on sait grâce à un bête ssl qu'il n'y a pas eu de corruption entre les deux, c'est assez inutile.
[^] # Re: Justement
Posté par ndesmoul . Évalué à 2.
D'autre part même en l'état la signature permet au moins d'être certain que ta déclaration va pas être modifiée après coup.
[^] # Re: Justement
Posté par dab . Évalué à 1.
Si entourloupe il y a, rien ne t'empêche de prouver ta bonne foi, preuve "concrète" à l'appui.
# Bon journal
Posté par GPL . Évalué à -7.
Juste que je préfère gnutls à openssl car c'est LGPL.
# EEE PC
Posté par MrLapinot (site web personnel) . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.