Discussion :

[Stéphane le calme]

Le gouvernement du Kazakhstan a commencé à intercepter tout le trafic Internet HTTPS dans ses frontières,
ce qui peut créer un dangereux précédent

Depuis mercredi 17 juillet 2019, le gouvernement du Kazakhstan a commencé à intercepter tout le trafic Internet HTTPS à l'intérieur de ses frontières.

Le gouvernement local a demandé aux fournisseurs de services Internet locaux de forcer leurs utilisateurs respectifs à installer un certificat délivré par le gouvernement sur tous les appareils et dans tous les navigateurs.

Une fois installé, le certificat permettra aux administrations locales de déchiffrer le trafic HTTPS des utilisateurs, d’en visualiser le contenu, de le chiffrer à nouveau avec leur certificat et de l’envoyer à sa destination.

Les utilisateurs kazakhs essayant d'accéder à Internet depuis mercredi ont été redirigés vers des pages Web contenant des instructions sur la procédure d'installation du certificat racine du gouvernement sur leurs navigateurs respectifs, qu'il s'agisse d'un ordinateur de bureau ou d'un appareil mobile.

Le gouvernement du Kazakhstan affirme que c’est dans l’intérêt des citoyens

Les fournisseurs de services Internet locaux ont commencé à forcer leurs clients à installer le certificat racine du gouvernement à la suite d'une annonce officielle du gouvernement.

Dans un communiqué publié sur son site Web, le ministère du Développement numérique, de l'Innovation et de l'Aérospatiale du Kazakhstan a déclaré que seuls les utilisateurs d'Internet situés dans la capitale du Kazakhstan, Nur-Sultan, devront installer le certificat.

« Des organismes autorisés nous ont demandé d'informer les abonnés de Nur-Sultan de la nécessité d'établir un certificat de sécurité », a déclaré Olzhas Bibanov, responsable du service des relations publiques de Tele2 Kazakhstan. Selon lui, la demande ne concerne que les résidents de la capitale.

Le site des opérateurs Kcell et Activ a également reçu une notification d'installation d'un certificat de sécurité. « À cause des cas fréquents de vol de données personnelles et de données d’identité, ainsi que d’argent des comptes bancaires du Kazakhstan, un certificat de sécurité a été introduit. Il sera un outil efficace pour protéger l’espace d’information du pays contre les pirates, les fraudeurs sur Internet et d’autres types de cyber-menaces afin de protéger les données et les systèmes d'information. Il aidera à identifier les cybercriminels ainsi que les cyber-fraudeurs qui s’attaquent aux systèmes d'espace d'information du pays, y compris les systèmes bancaires (...) En l'absence d'un certificat de sécurité sur les appareils d'abonné, des restrictions techniques peuvent survenir avec l'accès à certaines ressources Internet », indique le communiqué sur les sites Internet des opérateurs.

Une mesure qui n’est pas cantonnée à la capitale

Si la mesure concernait officiellement la capitale dans un premier temps, des utilisateurs d’un peu partout sur le territoire ont déclaré qu’ils étaient dans l’incapacité d’accéder à internet avant d’installer le certificat du gouvernement. Selon le média local, certains utilisateurs ont également reçu des messages SMS sur leur smartphone pour leur demander d'installer les certificats.

Les opérateurs ont souligné que l'installation d'un certificat de sécurité doit être effectuée à partir de chaque appareil à partir duquel il y a un accès à Internet (téléphones mobiles et tablettes tournant sur iOS / Android, ordinateurs personnels et ordinateurs portables tournant sur Windows / MacOS). En l'absence d'un certificat de sécurité sur les périphériques d'abonné, l'accès à des ressources Internet individuelles peut être limité.

Les abonnés de Beeline (deuxième opérateur téléphonique en Russie) sont également invités à installer un certificat de sécurité. « Il est impératif de légiférer lorsque tous les appareils qui accèdent à Internet doivent recevoir un certificat de sécurité. Ce certificat a été développé par les autorités compétentes et doit être installé sur tous les appareils qui accèdent à Internet », a déclaré Alexey Benz, Corporate Communications Director à beeline.kz.

