en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Résumé de la sécurité de décembre 2020

SSL.com souhaite à tous nos clients et visiteurs un temps des fêtes heureux, sûr et sain, et une année 2021 prospère! Nous espérons que la nouvelle année sera un peu moins, euh… intéressant que 2020 a été à certains égards, mais nous sommes sûrs qu'il ne se passera pas un mois sans nouvelles importantes du monde de la sécurité des réseaux, des certificats numériques et PKI.

Vulnérabilité OpenSSL DoS

Nous avons couvert ce problème dans un billet de blog plus tôt ce mois-ci, mais cela vaut la peine de le répéter. Une vulnérabilité de haute gravité dans OpenSSL a été découvert qui affecte toutes les versions d'OpenSSL 1.0.2 et 1.1.1 antérieures à 1.1.1i. Cette vulnérabilité pourrait être exploitée pour créer une attaque par déni de service (DoS). OpenSSL 1.1.1i, publié le 8 décembre 2020, comprend un correctif.

Les utilisateurs d'OpenSSL doivent mettre à jour leurs installations dès que possible. Il existe deux chemins pour appliquer le correctif:

  • Les utilisateurs d'OpenSSL 1.1.1 et les utilisateurs non pris en charge 1.0.2 doivent passer à la version 1.1.1i.
  • Les clients du support Premium d'OpenSSL 1.0.2 doivent passer à la version 1.0.2x.

OpenSSL est actuellement installé sur la majorité des serveurs Web HTTPS. Vous pouvez en savoir plus sur la vulnérabilité dans SSL.com blog, et dans le projet OpenSSL Avis de sécurité.

À retenir de SSL.com: Si vous êtes un utilisateur d'OpenSSL et que vous ne l'avez pas déjà fait, veuillez lire OpenSSL's consultatif sur la vulnérabilité et mettez à jour votre installation dès que possible.

Cloudflare préconise de nouveaux protocoles de confidentialité

Tim Anderson rapporté dans The Register que Cloudflare «fait pression pour l'adoption de nouveaux protocoles Internet, il affirme permettre un« Internet respectueux de la vie privée ».» Ces protocoles incluent une DNS sur HTTPS (DoH), cryptage supplémentaire pour le TLS poignée de mainet des améliorations de sécurité pour la gestion des mots de passe utilisateur.

DoH inconscient

DNS sur HTTPS (DoH) résout un maillon faible de la confidentialité sur Internet en chiffrant les requêtes et réponses DNS, qui ont été historiquement envoyées en texte clair. DoH inconscient (ODoH)  va encore plus loin dans la protection de la confidentialité DNS en empêchant les serveurs DoH de connaître l'adresse IP du client:

L'essence d'ODoH est qu'elle introduit un proxy réseau entre le client et le serveur DoH. Le proxy n'a aucune visibilité sur la requête DNS, qui ne peut être lue que par le serveur DoH. Le serveur n'a pas connaissance de l'adresse IP du client. La requête est privée, à condition que le proxy et le serveur ne s'entendent pas.

Cloudflare a déjà déclaré la prise en charge d'ODoH, qui a été développé par des ingénieurs de Cloudflare, Apple et Fastly. Vous pouvez en savoir plus en consultant leur papier sur arxiv.org.

Client crypté Hello (ECH)

Client crypté Hello (ECH) offre un cryptage amélioré de la poignée de main TLS, Aller plus loin SNI crypté (ESNI), qui protège uniquement l'indication du nom du serveur (SNI) dans le TLS poignée de main. Ingénieur de recherche Cloudflare Christopher Patton écrit,

Bien qu'ESNI ait fait un pas en avant significatif, il ne parvient pas à atteindre notre objectif de chiffrement complet de la négociation. En plus d'être incomplet - il ne protège que le SNI - il est vulnérable aux une poignée d'attaques sophistiquées, qui, bien que difficiles à réaliser, indiquent des faiblesses théoriques dans la conception du protocole qui doivent être corrigées.
...
En fin de compte, l'objectif d'ECH est de garantir que TLS les connexions établies avec différents serveurs d'origine derrière le même fournisseur de services ECH sont indiscernables les unes des autres.

