GuiGui's Show

Identifier les cas où un document store n'est pas adapté.

« MongoDB is a document-oriented database. Instead of storing your data in tables made out of individual rows, like a relational database does, it stores your data in collections made out of individual documents. In MongoDB, a document is a big JSON blob with no particular format or schema.

[...]

At the root, we have a set of TV shows. Each show has many seasons, each season has many episodes, and each episode has many reviews and many cast members. When users come into this site, typically they go directly to the page for a particular TV show. On that page they see all the seasons and all the episodes and all the reviews and all the cast members from that show, all on one page. So from the application perspective, when the user visits a page, we want to retrieve all of the information connected to that TV show.

There are a number of ways you could model this data. In a typical relational store, each of these boxes would be a table. You’d have a tv_shows table, a seasons table with a foreign key into tv_shows, an episodes table with a foreign key into seasons, and reviews and cast_members tables with foreign keys into episodes. So to get all the information for a TV show, you’re looking at a five-table join.

We could also model this data as a set of nested hashes. The set of information about a particular TV show is one big nested key/value data structure. Inside a TV show, there’s an array of seasons, each of which is also a hash. Within each season, an array of episodes, each of which is a hash, and so on. This is how MongoDB models the data. Each TV show is a document that contains all the information we need for one show.

[...]

It’s got some title metadata, and then it’s got an array of seasons. Each season is itself a hash with metadata and an array of episodes. In turn, each episode has some metadata and arrays for both reviews and cast members.

It’s basically a huge fractal data structure.

[...]

All of the data we need for a TV show is under one document, so it’s very fast to retrieve all this information at once, even if the document is very large. There’s a TV show here in the US called “General Hospital” that has aired over 12,000 episodes over the course of 50+ seasons. On my laptop, PostgreSQL takes about a minute to get denormalized data for 12,000 episodes, while retrieval of the equivalent document by ID in MongoDB takes a fraction of a second.

So in many ways, this application presented the ideal use case for a document store.

[...]

There is a really important difference between Diaspora’s social data and the Mongo-ideal TV show data that no one noticed at first.

With TV shows, each box in the relationship diagram is a different type. TV shows are different from seasons are different from episodes are different from reviews are different from cast members. None of them is even a sub-type of another type.

But with social data, some of the boxes in the relationship diagram are the same type. In fact, all of these green boxes are the same type — they are all Diaspora users.

A user has friends, and each friend may themselves be a user. Or, they may not, because it’s a distributed system. (That’s a whole layer of complexity that I’m just skipping for today.) In the same way, commenters and likers may also be users.

This type duplication makes it way harder to denormalize an activity stream into a single document. That’s because in different places in your document, you may be referring to the same concept — in this case, the same user. The user who liked that post in your activity stream may also be the user who commented on a different post.

[...]

We can represent this in MongoDB in a couple of different ways. Duplication is any easy option. All the information for that friend is copied and saved to the like on the first post, and then a separate copy is saved to the comment on the second post. The advantage is that all the data is present everywhere you need it, and you can still pull the whole activity stream back as a single document.

[...]

You can also see why this is dangerous. Updating a user’s data means walking through all the activity streams that they appear in to change the data in all those different places. This is very error-prone, and often leads to inconsistent data and mysterious errors, particularly when dealing with deletions.

[...]

There is another approach you can take to this problem in MongoDB, which will more familiar if you have a relational background. Instead of duplicating user data, you can store references to users in the activity stream documents.

With this approach, instead of inlining this user data wherever you need it, you give each user an ID. Once users have IDs, we store the user’s ID every place that we were previously inlining data. New IDs are in green below.

[...]

This eliminates our duplication problem. When user data changes, there’s only one document that gets rewritten. However, we’ve created a new problem for ourselves. Because we’ve moved some data out of the activity streams, we can no longer construct an activity stream from a single document. This is less efficient and more complex. Constructing an activity stream now requires us to 1) retrieve the stream document, and then 2) retrieve all the user documents to fill in names and avatars.

What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead.

[...]