La réaction des éditeurs de navigateurs

Actuellement, les éditeurs de navigateurs tels que Google, Microsoft et Mozilla discutent d'un plan d'action sur la façon de gérer les sites qui ont été (re) chiffrés par le certificat racine du gouvernement kazakh. Aucune décision n'a été prise à l'heure actuelle.

Dans une discussion chez Mozilla, l’individu répondant au prénom Eugène suggère que cette autorité de certification figurer sur la liste noire de Mozilla et que Firefox ne devrait pas l'accepter du tout, même si l'utilisateur l'a installée manuellement. Il estime que cela préservera la vie privée de tous les utilisateurs d'Internet au Kazakhstan.

Plus loin, il en appelle à la collaboration entre Mozilla et Google :

« Je pense que Mozilla et Google devraient intervenir dans cette situation, car elle peut créer un précédent dangereux, annulant tous les efforts de renforcement de HTTPS.

« Si le Kazakhstan réussit, de plus en plus de gouvernements (par exemple, la Fédération de Russie, l'Iran, etc.) lanceront des attaques mondiales de MITM contre leurs citoyens, ce qui n'est pas bon.

« Je pense que toutes les autorités de certification utilisées pour les attaques MITM devraient être explicitement inscrites sur la liste noire de Mozilla et de Google, afin d’exclure toute possibilité de telles attaques ».

Le gouvernement n’en est pas à sa première tentative

Le gouvernement kazakh a d'abord tenté de faire installer un certificat racine par tous ses citoyens en décembre 2015. À l'époque, il avait décidé que tous les utilisateurs kazakhs devaient installer leur certificat racine le 1er janvier 2016 au plus tard.

La décision n'a jamais été mise en œuvre car plusieurs organisations, dont des FAI, des banques et des gouvernements étrangers, ont poursuivi le gouvernement en justice, craignant d'affaiblir la sécurité de tout le trafic Internet (et des entreprises adjacentes) en provenance du pays.

Parallèlement, en décembre 2015, le gouvernement kazakh a également demandé à Mozilla que son certificat racine soit inclus par défaut dans Firefox, mais Mozilla a décliné l'offre.

Sources : média local, Bugzilla, Google Group, Kazakhtelecom

Voir aussi :

Fournir un DNS plus sécurisé ne fait pas de nous des méchants, répond Mozilla à l'association des FAI du Royaume-Uni au sujet du DNS-over-HTTPS
Trolldi : Mozilla nominé parmi les "Internet Villain" par l'ISPA britannique pour son support de DNS-over-HTTPS, aux côtés de l'article 13 et de Trump
Chrome pour Android chargerait les pages HTTPS plus vite sur des connexions lentes grâce à une mise à jour de la fonctionnalité Data Saver
DNS-over-HTTPS : Mozilla estime que les premiers essais ont été réussis et va étendre le test à d'autres utilisateurs de Firefox

[bk417]

Il faut que Google, Microsoft et Mozilla réagissent rapidement et de façon groupée si ils veulent que cette tentative d'espionnage échoue.
Blacklister le CA ou l'autoriser et rajouter une alerte visuelle permanente dans le navigateur.

Mais bon ce n'est qu'une étape, la prochaine étape sera que le gouvernement imposera carrément d'utiliser leur navigateur trafiqué (un Google chrome patché par ex.) pour avoir accès au net.

A long terme, il faudrait peut-être pousser l'utilisation des CAA dans les enregistrement DNS (chiffrés et validés DNSSEC bien sûr), qui liste les Autorité de Certification autorisées à émettre un certif pour chaque domaine.

[Aurelien Plazzotta]

IPFS (i.d. InterPlanetary FileSystem) devient de plus en plus facile à justifier pour remplacer le Web. Il s'agit d'un protocole de transmission hypermedia décentralisé et résiliant à la censure en développement depuis 2015. Vous pouvez lire les grandes lignes du projet sur ipfs.io et lire la documentation sur https://docs.ipfs.io/

Wikipedia a pu être répliqué durant je ne sais quelle période et les sites web de l'indépendance catalane ont pu être sauvé durant 2017 suite à une campagne d'obscurantisme du gouvernement espagnol.
IPFS peut être installé sur disque dur avec une implémentation en Go ou via une extension du navigateur écrite en Javascript.

Veuillez noter que IPFS est en Alpha.

Vous pouvez découvrir le fonctionnement du système en visionnant une vidéo de 10 minutes ici:

Il existe également la technologie Gopher, autre protocole de transmission décentralisé concurrent du Web, et créé en 1991. Il revient en force depuis des années mais je ne crois pas vraiment à sa résurgence https://en.wikipedia.org/wiki/Gopher_%28protocol%29 que j'ai pu brièvement tester via son extension Firefox OverbiteWX: https://addons.mozilla.org/en-US/fir...on/overbitewx/

à bk417:
Chrome est déjà un navigateur trafiqué, il s'agit d'une surcouche logicielle propriétaire ajoutée depuis Chromium.

[mh-cbon]

IPFS (i.d. InterPlanetary FileSystem) devient de plus en plus facile à justifier pour remplacer le Web. Il s'agit d'un protocole de transmission hypermedia décentralisé et résiliant à la censure en développement depuis 2015. Vous pouvez lire les grandes lignes du projet sur ipfs.io et lire la documentation sur https://docs.ipfs.io/
...

quelle différence fais tu entre ipfs et tor ? pourquoi préféré promouvoir ipfs qui est encore alpha là ou tor est déjà bien rodé ?

[Jon Shannow]

« Si le Kazakhstan réussit, de plus en plus de gouvernements (par exemple, la Fédération de Russie, l'Iran, etc.) lanceront des attaques mondiales de MITM contre leurs citoyens, ce qui n'est pas bon.

Ils ont oublié de cité la France, les USA, ... qui ont des gouvernements à tendances fascistes...

[Marco46]

Ce procédé est malheureusement un grand classique en entreprise. Cf corporate proxy man in the middle.

Appliquer la chose à tout un pays c'est un peu beaucoup bourrin et ça doit demander une sacré infra pour tenir la charge. Je ne pense pas que ça soit faisable à l'échelle d'un pays comme la France sans couter une fortune en investissement et en exploitation.

[Aurelien Plazzotta]

Le cycle de développement d'un projet est moins important que son périmètre en ce qui me concerne.
IPFS reprend les bonnes pratiques de Tor pour l'anonymisation des noeuds mais permet en plus d'émettre et non seulement recevoir.
Avec Tor, l'utilisateur passe d'abord par un site web pour récupérer les metadonnées, mis en ligne par un hébergeur, lui-même propulsé par un fournisseur d'accès, lui-même approuvé par une autorité centrale (e.g. Verizon).

Avec IPFS, vous devenez vous-même hébergeur de contenu. Et si votre voisin héberge des données qui vous intéresse, l'algortihme de recherche du chemin le plus court (i.d. Merkle Dag si j'ai bien compris), permet de télécharger directement sur lui au lieu de pomper sur un réseau de diffusion de contenu (i.d. Content Delivery Network) ou sur un serveur à l'autre bout de la planète, pouvant tous deux être soumis à des censures, des problèmes de latence ou de bande passante.

Pour les détails techniques, je suis incapable de vous répondre.

J'ajoute l'URI d'un article intéressant concernant la nécessité d'un réseau permanent: https://www.wired.com/2016/06/invent...permanent-web/

[mh-cbon]

Le cycle de développement d'un projet est moins important que son périmètre en ce qui me concerne.
IPFS reprend les bonnes pratiques de Tor pour l'anonymisation des noeuds mais permet en plus d'émettre et non seulement recevoir.
Avec Tor, l'utilisateur passe d'abord par un site web pour récupérer les metadonnées, mis en ligne par un hébergeur, lui-même propulsé par un fournisseur d'accès, lui-même approuvé par une autorité centrale (e.g. Verizon).

Avec IPFS, vous devenez vous-même hébergeur de contenu. Et si votre voisin héberge des données qui vous intéresse, l'algortihme de recherche du chemin le plus court (i.d. Merkle Dag si j'ai bien compris), permet de télécharger directement sur lui au lieu de pomper sur un réseau de diffusion de contenu (i.d. Content Delivery Network) ou sur un serveur à l'autre bout de la planète, pouvant tous deux être soumis à des censures, des problèmes de latence ou de bande passante.