Sans surprise, étant donné qu'ECH «n'a de sens qu'aux côtés de DoH, et dans le contexte d'un CDN (réseau de distribution de contenu)», Cloudflare «se considère comme un fournisseur ECH probable». Vous pouvez en savoir plus sur l'ECH dans l'IETF projet de proposition.

Mots de passe OPAQUE

Les mots de passe OPAQUE - «une sorte de jeu de mots sur la fonction pseudo-aléatoire oubliée (OPRF) combinée à l'échange de clé authentifiée par mot de passe (PAKE)» - est un mécanisme pour éviter complètement le transfert du mot de passe d'un utilisateur vers un serveur. OPAQUE y parvient en «demandant au serveur et au client de calculer conjointement un hachage salé à comparer en utilisant un second sel intermédiaire. Cela garantit que le serveur ne peut pas apprendre le mot de passe de l'utilisateur lors de l'authentification et que l'utilisateur n'apprend pas le sel secret du serveur. »

Pour en savoir plus sur les mots de passe OPAQUE, consultez le présent document [Lien PDF] par des chercheurs de l'Université de Californie, Irvine et IBM, et de l'ingénieur Cloudflare Tatiana Bradley billet de blog.

À retenir de SSL.com: Nous sommes toujours ravis de découvrir les nouveaux protocoles de sécurité réseau, en particulier en ce qui concerne PKI et certificats numériques. Nous vous apporterons plus d'informations sur ces avancées et d'autres avancées en matière de sécurité et de confidentialité au fur et à mesure qu'elles apparaissent et sont mises en œuvre.

Fuite d'informations d'identification FTP possiblement liées à l'attaque SolarWinds

À moins que vous n'ayez passé les dernières semaines dans une cabine éloignée et hors réseau (ce n'est pas une mauvaise idée maintenant que nous y pensons), vous avez probablement déjà entendu beaucoup de choses sur le attaque de la chaîne d'approvisionnement Cela a compromis le logiciel de surveillance informatique Orion de SolarWinds et de nombreux utilisateurs du gouvernement et de l'industrie. Le 16 décembre de Ravie Lakshmanan DE BOUBA in the Hacker News explique comment les attaquants «ont probablement réussi à compromettre la construction de logiciels et l'infrastructure de signature de code de la plate-forme SolarWinds Orion dès octobre 2019 pour livrer la porte dérobée malveillante à travers son processus de publication du logiciel.

L'idée… était de compromettre le système de construction, d'injecter tranquillement son propre code dans le code source du logiciel, d'attendre que l'entreprise compile, signe les packages et enfin, vérifie si leurs modifications apparaissent comme prévu dans les mises à jour nouvellement publiées.

La chronologie d'octobre 2019 correspond à celle du chercheur en sécurité Vinoth Kumer découverte, en novembre 2019, d'un dépôt GitHub public divulguant des informations d'identification FTP en clair pour le serveur de mise à jour de Solarwinds - et que ce serveur était accessible avec le mot de passe «solarwinds123». Le repo en question était ouvert au public «depuis le 17 juin 2018», donnant aux attaquants potentiels suffisamment de temps pour découvrir et exploiter les informations d'identification divulguées.

Bien sûr, le fait que SolarWinds conseille également aux utilisateurs de désactiver les mesures de sécurité n'a pas aidé:

Pour aggraver les choses, un code malveillant ajouté à une mise à jour logicielle Orion peut être passé inaperçu par les logiciels antivirus et autres outils de sécurité sur les systèmes ciblés grâce à SolarWinds. conseil de support, qui indique que ses produits peuvent ne pas fonctionner correctement à moins que leurs répertoires de fichiers ne soient exemptés des analyses antivirus et des restrictions d'objet de stratégie de groupe (GPO).

À retenir de SSL.com: Signature de code est une étape importante, voire obligatoire, pour maintenir la confiance lors de la distribution de logiciels aux clients, mais cela dépend d'un environnement sécurisé pour réussir. Protéger des serveurs cruciaux avec des mots de passe faibles et faciles à deviner et / ou exposer par inadvertance des informations d'identification en texte clair au public, laisse une porte ouverte aux attaques qui exploitent votre système de construction pour publier des logiciels signés, mais non cheval de Troie.

Abonnez-vous à la newsletter SSL.com

Ne manquez pas les nouveaux articles et mises à jour de SSL.com