Let’s return to TV shows for a second. The set of relationships for a TV show don’t have a lot of complexity. Because all the boxes in the relationship diagram are different entities, the entire query can be denormalized into one document with no duplication and no references. In this document database, there are no links between documents. It requires no joins.

On a social network, however, nothing is that self-contained. Any time you see something that looks like a name or a picture, you expect to be able to click on it and go see that user, their profile, and their posts. A TV show application doesn’t work that way. If you’re on season 1 episode 1 of Babylon 5, you don’t expect to be able to click through to season 1 episode 1 of General Hospital.

[...]

Once we started doing ugly MongoDB joins manually in the Diaspora code, we knew it was the first sign of trouble. It was a sign that our data was actually relational, that there was value to that structure, and that we were going against the basic concept of a document data store.

Whether you’re duplicating critical data (ugh), or using references and doing joins in your application code (double ugh), when you have links between documents, you’ve outgrown MongoDB. When the MongoDB folks say “documents,” in many ways, they mean things you can print out on a piece of paper and hold. A document may have internal structure — headings and subheadings and paragraphs and footers — but it doesn’t link to other documents. It’s a self-contained piece of semi-structured data.

If your data looks like that, you’ve got documents. Congratulations! It’s a good use case for Mongo. But if there’s value in the links between documents, then you don’t actually have documents. MongoDB is not the right solution for you. It’s certainly not the right solution for social data, where links between documents are actually the most critical data in the system.

[...]

When MongoDB is all you have, it’s a cache with no backing store behind it. It will become inconsistent. Not eventually consistent — just plain, flat-out inconsistent, for all time. At that point, you have no options. Not even a nuclear one. You have no way to regenerate the data in a consistent state.

When Diaspora decided to store social data in MongoDB, we were conflating a database with a cache. Databases and caches are very different things. They have very different ideas about permanence, transience, duplication, references, data integrity, and speed.

[...]

Remember that TV show application? It was the perfect use case for MongoDB. Each show was one document, perfectly self-contained. No references to anything, no duplication, and no way for the data to become inconsistent.

About three months into development, it was still humming along nicely on MongoDB. One Monday, at the weekly planning meeting, the client told us about a new feature that one of their investors wanted: when they were looking at the actors in an episode of a show, they wanted to be able to click on an actor’s name and see that person’s entire television career. They wanted a chronological listing of all of the episodes of all the different shows that actor had ever been in.

We stored each show as a document in MongoDB containing all of its nested information, including cast members. If the same actor appeared in two different episodes, even of the same show, their information was stored in both places. We had no way to tell, aside from comparing the names, whether they were the same person. So to implement this feature, we needed to search through every document to find and de-duplicate instances of the actor that the user clicked on. Ugh. At a minimum, we needed to de-dup them once, and then maintain an external index of actor information, which would have the same invalidation issues as any other cache.  »

Via http://www.gcu-squad.org/2014/11/mongo-or-not-mongo/

:D

Via http://lehollandaisvolant.net/?id=20150428185651

« Depuis que les piratages de Comodo et DigiNotar ont fait prendre conscience du peu de sécurité qu'apportent les certificats X.509, plusieurs solutions ont été proposées pour combler les failles des autorités de certification. La proposition de ce RFC consiste à permettre à un client d'épingler (to pin) les clés cryptographiques d'un serveur HTTP utilisant TLS, c'est-à-dire à s'en souvenir pendant une durée spécifiée par le serveur. Ainsi, même si un faux certificat est émis par une AC, il ne sera pas accepté.

[...]

Parmi les solutions élaborées, il y a DANE, qui s'appuie sur le DNS (RFC 6698), mais Google préfère les certificats à la lumière du jour du RFC 6962 et l'épinglage (pinning) des clés, dans ce tout nouveau RFC 7469.

[...]