Pour les détails techniques, je suis incapable de vous répondre.

J'ajoute l'URI d'un article intéressant concernant la nécessité d'un réseau permanent: https://www.wired.com/2016/06/invent...permanent-web/

mmhhh avec tor aussi on peut émettre. Et les limitations techniques imposées à nos box sont les mêmes que l'on utilise le clearweb, tor ou ipfs.

[mh-cbon]

Ce procédé est malheureusement un grand classique en entreprise. Cf corporate proxy man in the middle.

Appliquer la chose à tout un pays c'est un peu beaucoup bourrin et ça doit demander une sacré infra pour tenir la charge. Je ne pense pas que ça soit faisable à l'échelle d'un pays comme la France sans couter une fortune en investissement et en exploitation.

t'es pas obligé d'écouter tout le réseau en permanence, le système pourrait éventuellement n’être utiliser ou activer que si l'utilisateur est ciblé par une motivation politique ou une action indicatrice de sa navigation "litigieuse".

moi de ce que je comprends on parle seulement de foutre un certificat dans tous les ordis du pc pour se donner les moyens d'un mitm.

[mh-cbon]

Ils ont oublié de cité la France, les USA, ... qui ont des gouvernements à tendances fascistes...

c'est clair! j'en parles même plus tellement ça me fatigue les esprits aussi étriqués.

