Tour d'horizon de la sécurité de juin 2020

Bienvenue dans cette édition de juin du Security Roundup de SSL.com. L'été est là, la pandémie continue, tout comme l'actualité de la sécurité numérique! Ce mois-ci, nous allons examiner:

Si vous recherchez un SSL /TLS certificat pour votre site, jetez un œil à la valeur abordable et élevée de SSL.com Options.

Le Sénat envisage d'envisager des portes dérobées de chiffrement obligatoires

Celui-ci est un peu yikes-y. Alors qu'une grande partie du pays envisage de réduire le pouvoir des forces de l'ordre, trois sénateurs ont introduit un Projet de loi draconien cela obligera les entreprises de technologie à créer des «portes dérobées» pour un système de cryptage qui permettront aux forces de l'ordre d'accéder aux données en transit et sur les appareils. Comme Vice Magazine Carte mère le mettre succinctement leur titre, "Les républicains qui ne comprennent pas le chiffrement présentent un projet de loi pour le casser."

Le projet de loi des sénateurs Lindsey Graham (R-Caroline du Sud), Tom Cotton (R-Arkansas) et Marsha Blackburn (R-Tennessee) a été largement et minutieusement critiqué par l'industrie de la technologie, les défenseurs des droits civils et beaucoup de bon sens. Comme Thomas Claburn's article dans The Register explique:

Le projet de loi exige que toute entreprise qui se présente avec un mandat - «fabricant de dispositifs, fournisseur de système d'exploitation, fournisseur de service informatique à distance ou autre personne» - aide les autorités à «accéder aux informations stockées sur un appareil électronique ou à accéder à des informations électroniques stockées à distance. "

 Il ne précise pas comment le cryptage doit être traité, mais simplement qu'il doit être annulable lorsqu'il ne convient pas aux autorités ...

 … Le cryptage, il faut le dire, empêche également une bonne partie de la criminalité en gardant des choses comme les comptes bancaires en ligne et la navigation sur le Web raisonnablement sécurisés. Mandater une porte dérobée, qui mathématiquement n'importe qui pourrait trouver, n'est peut-être pas la décision la plus sage.

Malheureusement, cette tentative de législation n'est même pas particulièrement nouvelle, juste la dernière itération paresseuse d'une tentative de contournement de la sécurité numérique pour faciliter les choses pour les pouvoirs en place.

À retenir de SSL.com: SSL.com ne prend pas en charge l'insécurité imposée par le gouvernement - lorsque le cryptage de bout en bout est interdit, seuls les hors-la-loi auront un cryptage de bout en bout. Notez également cette citation de l'article de Vice: «La seule mise en garde est« à moins que les actions indépendantes d'une entité non affiliée ne rendent techniquement impossible de le faire », ce qui semble exclure la réalité actuelle, à savoir que les entreprises technologiques elles-mêmes l'ont rendu impossible pour déchiffrer les données stockées sur un téléphone crypté avec un mot de passe, ou les messages échangés dans des applications cryptées de bout en bout. '

Le gouvernement américain envisage d'utiliser HTTPS sur tous les sites Web .gov

Dans les bonnes nouvelles tardives, le gouvernement américain a annoncé son intention d'ajouter le domaine «.gov» à la liste de préchargement HTTP Strict Transport Security (HSTS). Pour le moment, certains sites gouvernementaux continueront à proposer HTTP pour les garder accessibles aux utilisateurs, avec l'intention d'atteindre le point où tous les serveurs Web .gov utiliseront HTTPS par défaut.

Mais il s'agit du gouvernement fédéral et il est important de noter que rien de tout cela ne se fera du jour au lendemain. Au contraire, les États-Unis s'efforcent de mettre le domaine .gov sur la liste de préchargement HSTS, qui finira par rediriger les utilisateurs pour qu'ils communiquent via HTTPS par défaut.

A partir de le gouvernement annoncet:

Notez que nous annonçons une intention de précharger le TLD, mais pas réellement de le précharger aujourd'hui. Si nous faisions cela, certains sites Web gouvernementaux qui n'offrent pas le HTTPS deviendraient inaccessibles aux utilisateurs, et nous ne voulons pas avoir un impact négatif sur les services sur notre façon de les améliorer! En fait, le préchargement est une étape simple, mais y parvenir exigera des efforts concertés entre les organisations gouvernementales fédérales, étatiques, locales et tribales qui utilisent une ressource commune, mais qui ne travaillent pas souvent ensemble dans ce domaine… Avec des efforts concertés, nous pourrions précharger. gov dans quelques années.

Dans l'intervalle, selon cette même annonce, le gouvernement préparera des sites individuels pour la transition, organisera des présentations et des séances d'écoute, et préchargera automatiquement tous neufs Domaines .gov à partir de septembre. Ils ont également créé une nouvelle liste de diffusion pour les commentaires des agences gouvernementales sur les défis auxquels ils s'attendent à faire face.

À retenir de SSL.com:  Tous les sites Web du monde entier devraient désormais utiliser HTTPS, c'est donc une bonne idée, bien que lente. Nous prendrons ce que nous pouvons obtenir!

Comcast et Mozilla Strike Firefox DoH Deal

Comcast est le premier fournisseur d'accès Internet à partenariat avec Mozilla pour fournir des recherches DNS cryptées dans Firefox. L'accord entre les deux sociétés vient après un différend sur la confidentialité des FAI et si le DNS sur HTTPS enlève la capacité des FAI à suivre les utilisateurs et à maintenir des choses comme le contrôle parental.

