Journal : Télédéclarer ses impôts et citoyenneté
Posté par chryjs () le 13 mai 2008
Pour la version courte j'utilise debian testing amd64... Et cette année j'ai ramé pour télédéclarer (les autres fois ça s'est bien passé) à cause d'un contrôle débile sur la conformité de la JVM. Et oui j'avais une JVM 1.7.0 et ça n'était pas prévu.
Après des heures de chat et de téléphone où l'on a même essayé de me faire installer MS-IE (et oui il y en a qui ne doutent de rien) jusqu'au moment où... comment vous n'avez pas de menu avec le clic droit (en fait si mais bon) ?
Comment je m'en suis sorti ?
J'ai viré mon icedtea 1.7 et j'ai installé un vieux Blackdown-1.4.2-02 pour AMD64. Après un premier plantage au cours de la télédéclaration j'ai pu tout faire y compris la signature...
Je parle même pas de la charte du contribuable même pas respectée !
Quelle honte ! Chaque année ça se dégrade ! Ha oui la conclusion du support : faites une déclaration papier !
Après des heures de chat et de téléphone où l'on a même essayé de me faire installer MS-IE (et oui il y en a qui ne doutent de rien) jusqu'au moment où... comment vous n'avez pas de menu avec le clic droit (en fait si mais bon) ?
Comment je m'en suis sorti ?
J'ai viré mon icedtea 1.7 et j'ai installé un vieux Blackdown-1.4.2-02 pour AMD64. Après un premier plantage au cours de la télédéclaration j'ai pu tout faire y compris la signature...
Je parle même pas de la charte du contribuable même pas respectée !
Quelle honte ! Chaque année ça se dégrade ! Ha oui la conclusion du support : faites une déclaration papier !
> Lire le journal (62 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #930731.
Run by 
Cette page a été générée par Templeet en 0.0815s (dont 0.0069 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Web, form et certificats...
Est-ce qu'il ne suffirait pas de monter un canal SSL avec le certificat fournit par les impôts?
Java est déraisonnablement complexe comme dépendance pour la déclaration online.
[^]Re: Web, form et certificats...
Oui j'ai jamais testé (je paye pas encore d'impôts \o/).
Mais je suis étonné de ce choix de Java, j'ai rien contre la techno en elle même bien au contraire. Mais est-ce que un simple formulaire HTML en https ne serait pas suffisant ?
Quelqu'un pourrait éclairer ma lanterne? (comme dit plus haut je ne peut pas tester l'appli pour comprendre le besoin).
[^]Re: Web, form et certificats...
Il faudrait plus qu'un simple formulaire. L'idée ici n'est pas seulement d'assurer la confidentialité (faisable avec du https basique), mais surtout de signer ta déclaration, ce qui implique que tu disposes de ton côté d'un certificat ad hoc (fournit par l'administration) et de sa clé privée associée.
L'applet java (elle-même signée pour éviter l'exécution de code frauduleux) sert à remplir ta déclaration, mais se charge également de la signer numériquement.
Le choix de Java me semble pertinent. En plus c'est multiplateforme même s'il reste quelques soucis comme l'indique ce journal.
[^]Re: Web, form et certificats...
> Il faudrait plus qu'un simple formulaire. L'idée ici n'est pas seulement d'assurer la confidentialité (faisable avec du https basique), mais surtout de signer ta déclaration, ce qui implique que tu disposes de ton côté d'un certificat ad hoc (fournit par l'administration) et de sa clé privée associée.
C'est effectivement la raison. Ceci dit j'ai toujours trouvé ça complètement stupide dans le système des impots. Tu peux créer/obtenir/renier ton certificat avec la même application qui sert à vérifier ta signature. S'il est capable de t'autoriser à créer/obtenir/renier ton certificat c'est qu'il t'a déjà authentifié avec assurance, et la vérification devient purement superflue.
La sécurité est toujours équivalente à celle du maillon le plus faible. On te demande quelques infos pas très privée et un numéro inscrit sur la déclaration. N'importe qui qui a ça peut supprimer ton certificat et en créer un nouveau avant de signer avec. C'est quoi l'intérêt dans ce cas ? la signature n'a que la valeur du "il a pu me donner le numéro inscrit sur la déclaration".
Je suppose que c'est un bête pré-requis légal ou administratif avec "il faut que ce soit signé, la signature électronique c'est avec des certificats alors mettons un certificat". Le fait que le certificat ne rajoute rien du tout à la sécurité du bouzin n'entre même pas en ligne de compte.
L'applet java a un sens dans l'idée qu'elle est elle-même signée (ce qui me garantie en théorie que personne n'y a touché si je suis capable d'authentifier la signature) mais le certificat qu'on nous impose pour signer notre envoi, c'est de la branlette intellectuelle.
[^]Re: Web, form et certificats...
Le choix de Java est clairement fait dans un souci de transparence et d'indépendance de la plate-forme de développement. .NET était déjà présent à l'époque où la télédéclaration a été mis en oeuvre, et un certain nombre de facilités existait alors qu'avec Java/Eclipse y'avait encore pas mal de boulot en plus à faire. Mais Java a été choisi malgré tout pour ne pas s'enfermer dans une solution dont les évolutions sont non-maîtrisées.
[^]Re: Web, form et certificats...
D'autant que le portail de télédéclaration/consultation repose sur des technos libres, à savoir Red Hat+Apache+JBoss. Bon ok, la partie BDD quand à elle est basée sur des mainframes sous HP-UX et Oracle, mais pour le coup faut de la robustesse (et du support).
Et pour y avoir bossé, je peux dire que l'architecture de l'ensemble est bien béton, que ce soit en termes de fiabilité, de sécurité ou de scalabilité (je n'en dirai pas plus, clause de confidentialité, toussa).
radio ianux
[^]Re: Web, form et certificats...
Pourquoi moinsser ce pauvre garçon ?!
Every time you write invalid markup, God kills a kitten
[^]Re: Web, form et certificats...
Comme d'autres l'ont dit, SSL ne permet que d'assurer la confidentialité du flux HTTP entre ton navigateur et les serveurs des impôts.
Or, il faut aussi exécuter du code dans ton navigateur :
- Affichage de ce que tu as déclaré indépendamment du navigateur utilisé (le résumé de ta déclaration est affiché par une applet, et pas par le navigateur) (ce résumé t'engage, c'est le point le plus important juridiquement)
- Sélection du certificat à utiliser pour signer (il n'y a pas de standard pour afficher une telle liste, d'où code spécifique aux navigateurs)
- Signature de ce que tu as déclaré (exécuté sur ton navigateur, pas aux impôts) (bien sûr, très important)
- Affichage de l'accusé de réception des impôts et génération du PDF associé (généré par une applet) (cet accusé de réception engage les impôts, c'est l'autre point important juridiquement)
Avec bien sûr, chiffrements, signatures, vérifications et contre-vérifications aux endroits appropriés.
Tout cela, SSL ne le permet pas bien sûr. On pourrait imaginer utiliser du JavaScript, mais c'est pas assez standard, trop dynamique, pas assez performant, trop enfermé dans le navigateur... Reste donc Java (ou ActiveX).
[^]Re: Web, form et certificats...
> - Signature de ce que tu as déclaré (exécuté sur ton navigateur, pas aux impôts) (bien sûr, très important)
Ca serait très important si le dit certificat était récupéré indépendamment de la déclaration aux impots, ou si il était utilisé globalement dans toutes nos communications avec l'état. Là il est donné par le même site, dans la même procédure, et n'a de valeur que dans cette procédure. En quoi est-ce important ? (comprendre : en quoi il ajoute une quelconque sécurité inexistante sinon ?)
> - Affichage de l'accusé de réception des impôts et génération du PDF associé (généré par une applet) (cet accusé de réception engage les impôts, c'est l'autre point important juridiquement)
L'affichage, un pdf suffit. La génération ça me parait totalement incohérent s'il est effectivement fait par l'applet côté client (quel valeur peut-il avoir dans ce cas ? au niveau certification/sécurité/assurance que tout s'est déroulé correctement ?)
En fait :
- affichage indépendant du navigateur : ton affichage dépendra toujours de ton lecteur, là tu as juste changé de lecteur pour dépendre de la jvm (d'où en partie le pourquoi ils vérifient la version de la jvm). Faire un code html standard et vérifier les navigateurs courants (avec une vérification du user agent comme ils le font sur la jvm) suffirait. Pour les parties vraiment critiques un doublage PDF suffit (et en plus c'est sauvegardable).
- sélection du certificat et signature de la déclaration : cf plus haut, ça n'ajoute strictement aucune sécurité vu le modèle qu'ils ont choisit. C'est joli en théorie mais la mise en application ici met totalement en échec les avantage de la signature
- affichage de l'accusé de réception : un PDF signé généré côté serveur irait très bien, je serait d'ailleurs étonné que même avec leur appli java ce n'est pas ce qu'il se passe.
Le seul point vraiment unique de l'applet par rapport à un bête html/pdf/http/ssl tu ne le listes pas : c'est l'assurance que l'application elle même (le contenu de l'applet) vient des impots sans modification (le ssl ne certifie que le fait que les impots répondent, il n'assure pas l'intégrité du contenu).
Maintenant pour ma part ce point justifie parfaitement la solution Java.
Le point qui leur a fait choisir Java est probablement bureaucratique/légal/administratif, c'est pouvoir marquer "signature électronique", même si concrêtement ça n'apporte rien. Bref, pas un point technique.
[^]Re: Web, form et certificats...
Techniquement le certificat n'a rien d'exceptionnel, il peut être utilisé par toute entité qui reconnaît la Direction Générale des Impôts comme une autorité de certification et qui sait interpréter le CN de ce certificat (rien de bien difficile).
À l'inverse la Direction Générale des Impôts peut utiliser tout certificat signé par une autorité reconnue, elle a choisi de ne pas le faire dans le cadre des impôts des particuliers (encore que... faudrait tester un certificat généré par une autorité tierce avec un CN "qui va bien"... si ça se trouve ça passe), mais elle le fait dans le cadre des impôts des professionnels.
Je ne sais plus comment se passe la délivrance du certificat précisément, en tout cas derrière la façade commune c'est deux applications bien différentes qui se chargent d'une part de la génération / distribution, et d'autre part de la saisie de l'impôt. Ce serait peut-être plus clair (et plus sûr ?) si les deux étapes étaient clairement séparées, mais ça se ferait au coût de la convivialité de l'opération, critère manifestement important aux yeux du ministère.
Le PDF est bien généré côté client, mais je ne crois pas que ce soit pour un quelconque critère de sécurité : c'est soit pour économiser de la bande passante, soit parce que quand cette partie a été développée (aux environs de 2004 je crois) il n'y avait pas de bonne techno stable de génération PDF côté serveur, soit enfin pour économiser du CPU et de la RAM côté serveur.
Ils pourraient peut-être se contenter d'afficher du PDF pour les parties critiques, mais ce serait beaucoup moins convivial voire très confus (cas des PDF qui s'affichent systématiquement hors du navigateur) ; en termes d'ergonomie c'est beaucoup plus propre d'intégrer une applet au sein du site qui a exactement la même apparence que le reste du HTML. Par contre pour ces sections critiques, une applet est bien utile, car outre l'aspect juridique qui est vraiment important (en cas de bug, on peut sortir le code source, alors que sinon on peut juste dire "faute à pas de chance" et ça marche pas génial dans un tribunal), elle diminue également les chances d'injection de HTML ou de JavaScript de provenance externe (les navigateurs ont eu pas mal de failles de sécurité à ces niveaux).
Pour ce qui est de la "mise en échec totale des avantages de la signature" il faudrait que tu t'expliques plus en détail, car je ne te comprends pas. Il me semble au contraire qu'on a là une utilisation correcte des certificats, mais je ne suis pas expert en la matière. Arguments bienvenus.
Enfin pour conclure, Java a bien été choisi sur des critères techniques (et également architecturaux et stratégiques) et non pas administrativo-bureaucrato-légaux-truc. Clairement la démarche a abouti à Java et n'est pas partie d'un a priori.
(Et au fait, il y a aussi une version ActiveX de secours pour ceux qui sont sur un poste Windows sans Java correct. La sélection est transparente lors de la phase de détection initiale.)
[^]Re: Web, form et certificats...
> Pour ce qui est de la "mise en échec totale des avantages de la signature" il faudrait que tu t'expliques plus en détail, car je ne te comprends pas. Il me semble au contraire qu'on a là une utilisation correcte des certificats, mais je ne suis pas expert en la matière. Arguments bienvenus.
Le certificat peut servir :
1- aux impots pour être sûrs que c'est bien toi qui a signé
2- aux impots pour prouver à d'autres que tu as signé
3- à toi pour prouver aux impots que tu as signé
4- à toi pour prouver à d'autres que tu as signé
Le 1 est la partie faible. Vu que c'est eux qui te donnent et qui valident ton certificat, ils sont déjà assurés que c'est bien toi derrière pendant cette session SSL (sinon ils viennent de balancer le certificat à un tiers et tout le système se casse déjà la gueule). Bref, le certificat ne garantie rien de plus.
Le 2 est du même tonneau. Ils peuvent prouver que ta déclaration est signée mais il va falloir prouver que c'est toi qui avait le certificat. Comme c'est les impots qui distribuent le certificat on en revient à un besoin pour les impots de prouver que c'était toi derrière la connexion SSL. Bref, le certificat ne rajoute rien et pour prouver que tu as signé il va falloir de toutes façons prouver que le système et l'authentification étaient sûrs même avant le certificat.
De toutes façons la question c'est "Peux t'on croire les impots sur parole ?".
- Si on répond oui le certificat n'est pas utile parce qu'il suffit qu'ils assurent que leur vérification d'identité et que leur appli sont corrects, et qu'ils ont bien recu cette déclaration, pas besoin du certificat.
- Si on répond non alors le certificat n'offre rien de plus non plus car c'est les impots qui authentifient le certificat ..... si on part de l'idée qu'ils puissent mentir ils auraient aussi bien pu authentifier à ton nom un autre certificat que le tien, et signer la fausse déclaration avec.
Le 3 et le 4 je les ai mis car c'est une des assurances données par le système de certificat mais en réalité il suffit aux impots de signer ton récipissé avec nom/identifiant et somme de contrôle de ta déclaration. Tu n'as pas besoin d'avoir un certificat toi même pour ça.
> Par contre pour ces sections critiques, une applet est bien utile, car outre l'aspect juridique qui est vraiment important (en cas de bug, on peut sortir le code source, alors que sinon on peut juste dire "faute à pas de chance" et ça marche pas génial dans un tribunal),
Le java serait entièrement côté serveur qu'on pourrait faire la même chose : on sait ce que ça a sorti. Mais je comprend l'aspect problématique des navigateurs actuels et je suis d'accord pour dire que ça peut tout à fait justifier Java. Je ne parlais que de l'aspect certificat, je conçois bien que Java peut apporter d'autres avantages.
[^]Re: Web, form et certificats...
Merci pour tous ces commentaires. Donc vous m'avez convaincu de revenir à la version papier.
Java est une grosse... GROSSE erreur sachant qu'un canal SSL avec le certificat des impôts est largement suffisant.
Aaaaaah! La corruption au niveau de l'état: ça me fait penser au RGI où certains ont réussi à en bloquer l'adoption en attendant cette farçe qu'est OOXML et d'autres ont réussi à imposer l'utilisation du bloat horriblement complexe qu'est java pour la déclaration online. Pas un pour rattraper l'autre.