[sekaijin]

j'avoue ne pas bien saisir

lorsque un internaute se connecte au réseau il passe par son fai et qu'il impose un certificat n'est pas aberrant.
ensuite lorsque on demande une url il ya la résolution de l'adresse. la encore cest entre le client et le fai.
mais ensuite le client échange un certificat avec le serveur pas avec le fai.
et le codage ne ce fait pas avec le certificat du fait ni avec le certificat racine du client

mais avec une clef créée par le seveur et un clef dynamique créée par le client. la clef serveur est signée avec le certificat serveur et la clef client avec un certificat du client.

je ne vois pas comment un certificat racine qui ne connaît aucune des clefs de codage pourait decoder le trafic.


c'est en revanche beaucoup plus inquiétant pour tous ceux qui consulte leur webmail ou autre site de leur fai au Kazakhstan.

je vous dirait ca a mon retour.
A+JYT

[Neckara]

@sekaijin : C'est très simple, avec un certificat racine, tu peux émettre un certificat valide pour tout site.

Ainsi, il suffit de te mettre entre le site et l'utilisateur, et de présenter à l'utilisateur ton propre certificat, ainsi, tu pourras lire et envoyer des messages à l'utilisateur. Il ne suffit ensuite que rediriger les messages vers/en provenance du serveur en utilisant le vrai certificat en se faisant passer pour l'utilisateur, et le tour est joué.

[Jiji66]

j'avoue ne pas bien saisir

lorsque un internaute se connecte au réseau il passe par son fai et qu'il impose un certificat n'est pas aberrant.
ensuite lorsque on demande une url il ya la résolution de l'adresse. la encore cest entre le client et le fai.
mais ensuite le client échange un certificat avec le serveur pas avec le fai.
et le codage ne ce fait pas avec le certificat du fait ni avec le certificat racine du client