L'épinglage fait partie des techniques TOFU (Trust On First Use) : la première fois qu'un client se connecte au serveur, il ne peut pas savoir si la clé est bonne (il doit se fier à la validation X.509, avec ses limites). À la première connexion, le client HTTP (par exemple un navigateur Web) doit espérer qu'il n'y a pas d'homme du milieu ayant réussi à obtenir un faux certificat (pour cette raison, une attaque persistente, comme celle du ministère des finances, citée plus haut, ne serait pas empêchée par l'épinglage). Aux connexions suivantes, le client HTTP pourra par contre vérifier l'identité du serveur, grâce à la clé épinglée, c'est-à-dire gardée en mémoire. Ce n'est pas idéal (imaginez un homme du milieu ayant un faux certificat pour la première connexion et épinglant ses propres clés, empêchant ainsi toute correction ultérieure !) mais c'est un progrès sur la situation actuelle (valider les clés est un problème difficile en cryptographie).

[...]

Elle définit un nouvel en-tête HTTP, Public-Key-Pins:. Présent dans une réponse HTTPS, cet en-tête indique au client HTTP que ce serait souhaitable qu'il épingle, qu'il mémorise, la clé publique. Le contenu de l'en-tête Public-Key-Pins: est le condensat de la clé publique utilisée pour TLS, condensat encodé en Base64 (RFC 4648). L'algorithme de condensation est indiqué dans la valeur de l'en-tête. Aujourd'hui, c'est forcément SHA-256 (RFC 6234). La clé est l'encodage DER du champ subjectPublicKeyInfo du certificat X.509 (à noter que les cas des clés brutes du RFC 7250 ou des clés PGP du RFC 6091 ne semblent pas traités, car elles n'ont pas les problèmes des certificats X.509). Une directive max-age est obligatoire dans l'en-tête HTTP, pour indiquer le nombre de secondes que doit durer l'épinglage (après quoi le client HTTP « oublie » la clé). Voici un exemple :

Public-Key-Pins: max-age=604800;
       pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="

[...]

Autre directive facultative, report-uri indique à quel URI le client doit signaler les erreurs résultant de l'épinglage. En effet, on peut prévoir que, comme avec toute technique de sécurité, il y aura des problèmes. Par exemple, des webmestres changeront de clé et oublieront de modifier le Public-Key-Pins:. Il est donc important que ces problèmes soient détectés rapidement. Ce signalement se fera selon la technique décrite plus loin en section 3. Attention aux conséquences pour la vie privée ! La très détaillée section 5 couvre ce risque d'intrusivité.

[...]

À noter qu'un deuxième en-tête est défini, Public-Key-Pins-Report-Only:, qui a exactement la même syntaxe, mais une sémantique différente : le client HTTP teste la clé épinglée et, si elle est fausse, le signale à l'URI indiqué par report-uri (qui devient donc obligatoire), mais n'empêche pas l'accès au serveur. C'est utile pour tester avant le vrai déploiement.

[...]

Par exemple, l'épinglage peut avoir des conséquences néfastes si on s'est fait voler sa clé privée : normalement, on génère une nouvelle clé, un nouveau certificat et on demande à l'AC de re-signer. Mais on ne pourra pas l'utiliser car la clé publique correspondant à la clé volée est toujours épinglée dans des tas de navigateurs. On peut réduire ce problème en diminuant la durée d'épinglage. Mais, alors, on réduit aussi la durée de la protection dans le cas où une AC génère un certificat mensonger. Un compromis est donc nécessaire. Une approche possible est d'épingler, non pas la clé du serveur mais une clé intermédiaire dans la chaîne des certificats. Supposons que la société Example, qui gère example.com soit cliente de l'AC SmallAC qui a elle-même son certificat signé par une AC très largement reconnue, BigAC. En épinglant la clé de SmallAC, on se protège contre un vol de la clé privée d'example.com, et contre un faux certificat, même émis par BigAC. La société Example reste vulnérable à un faux certificat produit par SmallAC mais cela diminue sérieusement le nombre d'acteurs qui peuvent attaquer Example.

[...]

On a vu plus haut qu'on pouvait avoir plusieurs clés dans l'en-tête Public-Key-Pins:. Une des utilisations de cette possibilité est le cas où on a une clé de réserve (backup pin), non utilisée mais gardée en un endroit différent de la clé du certificat actuel. Ainsi, si, pour une raison ou pour une autre, la clé est inutilisable, la clé de réserve peut prendre le relais immédiatement puisqu'elle est déjà épinglée.

[...]

Autre cas où l'épinglage peut avoir un effet néfaste, celui de l'épinglage hostile. Imaginons un méchant qui obtienne un faux certificat. Il détourne le trafic (par exemple par un empoisonnement DNS) et envoie les gens vers son serveur HTTPS, qui semblera légitime, en raison du faux certificat. Avec l'épinglage, il peut même prolonger son attaque en épinglant sa clé. Si le site légitime n'avait pas été visité avant, ou s'il ne faisait pas d'épinglage, l'attaque peut réussir, bloquant le client HTTPS sur la clé de l'agresseur pour la durée max-age spécifiée par ledit agresseur. Il n'y a pas de solution miracle pour ce problème. Une possibilité est de précharger les clés de sites connus dans le navigateur. Une autre est d'utiliser les certificats au grand jour du RFC 6962.

[...]

Autres risques, ceux pour la vie privée (section 5). Un serveur peu sympathique peut utiliser l'épinglage comme une sorte de cookie discret. Par exemple, il peut mettre une petite image dans un sous-domaine, épingler des fausses clés pour ce sous-domaine (une différente par visiteur) et attendre les signalements à report-uri pour identifier un client HTTPS unique. Des sites différents peuvent même coopérer pour avoir le même report-uri, pour suivre un client à travers plusieurs sites.

À noter aussi que les signalements d'un problème de validation contiennent la chaîne de certificats utilisée. Cela peut permettre d'identifier l'utilisation de faux certificats par telle ou telle organisation. C'est plutôt une bonne chose pour détecter des attaques comme celle effectuée au ministère des finances mais cela ne sera évidemment pas apprécié de ceux qui veulent faire du détournement de trafic.

[...]

Le RFC recommande aussi que l'utilisateur puisse accéder facilement à la liste des clés épinglées et aussi, ce qui me semble plus contestable, qu'il puisse la modifier, par exemple en désépinglant les clés. Cela me semble dangereux car cela peut ouvrir une voie à l'ingénierie sociale (« il y a un petit problème technique, si l'accès vous est refusé, cliquez sur Clear all pinned keys »).

