Boarf, la sécurité de TLS se base sur une assertion qui est fausse.
De fait, le https non maitrisé ne remplit pas la fonction de sécurisation.

MODÉRATION : ce message concerne l'architecture du protocole TLS et du déploiement du HTTPS, et non spécifiquement OpenSSL. Il a été déplacé depuis le topic Vulnérabilité dans OpenSSL

Le thème du présent topic est donc : les tiers de confiance dans l'architecture de TLS. Les discussions spécifiques les bugs d'OpenSSL sont hors sujets.

Assertion : les autorités de certifications sont dignes de confiances.

Beuhh

Concernant le certificat racine de l'ANSSI :

CA Company Name : ANSSI (Agence nationale de la sécurité des systèmes d'information)
Website URL : http://www.ssi.gouv.fr/
Organizational type : ANSSI is a part of the French Government.
(...)
This is the RSA4096-SHA256 root certificate of the French Government CA. The IGC/A root issues a subordinate CA for government or administrative organization only. Each of these subordinate CAs may issue end-entity certificates or additional subordinate CAs to be used for divisions within that organization. Each organization is required to follow the CP and the Government RGS, and be audited. This root certificate is used for certificate signature and CRL signature.

https://bugzilla.mozilla.org/show_bug.cgi?id=693450

Suppression d’une branche de l’IGC/A

7 décembre 2013
Revocation of an IGC/A branch

Suite à une erreur humaine lors d’une action de renforcement de la sécurité au ministère des finances, des certificats numériques correspondant à des domaines extérieurs à l’administration française ont été signés par une autorité de certification de la direction générale du Trésor rattachée à l’IGC/A.
Cette erreur n’a eu aucune conséquence sur la sécurité des réseaux de l’administration ni sur les internautes. La branche considérée de l’IGC/A a été coupée à titre préventif.
Un renforcement des procédures de l’IGC/A est en cours d’étude pour éviter qu’un tel incident ne puisse se reproduire.

http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html

Attestation de realisation d’audits relatifs à l’IGCA/A 4096

13 décembre 2011

Conformèment à la politique de certification de l’infrastructure de gestion de clés publiques opérée par l’ANSSI, dite "IGC/A" , l’ANSSI procède ou fait procéder systématiquement à l’audit préalable des autorités de certification demandant à être rattachées à l’IGC/A, ainsi qu’à des audits périodiques de surveillance.
En 2011, il a été procédé à l’audit de certification initiale de l’AC racine du ministère de l’intérieur, de l’outre-mer, des collectivités territoriales et de l’immigration, les 6 et 8 décembre (audit documentaire) et les 12 et 13 décembre (audit sur site). La conclusion favorable de cet audit a conduit à accepter la demande de certification du ministère.
Cet audit a été mené en conformité avec la politique de certification de l’IGC/A, et suivant les critères du référentiel général de sécurité (seconde référence), qui reprend notamment les exigences de l’ETSI TS 102 042.
D’autre part, un exercice a été mené le 15 décembre 2011, dans le but d’éprouver la capacité de l’ANSSI à faire face à un incident majeur affectant son service de publication. Les résultats de cet exercice, mené en collaboration avec certains utilisateurs de l’IGC/A, ont été très positifs.
Enfin, l’audit de surveillance de l’AC racine IGC/A (disposant des certificats RSA2048-SHA1 et RSA4096-SHA2) a été mené les 19 et 21 décembre 2011 en intégrant les exigences du CA/Browser Forum (troisième référence).

http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.html

Further improving digital certificate security
Saturday, December 7, 2013 11:43 AM
Posted by Adam Langley, Security Engineer

Late on December 3rd, we became aware of unauthorized digital certificates for several Google domains. We investigated immediately and found the certificate was issued by an intermediate certificate authority (CA) linking back to ANSSI, a French certificate authority. Intermediate CA certificates carry the full authority of the CA, so anyone who has one can use it to create a certificate for any website they wish to impersonate.

In response, we updated Chrome’s certificate revocation metadata immediately to block that intermediate CA, and then alerted ANSSI and other browser vendors. Our actions addressed the immediate problem for our users.

ANSSI has found that the intermediate CA certificate was used in a commercial device, on a private network, to inspect encrypted traffic with the knowledge of the users on that network. This was a violation of their procedures and they have asked for the certificate in question to be revoked by browsers. We updated Chrome’s revocation metadata again to implement this.

This incident represents a serious breach and demonstrates why Certificate Transparency, which we developed in 2011 and have been advocating for since, is so critical.

Since our priority is the security and privacy of our users, we are carefully considering what additional actions may be necessary.

[Update December 12: We have decided that the ANSSI certificate authority will be limited to the following top-level domains in a future version of Chrome:
.fr
.gp (Guadeloupe)
.gf (Guyane)
.mq (Martinique)
.re (Réunion)
.yt (Mayotte)
.pm (Saint-Pierre et Miquelon)
.bl (Saint Barthélemy)
.mf (Saint Martin)
.wf (Wallis et Futuna)
.pf (Polynésie française)
.nc (Nouvelle Calédonie)
.tf (Terres australes et antarctiques françaises)]

https://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html

AMA, de telles restrictions géographique devraient être généralisées à toutes les entités gouvernementales, pour commencer.

C'est une évolution facile qui ne suppose pas de changer l'architecture du système.

Le système des "autorités" se caractérise par :
- la concurrence commerciale envers le client
- les monopoles locaux pour le consommateur final

Le client, c'est le propriétaire du domaine (vivien). Il peut faire jouer la concurrence. Le produit est à peu près standardisé, même si les procédures peuvent un peu varier. Un fournisseur moins procédurier est plus confortable, même s'il dégrade au final la qualité du produit.

Le consommateur final, c'est le forum qui accède à ce forum. Je n'ai pas le choix : pour valider le certificat du site, je dois me reposer sur le fournisseur de cette certification. Je suis dans la situation de la personne qui veut téléphoner à quelqu'un chez un opérateur X, je vais financer cet opérateur X à un tarif défini (et régulé par une Autorité indépendante).

Il y a une différence : quand je choisis un opérateur de téléphonie, je sais s'il attribue des numéros fixes géographiques, non-géographiques, ou mobiles. (Il se trouve que les opérateurs mobiles attribuent tous un numéro mobile et non un fixe non-géographique, c'est bizarre.) Je peux choisir un opérateur en fonction de ce qu'il me coûtera et aussi en fonction de ce qu'il coûtera aux gens qui m'appellent.

La différence évidemment est que tout le monde pense à sa facture de téléphone et que presque personne ne pense à la chaîne de certification d'un site et à son magasin de certificats racines.

Il n'y a pas un "régulateur" unique des tiers de confiance TLS, mais plusieurs : MS, Mozilla... font les rois.

L'utilisateur délègue sa confiance à un gestionnaire (MS, Mozilla...) qui délègue à des AC qui délèguent souvent à des sous-traitants, et éventuellement sur plusieurs niveaux.

On parle souvent de la dilution des responsabilités que provoque la sous-traitance en cascade, on a là un exemple flagrant.

DANE ?

OVH ne semble pas proposer DANE