mais avec une clef créée par le seveur et un clef dynamique créée par le client. la clef serveur est signée avec le certificat serveur et la clef client avec un certificat du client.

je ne vois pas comment un certificat racine qui ne connaît aucune des clefs de codage pourait decoder le trafic.


c'est en revanche beaucoup plus inquiétant pour tous ceux qui consulte leur webmail ou autre site de leur fai au Kazakhstan.

je vous dirait ca a mon retour.
A+JYT

Moi je comprends trés bien pourquoi ils interceptent tout.

https://fr.wikipedia.org/wiki/Attaqu...omme_du_milieu

[mh-cbon]

Moi je comprends trés bien pourquoi ils interceptent tout.

https://fr.wikipedia.org/wiki/Attaqu...omme_du_milieu

ouais ! j'avais pas vu!! il nous parle de webmail qd on lui cause mitm. mmhhhh comment dire. je veux pas railler mais là c'est gros. la macronie à de l'avenir ^^ (c'est un propos haineux ca ? rofl je sais pas..)

[sekaijin]

si ma mémoire ne me fait pas défaut
il y a quelque temps déjà que les handshake TLS on été revu pour justement éviter l'attaque par l'homme du milieu.

il est vrai que cette phase de négociation dans l'échange est la plus vulnérable.
Je ne dis pas que l'attaque est impossible mais elle est difficile. et ce n'est pas un certificat racine vérolé émis par un tiers qui n'entre pas en compte dans la négociation qui change la donne.

Vous avez des dizaines de certificat racine sur vos machine et heureusement si l'un d'eux est compromis ça ne remets pas en cause la sécurité globale mais seulement de ceux qui utilise ce certificat.

de plus un certificat racine ne sert pas (ne doit jamais servir) à crypter les données. il ne sert qu'a vérifier la validité d'un certificat émis par un autre et signé par cette racine.

j'ai 3 certificats racine A, B, C (C est compromis)
je contacte un serveur qui m'envoie sont certificat a signé par A
je vérifie que a est authentique
nous négocions un couple de clefs
nous obtenons une clef de codage Z
nous cryptons nos échange avec cette clef.

à aucun moment le certificat Racine C n'est entré en jeux.

je contacte un serveur qui m'envoie sont certificat c signé par C
je vérifie que c est authentique
nous négocions un couple de clefs
nous obtenons une clef de codage Z
nous cryptons nos échange avec cette clef.

vu que C est compromis je ne suis pas sur que c soit authentique
mais l'émetteur de C ne peux toujours pas décoder les échange


je contacte un serveur qui m'envoie sont certificat d signé par C mais généré par l'éditeur de C et qui est lui aussi compromis
je vérifie que d est authentique
nous négocions un couple de clefs
nous obtenons une clef de codage Z
nous cryptons nos échange avec cette clef.

vu que C est compromis je ne suis pas sur que d soit authentique
et comme d est lui aussi compromis les clefs générées sont potentiellement poreuse et les échange peuvent être décodé sans trop de difficulté.

à moins que le Kazakhstan impose à tous les site internet du pays d'utiliser un certificat émis par le gouvernement sur tous leurs site web il ne pourront pas aussi facilement décrypter les échanges.
quant à l'imposer au reste du monde c'est une utopie.

donc Oui c'est sérieux car c'est un précédent politique et oui cela est un élément essentiel pour mettre en place une écoute à grande échelle. en soit ce n'est pas suffisant. c'est une atteinte aux libertés individuelles etc.

Mais ce n'est pas une raison suffisante pour paniquer.
A+JYT

[Neckara]

il y a quelque temps déjà que les handshake TLS on été revu pour justement éviter l'attaque par l'homme du milieu.

Si tu ne peux pas t'assurer d'authentifier correctement le serveur, tu ne peux pas éviter l'attaque par l'homme du milieu.