[...]

(Tom me fait remarquer à juste titre qu'une clé de secours est obligatoire - section 4.3 - et que donc il faut toujours au moins deux pin-sha256. J'ai simplifié.)  »

« Le protocole HTTP définit plusieurs codes de retour pour une redirection (« la ressource que tu cherches n'est pas ici, va voir là »). La section 6.4 du RFC 7231 classe ces trois codes de retour en notant que deux désignent des redirections temporaires (302 et 307) et qu'un désigne une redirection permanente (301). Deux codes permettent au client HTTP de remplacer, pour la nouvelle requête, la méthode POST par un GET (301 et 302), un autre ne le permet pas (307). Si vous avez suivi, vous avez noté qu'il manquait un code voulant dire « redirection permanente mais sans changer la méthode HTTP ». C'est l'objet du nouveau code décrit à l'origine dans le RFC 7238, et désormais normalisé dans ce RFC, le code 308. »

« L'auteur de la retranscription précise au journal, dans un second temps, que "des modifications peuvent être apportées, tant que ces dernières n’altéraient pas l’esprit de l’intervention". Et se ravise finalement, par mail : "Au final, ce qui a été dit deux fois dans la même lancée (après plusieurs autres) a été ramassé en une fois, celle où il y a 'par nature et par essence', écrit cette personne. Mais je conçois très bien que l’effet en soit amoindri. Je vais remanier ça afin que ce soit la phrase d’entrée qui apparaisse." A l'heure où cet article est publié sur francetv info (20h20), la modification n'a toujours pas été apportée. »

Sans aller jusqu'à parler de malhonnêteté ciblée sur le dossier du projet de loi renseignement comme le fait cet article, je trouve cela très éclairant sur la qualité des retranscriptions de l'ensemble des interventions qui se produisent dans notre parlement.

« Le protocole TLS offre un grand nombre de choix : choix de la version, choix des algorithmes cryptographiques, plein d'options... Tous ces choix ne sont pas équivalents en terme de sécurité : les versions anciennes de TLS ont des vulnérabilités absentes des plus récentes, par exemple. Dès qu'un protocole cryptographique a des choix, il y a un risque de sécurité : que l'attaquant tente de perturber la négociation initiale entre les deux parties, pour les amener à choisir les variantes les moins sécurisées, en faisant croire à chacun que son partenaire ne peut pas gérer les meilleures variantes. C'est ce qu'on nomme une attaque par repli (downgrade attack) et c'est une plaie classique des protocoles cryptographiques (sauf de ceux qui n'offrent aucun choix, mais qui ont d'autres problèmes, notamment l'impossibilité d'évoluer). Ce RFC présente une nouvelle technique TLS pour empêcher certaines attaques par repli : annoncer un algorithme cryptographique qui n'est pas un vrai algorithme mais qui signale qu'on a effectué un repli, permettant au partenaire de détecter que quelqu'un a interféré avec la communication. Cette technique se nomme SCSV, pour Signaling Cipher Suite Value.

[...]

Mais il y a des serveurs TLS bogués qui réagissent mal avec certaines variantes. Au lieu d'indiquer proprement qu'ils ne gèrent pas ces variantes, ils coupent la communication. Un client TLS qui veut donc maximiser ses chances de se connecter va donc réessayer, en ne proposant pas les choix qui ont pu mener au précédent échec. C'est sympa du point de vue de l'interopérabilité mais cette downgrade dance est dangereuse du point de vue de la sécurité : le serveur, lors de la deuxième tentative, ne sait pas qu'il s'agit d'un repli. [...]  Jusqu'à ce nouveau RFC, la seule protection contre ces attaques était de configurer le serveur pour refuser certains choix vraiment trop mauvais, question sécurité. Cette solution était trop rigide (pour reprendre l'exemple précédent, TLS 1.0 n'est pas catastrophique : il est raisonnable d'autoriser les vieux clients à se connecter en 1.0, mais on veut empêcher que les clients récents ne soient amenés à se limiter à 1.0).

[...]

À noter que, même en l'absence d'un attaquant actif, on voit parfois des replis malencontreux : un problème temporaire de réseau peut mener le client TLS à se dire « tiens, pas de réponse, je vais réessayer en TLS 1.0 et sans les extensions, pour voir ».

[...]

Donc, pour permettre au serveur de détecter que le client a fait un repli à tort, notre RFC introduit un nouveau pseudo-algorithme de chiffrement, TLS_FALLBACK_SCSV, valeur 0x56,0x00 (désormais dans le registre IANA). Il sera envoyé uniquement par le client, jamais par le serveur. Ce n'est pas un vrai algorithme, juste un signalement par le client qu'une première connexion a échoué et que le client tente un repli (section 4 du RFC). Si le client envoie le pseudo-algorithme TLS_FALLBACK_SCSV dans son ClientHello, et indique un protocole de version inférieure à ce que le serveur peut gérer, le serveur peut alors se rendre compte que le client a effectué un repli à tort (cf. section 3). Il peut alors répondre avec un nouveau message d'erreur, l'alerte TLS inappropriate_fallback (valeur 86).

[...]

Le signalement par le client qu'il s'est replié est un (pseudo-)algorithme de chiffrement, pas une extension TLS, car le but est qu'il ne pose de problème avec aucun serveur, même le plus ancien et le plus bogué. Le mécanisme d'indication des algorithmes de chiffrement date des débuts de SSL et on peut donc certainement compter dessus.

[...]

Si le client n'a pas pu se connecter en TLS v1 ou supérieur, et se replie sur SSL v3, alors, le TLS_FALLBACK_SCSV est vraiment nécessaire car SSL v3 a de nombreuses faiblesses (la faille Poodle par exemple). Par contre, quand un client a une toute nouvelle version de TLS (à l'heure de la publication de ce RFC, la version 1.3 est en cours de développement), des difficultés avec les vieux serveurs sont à prévoir et il peut être préférable de ne pas envoyer TLS_FALLBACK_SCSV, et d'accepter le repli. »

Je note que ça complique un repli mais ça ne l'empêche pas complètement : un attaquant actif peut supprimer la SCSV mais ça va au delà d'une attaque par repli classique "je drop le paquet pour forcer downgrade" donc il y a renforcement de la sécurité.

« Ici, le syllogisme n’est pas fini, la honte ayant sans doute saisi le ministre à la gorge au dernier moment, mais il est aisé à compléter.

Majeure : le projet de loi relatif au renseignement ne contient aucune disposition attentatoire aux libertés.

Mineure : le projet de loi contient des dispositions remettant en cause la vie privée et le droit à la vie privée.

Conclusion non énoncée : le droit à la vie privée ne compte pas parmi les libertés.

Et c’est vrai, dans un sens. La vie privée ne fait pas partie des libertés fondamentales. Elle est plus que ça : elle est un droit fondamental.

Rappelons qu’une liberté est une interdiction d’interdire faite à l’État : l’Etat ne peut porter atteinte à une liberté fondamentale ou alors sous des conditions très strictes. Le droit va plus loin, il crée une obligation à la charge de l’État de prêter main-forte à ce droit des atteintes commises par les particuliers. Le droit est plus fort que la liberté car il impose à l’État d’agir.

Or le droit à la vie privée est un droit fondamental, consacré au niveau européen par l’article 8 de la Convention européenne des droits de l’homme :

        Toute personne a droit au respect de sa vie privée et familiale, de son domicile et de sa correspondance.

        Il ne peut y avoir ingérence d'une autorité publique dans l'exercice de ce droit que pour autant que cette ingérence est prévue par la loi et qu'elle constitue une mesure qui, dans une société démocratique, est nécessaire à la sécurité nationale, à la sûreté publique, au bien-être économique du pays, à la défense de l'ordre et à la prévention des infractions pénales, à la protection de la santé ou de la morale, ou à la protection des droits et libertés d'autrui.

Si cela ne suffisait pas, ce droit a été intégré dans le bloc de constitutionnalité par le Conseil constitutionnel. Il se rattache selon le Conseil constitutionnel à l’article 2 de la déclaration des droits de l’homme et du citoyen (Décision 94-352 DC du 18 janvier 1995) car il est inclus dans le mot « liberté » qui est un des droits imprescriptibles de l’homme dont le but de toute association politique est la conservation. Oui, Bernard, la vie privée est une liberté, au sens de la Constitution.

Pour les mal-comprenant, le Conseil constitutionnel l’a rappelé dans une décision n°99-416 DC du 23 juillet 1999 et plus récemment dans la décision n° 2009-580 DC du 10 juin 2009 où, dans son Considérant n°22, le Conseil dit très clairement :

    «  Considérant, en premier lieu, qu'aux termes de l'article 2 de la Déclaration de 1789 : " Le but de toute association politique est la conservation des droits naturels et imprescriptibles de l'homme. Ces droits sont la liberté, la propriété, la sûreté et la résistance à l'oppression " ; que la liberté proclamée par cet article implique le respect de la vie privée »

Fort de ce salutaire rappel que le droit à la vie privée est une liberté fondamentale, le Conseil a par cette décision censuré une grande partie du dispositif de la première loi HADOPI.

Et la condition de mauvaise foi, me direz-vous, comment l’Académie l’a-t-elle considéré comme établie ?

Tout simplement parce que parmi les signataires du recours de 2009 vilipendant à raison les atteintes à la vie privée opérée par la loi HADOPI se trouvait un député du nom de… Bernard Cazeneuve. »

« Decix, the largest internet traffic exchange point (IXP) worldwide, has had it with the snoops. Today (23 April), the Frankfurt company confirmed a report by the Sueddeutsche Zeitung that it will file a complaint at the German Federal Administrative Court against the obligation to grant broad access to the German Intelligence Service (BND) to the traffic transiting its large switches.

[...]

Decix had challenged the broad-scale tap orders as early as 2009, but did not get support from the BND oversight bodies. »

Donc ils étaient au courant et ils n'ont pas porté plainte. Et maintenant que c'est révélé sur la place publique, ho, on se bouge pour se faire bien voir. Allez, allez, allez, fichez-moi la paix avec vos arguments "ça n'arrivera jamais en Allemagne car ils ont une plus grande culture de la vie privée, Stasi, CCC, tout ça", ça ne vaut pas un clou ! Les employés du DE-CIX sont des Allemands comme les autres et visiblement, ils n'ont pas trop forcé pour révéler l'affaire.

Si le seul moyen de contre-pouvoir dont dispose un peuple c'est d'attendre qu'un lanceur d'alerte étranger se bouge puis réaction sous la contrainte, ce n'est pas sain, voilà mon propos.

Ha, et sinon, ce genre de chose n'arrive pas sur le France-IX, bien entendu : https://twitter.com/bortzmeyer/status/591606670163312641 :)))))))) D'autant que pas de réponse à ça visiblement : https://twitter.com/Turblog/status/584000276220223489

La magie de l'infrastructure de distribution x509, as usual :')

