Roundup de sécurité de septembre 2020

Bienvenue dans l'édition de septembre du Security Roundup mensuel de SSL.com! Aujourd'hui, nous allons parler de:

• Le tout nouveau SSL.com Newsletter
• Modifications apportées aux forums CA / B Directives SSL EV
• Les plans de la Russie protocoles d'interdiction qui cachent la destination du trafic Internet
• La Attaque de raton laveur on TLS versions 1.2 et antérieures
• Peu sûr Internet des Objets (IoT) pratiques
  

Annonce de la newsletter SSL.com!

SSL.com est fier d'annoncer notre nouvelle newsletter mensuelle! Chaque mois, nous vous enverrons des nouvelles et des informations sur la sécurité Internet, PKIet des certificats numériques, ainsi que des informations sur les nouveaux produits et services proposés par SSL.com. Pour vous inscrire, remplissez simplement le formulaire ci-dessous. (Vous pouvez facilement vous désinscrire à tout moment en cliquant sur le vous désabonner lien dans chaque e-mail que nous envoyons.):

CA / B Forum Ballot SC30: Modifications des directives de certificat SSL EV

Dans l'actualité d'intérêt pour SSL.com SSL EV clients, la version actuelle (1.7.3) du forum CA / Browser Directives relatives au certificat SSL EV, qui est entré en vigueur le 20 août 2020, a de nouvelles exigences. Plus précisément, comme décrit dans le forum CA / B Bulletin SC30, les autorités de certification (CA), telles que SSL.com, doivent désormais publier la liste des agences d'enregistrement et d'intégration qu'elles utilisent lors de la validation des demandes de certificat SSL EV. (Cette décision s'inscrit dans un objectif plus large de rendre les sources de validation EV cohérentes entre les AC.)

En conséquence, SSL.com publiera une liste des sources d'informations que nous utilisons lors de la validation des entreprises et autres organisations pour les certificats EV. Lorsque nous ne parvenons pas à localiser l'organisation d'un candidat dans notre liste actuelle de sources, nous tenterons de localiser une autre source d'informations viable et de l'ajouter à notre liste publiée avant de valider la commande et d'émettre le certificat.

La Russie envisage d'interdire les protocoles qui masquent la destination du trafic

Cette histoire peut vous sembler familière, si vous vous êtes tenu au courant des nouvelles de la sécurité numérique. En fait, le mois dernier nous avons signalé sur une histoire selon laquelle le «grand pare-feu» chinois bloque désormais le trafic HTTPS qui utilise TLS 1.3 et ENSI (Encrypted Server Name Indication) dans le but de permettre aux censeurs chinois de voir plus facilement les sites que les citoyens tentent de visiter et de contrôler l'accès à ces sites.

Ce mois-ci, un rapport de Catalin Cimpanu dans ZDNet a expliqué que la Russie cherche maintenant à interdire l'utilisation de certains protocoles avec une mise à jour des lois technologiques qui «rendrait illégal l'utilisation de protocoles de cryptage qui masquent complètement la destination du trafic. Comme indiqué dans l'article, ces protocoles comprendraient TLS 1.3 DoH, DoT et ESNI. Le raisonnement est, bien sûr, un peu comme le raisonnement derrière l'interdiction de la Chine - les protocoles entravent la surveillance et la portée de la censure par l'État. De l'article:

La Russie n'utilise pas de système de pare-feu national, mais le régime de Moscou repose sur un système appelé SORM qui permet aux forces de l'ordre d'intercepter le trafic Internet à des fins d'application de la loi directement à la source, dans les centres de données des télécommunications.
En outre, le ministère russe des télécommunications, le Roskomnadzor, a géré de facto un pare-feu national par le biais de son pouvoir réglementaire sur les FAI locaux. Au cours de la dernière décennie, Roskomnadzor a interdit les sites Web qu'il jugeait dangereux et a demandé aux FAI de filtrer leur trafic et de bloquer l'accès aux sites respectifs.
Avec TLS 1.3, DoH, DoT et ESNI étant adoptés, tous les outils de surveillance et de censure actuels de la Russie deviendront inutiles, car ils dépendent de l'accès aux identifiants de site Web qui fuient à partir du trafic Web crypté.