Or, quand une personne possède un certificat racine, il peut générer tous les certificats qu'il veut, c'est à dire se faire passer pour n'importe quel serveur.

de plus un certificat racine ne sert pas (ne doit jamais servir) à crypter les données. il ne sert qu'a vérifier la validité d'un certificat émis par un autre et signé par cette racine.

Chiffrer les données.

Ensuite, c'est justement là tout le problème, le certificat racine sert à certifier que des certificats ont été signés par le CA.
C'est à dire qu'il va dire "tous les certificats émis par X sont valides". Or, si un CA agit mal, il peut émettre des certificats se déclarant Y pour e.g. son propre compte. C'est à dire que le CA sera capable de se faire passer pour Y.

à moins que le Kazakhstan impose à tous les site internet du pays d'utiliser un certificat émis par le gouvernement sur tous leurs site web il ne pourront pas aussi facilement décrypter les échanges.

Pas besoin, il suffit de se mettre au milieu…

Au niveau du routage IP de dire que tous les paquets doivent passer par certains serveurs. Et ces serveurs là utiliseront des certificats frauduleux pour se mettre entre le client et le serveur.

[Marco46]

j'ai 3 certificats racine A, B, C (C est compromis)
je contacte un serveur qui m'envoie sont certificat a signé par A
je vérifie que a est authentique
nous négocions un couple de clefs
nous obtenons une clef de codage Z
nous cryptons nos échange avec cette clef.

à aucun moment le certificat Racine C n'est entré en jeux.

Sauf que tu ne te connectes pas au serveur de A mais à C qui est un proxy dans le réseau du FAI entre toi et le service A. Et C lui se connecte à A et peut donc à loisir inspecter tout ce qui passe au milieu.

Tout se passe de manière transparente pour l'utilisateur, il aura un joli cadenas vert dans la barre d'adresse de son site web.

Si l'utilisateur examine les infos du certificat et remonte la chaîne il constatera que toute la chaîne a été émise par le certificat racine de C.

Si tu bosses dans un grand compte je t'invite à faire le test, c'est très fréquent (milieu bancaire notamment).

Évidemment ça suppose d'avoir le certificat racine de C préalablement installé dans tous les magasins de certificats de la machine de l'utilisateur (système et navigateurs).

D'où la demande du Kazakhstan pour l'installation obligatoire du certificat et la question qui se pose pour les éditeurs des navigateurs. S'ils blacklistent le certificat racine du Kazakhstan ils n'auront plus qu'à réécrire un navigateur ou gérer un fork eux-mêmes.

à moins que le Kazakhstan impose à tous les site internet du pays d'utiliser un certificat émis par le gouvernement sur tous leurs site web il ne pourront pas aussi facilement décrypter les échanges.
quant à l'imposer au reste du monde c'est une utopie.

Les FAI du Kazakhstan n'ont pas besoin de faire ça puisque les flux transitent chez eux. Ils sont déjà au milieu, donc ils font bien ce qu'ils veulent soit au niveau de la résolution de leurs DNS soit sur la gestion du trafic IP directement.

[bk417]

la question qui se pose pour les éditeurs des navigateurs. S'ils blacklistent le certificat racine du Kazakhstan ils n'auront plus qu'à réécrire un navigateur ou gérer un fork eux-mêmes.

Je pense que blacklister le certificat racine est une première solution qui doit être faite, tous les navigateurs ensemble. Fait au niveau d'un état, c'est clairement une atteinte qui doit être combattue.
Que le gouvernement crée ensuite des fork et les publie sur toutes les machines et tel mobiles, c'est une autre paire de manche et ils vont bien galérer.

[Stéphane le calme]

L'interception HTTPS du Kazakhstan cible déjà des domaines comme ceux de Facebook, Twitter et Google,
soulevant des craintes chez les chercheurs

Qu'est-ce qu'une interception HTTPS ?