« In a major breach of public trust and confidence, the Chinese digital certificate authority China Internet Network Information Center (CNNIC) certified false credentials for numerous domains, including several owned by Google. The deliberate breach had the potential to seriously endanger vulnerable users, such as journalists communicating with sources. The breach was discovered by Google and published on its security blog on March 23. Despite this serious lapse, it appears CNNIC's authority will not be revoked, and that its credentials will continue to be trusted by almost all computers around the world.

[...]

Each CA also publishes its own documents called a certificate policy and/or certification practice statement (CP/CPS). In these, the CA describes what it will and won't do. CNNIC's CPS was controversial from the start. The practice statement noted that the CA "takes orders from the [Chinese] Ministry of Information Industry to conduct daily business."
[NDLR : sans surprise, ça a toujours été l'objet de cette AC. ]

[...]

Last week, many of those fears were realized. In violation of its certification practice statement, CNNIC delegated its certificate-signing power to Egyptian IT company MCS Holdings, according to the certificate chain, which Google published.
[ NDLR : donc maintenant, il ne s'agit plus de faire confiance à X AC dont on ne sait rien mais également à leurs X prestataires techniques... Joie. ]

[...]

The certificate could have been used to falsify credentials for any online communication. According to Google's analysis of its Certificate Transparency logs, MCS used it to do just that, falsifying certificates for several domains, including Gmail and Google's homepage, according to Microsoft security advisory. MCS said in a statement issued March 25 that it used the certificate in a system designed to intercept Internet traffic "for testing purposes."
[ NDLR : on est dans une région "à risque" (le printemps arabe n'est pas loin et la stabilité pas encore gagnée), on intercepte du trafic chiffré, on force le bypass de la phase d'authentification sur les clients (oui, l'usage d'un faux certificat pour berner l'auth, je nomme ça contournement) et on déchiffre le trafic... tout ça pour des tests... Mais bien sûr... ]

[...]

Google reported that MCS failed to use the required hardware security module. This breach could have allowed an attacker to gain access to MCS' certificate. With its certificate, attackers could have attempted to intercept any communication anywhere in the world, attacking anyone who relies on the security of the CA system. »
[ NDLR : comme dans l'histoire Lenovo... ]

Début avril : https://cpj.org/2015/04/google-revokes-authority-of-cnnic-after-breach-of-.php
« San Francisco, April 2, 2015--The Committee to Protect Journalists welcomes Google's plan to revoke the authority of root certificates belonging to China Internet Network Information Center (CNNIC) following CNNIC's major breach of the trust placed in them to underpin global Internet security. Mozilla also said it will not trust any CNNIC certificates dated after April 1, and is considering further action. »