La loi est actuellement à l'étude, dans l'attente des commentaires du public, et reviendra pour un vote début octobre. ZDNet note que, compte tenu du climat, "il est presque certain que l'amendement sera adopté."

Nouveauté TLS Attaque: raton laveur

Nous avons déjà un blog à propos de «l'attaque de raton laveur», mais cela vaut la peine de le mentionner à nouveau car l'attaque peut permettre à des tiers de casser SSL /TLS cryptage pour lire les communications destinées à être sécurisées. Comme expliqué dans un récent document académique, l'attaque exploite une vulnérabilité de timing dans TLS versions 1.2 et antérieures, et pourrait décrypter les communications comprenant les noms d'utilisateur, les mots de passe, les données de carte de crédit et d'autres informations sensibles. D'après notre article plus tôt ce mois-ci:

Bien que cela semble terrifiant, gardez à l'esprit que cette attaque ne peut avoir lieu que dans des circonstances très spécifiques et rares: le serveur doit réutiliser les clés Diffie-Hellman publiques dans le poignée de main (déjà considéré comme une mauvaise pratique), et l'attaquant doit être capable de faire des mesures de timing précises. De plus, le navigateur doit prendre en charge les suites de chiffrement vulnérables (à partir de juin 2020, tous les principaux navigateurs les ont abandonnées).

L'Internet des objets (vulnérables), édition Coffee Maker

Alors que l'histoire ci-dessus n'était pas actually sur les attaques de ratons laveurs, cette histoire concerne en réalité les cafetières. Pour être plus précis, l'article de Dan Goodin dans Ars Technica c'est comment une cafetière a été transformée en «machine à rançon» en exploitant les faiblesses courantes des appareils de l'Internet des objets (IoT).

Fondamentalement, iKettle (mal nommée) des produits plus intelligents est depuis longtemps une cible pour ceux qui cherchent à illustrer les dangers des appareils facilement piratés. Depuis 2015, les versions de la bouilloire ont été réquisitionnés à distance grâce à la rétro-ingénierie. Bien que la société ait publié une nouvelle version du pot depuis lors, les anciennes sont toujours utilisées et sont-elles vulnérables à ce que l'article note comme des attaques «hors de la boîte». Récemment, un programmeur nommé Martin Hron a décidé de tester les limites de ce à quoi pourrait ressembler une faille de sécurité sur une cafetière, dans le pire des cas:

Lorsque Hron a branché sa cafetière Smarter pour la première fois, il a découvert qu'elle agissait immédiatement comme un point d'accès Wi-Fi qui utilisait une connexion non sécurisée pour communiquer avec une application pour smartphone. L'application, à son tour, est utilisée pour configurer l'appareil et, si l'utilisateur le souhaite, le connecter à un réseau Wi-Fi domestique. Sans cryptage, le chercheur n'a eu aucun problème à apprendre comment le téléphone contrôlait la machine à café et, comme il n'y avait pas non plus d'authentification, comment une application de téléphone malveillante pouvait faire la même chose.
Cette capacité ne laissait toujours à Hron qu'un petit menu de commandes, aucune d'elles particulièrement nuisible. Il a donc examiné le mécanisme utilisé par la cafetière pour recevoir les mises à jour du firmware. Il s'est avéré qu'ils ont été reçus du téléphone avec - vous l'avez deviné - aucun cryptage, aucune authentification et aucune signature de code.

Il existe un article de blog complet sur le piratage de la cafetière intitulé "L'odeur fraîche du café racheté. » Il y a aussi une vidéo amusante démontrant le chaos qui a découlé de l'exploitation des vulnérabilités de la machine à café. Bien qu'il soit peu probable qu'une telle attaque se produise bientôt dans la cuisine de qui que ce soit, c'est un bon rappel que «intelligent» signifie plus que «pratique».