HTTPS sécurise la communication entre les navigateurs et les sites Web en chiffrant la communication, empêchant les fournisseurs de services Internet et les gouvernements de la lire ou de la modifier. Les serveurs prouvent leur identité en présentant des certificats signés numériquement par des autorités de certification (CA), des entités sur lesquelles les navigateurs Web ont confiance pour garantir l'identité des sites. Par exemple, facebook.com fournit aux navigateurs un certificat signé par DigiCert, une autorité de certification approuvée et intégrée à pratiquement tous les navigateurs. Les navigateurs peuvent savoir qu'ils parlent au vrai facebook.com en validant le certificat présenté et en confirmant qu'il est signé par une autorité de certification en laquelle ils ont confiance (DigiCert). Le certificat fourni par facebook.com contient également une clé cryptographique publique utilisée pour sécuriser les communications ultérieures entre le navigateur et Facebook.

Dans une attaque par interception HTTPS (une sorte d'attaque de type «homme au milieu» ou MitM), un adversaire intégré au réseau prétend être un site Web (par exemple, facebook.com) et présente son propre faux certificat avec la clé publique de l'attaquant. En règle générale, l’attaquant ne peut pas obtenir une signature de certificat de l’autorité de certification légitime pour un domaine qu’il ne contrôle pas. Les navigateurs vont donc détecter et déjouer ce type d’attaque. Toutefois, si l’attaquant parvient à convaincre les utilisateurs d’installer un nouveau certificat racine dans leur navigateur, ceux-ci feront confiance aux faux certificats de l’attaquant signés par cette autorité de certification illégitime. Avec ces faux certificats, l'attaquant peut emprunter l'identité de n'importe quel site Web, en modifiant son contenu ou en enregistrant exactement ce que les utilisateurs font ou affichent sur le site.

Le cas du Kazakhstan

Depuis mercredi 17 juillet 2019, le gouvernement du Kazakhstan a commencé à intercepter tout le trafic Internet HTTPS à l'intérieur de ses frontières. Le gouvernement local a demandé aux fournisseurs de services Internet locaux de forcer leurs utilisateurs respectifs à installer un certificat délivré par le gouvernement sur tous les appareils et dans tous les navigateurs.

Une fois installé, le certificat permettra aux administrations locales de déchiffrer le trafic HTTPS des utilisateurs, d’en visualiser le contenu, de le chiffrer à nouveau avec leur certificat et de l’envoyer à sa destination.

Les utilisateurs kazakhs essayant d'accéder à Internet depuis mercredi ont été redirigés vers des pages Web contenant des instructions sur la procédure d'installation du certificat racine du gouvernement sur leurs navigateurs respectifs, qu'il s'agisse d'un ordinateur de bureau ou d'un appareil mobile.

Les détails ont été rares au cours des premiers jours qui ont suivi l'interception des interceptions HTTPS. Cependant, une nouvelle étude publiée cette semaine par Censored Planet fournit un aperçu plus détaillé de ce qui se passe dans le pays. Selon l'organisation, l'interception HTTPS ne concerne actuellement que 37 domaines (sur environ 1000 qui ont été testés), tous étant des réseaux sociaux et des sites de communication, tels que les domaines Facebook, Google, Twitter, Instagram, YouTube et VK, ainsi que quelques sites plus petits.

La liste complète des sites interceptés est disponible ci-dessous (regroupés par service et non par ordre alphabétique):

• android.com
• messages.android.com
  ------------------------------------
• goo.gl
• google.com
• www.google.com
• allo.google.com,
• dns.google.com
• docs.google.com
• encrypted.google.com
• mail.google.com
• news.google.com
• picasa.google.com
• plus.google.com
• sites.google.com
• translate.google.com
• video.google.com
• groups.google.com
• hangouts.google.com
  ------------------------------------
• youtube.com
• www.youtube.com
  ------------------------------------
• facebook.com
• www.facebook.com
• messenger.com
• www.messenger.com
  ------------------------------------
• instagram.com
• www.instagram.com
• cdninstagram.com
  ------------------------------------
• twitter.com
  ------------------------------------
• vk.com
• vk.me
• vkuseraudio.net
• vkuservideo.net
  ------------------------------------
• mail.ru
• ok.ru
• rukoeb.com
• sosalkino.tv
• tamtam.chat

Un système d'interception encore en cours de test

Selon Censored Planet, les fournisseurs de services Internet locaux ne semblent pas participer dans leur totalité aux interceptions HTTPS pour le moment. Malgré la preuve que plusieurs fournisseurs de services Internet kazakhs contraignaient les utilisateurs à installer le certificat racine du gouvernement, Censored Planet a constaté que seul Kazakhtelecom (AS 9198 KazTelecom) interceptait activement les connexions HTTPS.

De plus, les interceptions HTTPS ne se produisent pas tout le temps. « Cela indique que le système d'interception est toujours en cours de test ou de mise au point, peut-être comme un précurseur d'un déploiement plus large », ont déclaré les chercheurs de Censored Planet.

L’équipe Censored Planet, qui comprend également des universitaires de l’Université du Michigan et de l’Université du Colorado, Boulder, a publié des informations détaillées sur la manière dont d’autres chercheurs peuvent étudier le phénomène de l’extérieur du pays et suivre les efforts d’espionnage du gouvernement kazakh.

Dans un communiqué, le gouvernement a expliqué : « À cause des cas fréquents de vol de données personnelles et de données d’identité, ainsi que d’argent des comptes bancaires du Kazakhstan, un certificat de sécurité a été introduit. Il sera un outil efficace pour protéger l’espace d’information du pays contre les pirates, les fraudeurs sur Internet et d’autres types de cyber-menaces afin de protéger les données et les systèmes d'information. Il aidera à identifier les cybercriminels ainsi que les cyber-fraudeurs qui s’attaquent aux systèmes d'espace d'information du pays, y compris les systèmes bancaires (...) En l'absence d'un certificat de sécurité sur les appareils d'abonné, des restrictions techniques peuvent survenir avec l'accès à certaines ressources Internet ».

Censored Planet prévient que « L’interception HTTPS du Kazakhstan affaiblit la sécurité et la confidentialité des utilisateurs Internet du pays. Bien que l'interception ne se produise pas encore dans tout le pays, il semble que le gouvernement soit à la fois disposé et potentiellement capable d'intercepter largement le protocole HTTPS dans un proche avenir. La communauté internationale doit surveiller de près cette pratique alarmante, qui va à l’encontre des décennies de progrès de la communauté de la sécurité informatique pour garantir que tous les sites Web sont protégés par un chiffrement puissant de bout en bout ».

Source : Censored Planet

Voir aussi :

Fournir un DNS plus sécurisé ne fait pas de nous des méchants, répond Mozilla à l'association des FAI du Royaume-Uni au sujet du DNS-over-HTTPS
Trolldi : Mozilla nominé parmi les "Internet Villain" par l'ISPA britannique pour son support de DNS-over-HTTPS, aux côtés de l'article 13 et de Trump
Chrome pour Android chargerait les pages HTTPS plus vite sur des connexions lentes grâce à une mise à jour de la fonctionnalité Data Saver
DNS-over-HTTPS : Mozilla estime que les premiers essais ont été réussis et va étendre le test à d'autres utilisateurs de Firefox

[tanaka59]

Je suis surpris de ne pas voir Yandex ...

Et ces 17 noms de domaines associés ?!

pseudo@ ...

"@yandex.com"
"@yandex.ru"
"@yandex.ua"
"@yandex.kz"
"@yandex.by"
"@yandex.uz"
"@yandex.tj"
"@yandex.az"
"@yandex.lv"
"@yandex.ee"
"@yandex.lt"
"@yandex.fr"
"@yandex.tm"
"@yandex.md"
"@yandex.com.tr"
"@ya.ru"
"@yandex.com.ge"
"@yandex.com.am"
"@yandex.tm"