Jon Brodkin dans Ars Technica Explique que Comcast sera le premier FAI à rejoindre le programme Trusted Recursive Resolver de Firefox, rejoignant Cloudflare et NextDNS. Le programme, selon cet article, «exige que les fournisseurs DNS cryptés répondent critères de confidentialité et de transparence et engagez-vous à ne pas bloquer ou filtrer les domaines par défaut «sauf si la loi de la juridiction dans laquelle le résolveur opère». »

Auparavant, les deux partenaires actuels étaient en désaccord sur DNS sur HTTPS, ce qui empêche les gens de voir ce que font les navigateurs de recherche DNS, ce qui rend la surveillance par les FAI assez difficile. Extrait de l'article d'Ars Technica:

Le partenariat Comcast / Mozilla est remarquable parce que les FAI ont combattu les projets de déploiement de DNS sur HTTPS dans les navigateurs, et le travail de Mozilla sur la technologie est en grande partie destiné à empêcher les FAI d'espionner la navigation de leurs utilisateurs. En septembre 2019, des groupes industriels, dont le lobby du câble NCTA auquel appartient Comcast, ont rédigé un lettre au congrès s'opposer aux plans de Google pour DNS crypté dans Chrome et Android. Comcast a donné aux membres du Congrès a présentation de lobbying qui prétendait que le plan DNS chiffré «centraliserait [e] une majorité des données DNS mondiales avec Google» et «donnerait à un fournisseur le contrôle du routage du trafic Internet et de vastes quantités de nouvelles données sur les consommateurs et les concurrents». La présentation de lobbying de Comcast s'est également plainte du plan de Mozilla pour Firefox.

Mozilla en novembre FAI accusés de mentir au Congrès afin de semer la confusion sur le DNS crypté. Mozilla lettre au Congrès critiqua Comcast, indiquant un incident en 2014 dans lequel Comcast «a injecté des publicités aux utilisateurs connectés à ses hotspots Wi-Fi publics, créant potentiellement de nouvelles vulnérabilités de sécurité dans les sites Web». Mozilla a déclaré qu'en raison de l'incident de Comcast et d'autres impliquant Verizon et AT&T, «nous pensons que de telles mesures proactives [pour mettre en œuvre un DNS crypté] sont devenues nécessaires pour protéger les utilisateurs à la lumière du vaste historique d'abus de données personnelles par les FAI.» Mozilla a également souligné l'absence de règles de confidentialité du haut débit dans le pays, qui étaient tué par le Congrès en 2017 à la demande des FAI.

Mais, cela semble maintenant être dans le passé, avec un accord signé entre les deux sociétés à partir de mars et une attente que le DNS crypté de Comcast arrivera également assez tôt sur Chrome.

À retenir de SSL.com: C'est bien de voir un FAI embarquer avec un DNS crypté, mais vous devriez quand même lire Xfinity de Comcast Politique de confidentialité si vous êtes un client.

AddTrust External CA Le certificat racine a expiré

La AddTrust External CA certificat racine expiré mai 30, 2020. Bien que la plupart des utilisateurs ne soient pas affectés par cette expiration, elle est tout de même remarquable. Certains certificats émis par le passé par SSL.com se connectent à la racine USERTrust RSA CA de Sectigo via une signature croisée intermédiaire par la racine AddTrust. Cela a été fait pour garantir la compatibilité avec les périphériques hérités qui n'incluent pas la racine USERTrust.

Heureusement, des appareils qui do inclure la racine USERTrust, qui sont la grande majorité, ne sera pas affectée par l'expiration. Dans ce cas, ce qui sera vrai pour tous les navigateurs, systèmes d'exploitation et appareils mobiles modernes, le logiciel choisira simplement un chemin de confiance menant à USERTrust et ignorera le certificat AddTrust expiré. Nous vous avons tout expliqué au début du mois, donc si vous cherchez plus de détails, vous voudrez peut-être rendez-vous sur notre article de blog du 2 juin. Pour maintenir la compatibilité avec les appareils plus anciens, les propriétaires de sites Web disposant de certificats SSL.com USERTrust peuvent télécharger des certificats intermédiaires et racine de remplacement via les boutons ci-dessous:

TÉLÉCHARGER LES CERTIFICATS INDIVIDUELS

TÉLÉCHARGER LES CERTIFICATS GROUPÉS

Utilisateurs utilisant d'anciens SSL /TLS clients, y compris OpenSSL 1.0.x et GnuTLS, doit supprimer le certificat AddTrust expiré de leur magasin racine du système d'exploitation. Voir nos blog pour des liens vers des correctifs pour Red Hat Linux et Ubuntu.

À retenir de SSL.com: Si vous avez des certificats USERTrust émis par SSL.com, vous pouvez (et devriez!) Télécharger un nouveau bundle CA depuis notre site Web et installez-les sur votre serveur.
Merci d'avoir visité SSL.com! Si vous avez des questions, veuillez nous contacter par e-mail à Support@SSL.com, appel 1-877-SSL-SECURE, ou cliquez simplement sur le lien de discussion en bas à droite de cette page. Vous pouvez également trouver des réponses à de nombreuses questions d'assistance courantes dans notre knowledgebase.

 

Abonnez-vous à la newsletter SSL.com

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

Nous aimerions recevoir vos commentaires

Répondez à notre enquête et faites-nous part de votre avis sur votre récent achat.