Apple, Google, GoDaddy misissued des certificats TLS avec la faiblesse des numéros de série

0
186
HTTPS lock TLS

Principales autorités de certification comme Apple, Google, et GoDaddy ont misissued plus de 1,2 million de certificats TLS en vedette un insuffisamment long numéro de série de seulement 63 bits au lieu de l’industrie minimum de 64 bits.

Ce problème ne représentent pas de menace pour la sécurité des utilisateurs de l’internet d’aujourd’hui. Toutefois, elle peut conduire à un grand nombre de sites cassés dans les semaines à venir, comme les certificats TLS sont remplacés à la volée.

L’erreur au cœur de ce problème est venu à la lumière, le 24 février dernier, au cours d’une discussion publique au sujet de l’acceptation d’une organisation controversée (DarkMatter) dans Firefox liste des autorités de certification (Ac) –les organismes autorisés à délivrer des certificats TLS être utilisé pour sécuriser les communications HTTPS.

Au cours d’un examen de DarkMatter de l’infrastructure et de son passé, l’activité, la sécurité, ingénieur logiciel de Corey Bonnell remarqué que l’organisation avait publié 235 certificats TLS en vedette un numéro de série de 63 bits au lieu de 64.

Scott Rea, l’un des DarkMatter Vice-Présidents, d’un suivi de la question de EJBCA, une plate-forme logicielle que de nombreux CAs sont l’aide à automatiser le processus de génération de nouveaux certificats TLS basé sur un ensemble de conditions préalables (les normes de l’industrie).

Le problème, comme il a expliqué plus tard, a été que d’un certificat TLS numéros de série doivent être des entiers positifs. Pour traiter de cette question, EJBCA, le sacrifice d’un des numéros de série de bits, qui allait toujours être égale à zéro, et à assurer que le numéro de série serait un entier positif et, par conséquent, être conformes aux normes.

Cependant, ce faisant, la version 64 bits du numéro de série serait effectivement un 63 bits numéro de série, la réduction de moitié de la protection de ce numéro de série aurait fourni le certificat TLS ensemble contre les attaques par collision (au cours de laquelle les attaquants essaient de créer de faux certificats TLS avec la même signature).

Qui est concerné?

Toutes les autorités de certification qui a utilisé le EJBCA logiciel de plate-forme et a choisi de générer des numéros de série, avec le minimum de 64 bits de valeur ont été touchés. CAs qui a généré 72 bits ou d’autres valeurs plus importantes pour les numéros de série n’ont pas été touchés.

Touchés CAs inclus des grands noms comme Apple, Google, GoDaddy, mais aussi d’autres plus petits CA opérateurs.

Dans les semaines au long de l’enquête qui a suivi, Apple a trouvé qu’il avait misissued sur 878,000 certificats TLS utilisé un 63 bits numéro de série au lieu du minimum de 64 bits. De ces 558 000 d’entre elles étaient encore en usage.

Google a été moins affecté et a dit qu’il misissued seulement 100,836 certificats TLS, dont 7,171 étaient encore en usage, mais 7,137 devaient arriver à échéance dans les prochains 90 jours.

Mais le misissued certificats n’étaient pas réellement un énorme problème pour Apple et Google, car ces certificats TLS ont été utilisées uniquement en interne à ces entreprises, et elles pourraient être remplacées par ces entreprises ” employés à l’intérieur de quelques jours ou quelques semaines.

D’autre part, la question était beaucoup plus gros problème pour GoDaddy et ses clients, qui ont acheté ces plus faibles TLS certs. La société a déclaré qu’elle a émis 285,936 certificats TLS à ses clients, dont 12,152 étaient toujours actifs, tandis que le reste (273,784) semble être orphelin et n’est pas utilisé sur n’importe quel site en direct.

Tous les trois entreprises, ainsi que les petits Tas comme SSL.com sont maintenant dans le processus de révocation de ces certificats et l’émission de nouveaux, avec un bon numéro de série de la longueur.

Alors que l’autorité de certification des normes de l’industrie disent que ces misissued certificats devront être révoqué et remplacé dans un délai de cinq jours, GoDaddy aura besoin de beaucoup plus que cela pour informer tous les clients.

La société d’hébergement web –pour de bonnes raisons, hésitant à nuke plus de 12 000 certificats en direct des sites web, à l’improviste, sans avoir les propriétaires de sites informé et de prendre note à l’avance.

Dans l’immédiat aucune menace pour la sécurité

“Est-ce important pour la sécurité? Non,” Hanno Boch, un cryptographe, chercheur en sécurité, et journaliste, a déclaré aujourd’hui sur Twitter.

“La série aléatoire a été introduite pour empêcher la collision] les attaques contre les fractures des fonctions de hachage (MD5/SHA1),” il a dit. “Nous n’utilisons pas cassé les fonctions de hachage [plus]. Aussi 63 bits est encore assez bon pour prévenir les attaques, même si nous avons utilisé brisé les tables de hachage.”

Boch a fait valoir que la raison pour laquelle le CAs de re-délivrance de tous les non-plainte des certificats est de respecter les règles de l’industrie. Les ac ont coupé les coins ronds dans le passé, et aucune erreur ne doit être toléré, même si l’erreur n’a pas un impact immédiat sur la sécurité des connexions HTTPS.

Liés à la cyber-sécurité de couverture:

Microsoft Mars Patch Tuesday est livré avec des correctifs pour les deux Fenêtres zéro daysMarriott chef de la direction des actions post-mortem, l’an dernier, hackWordPress sites d’achat en vertu de attackFacebook poursuit ukrainien de l’extension de navigateur décideurs pour gratter de l’utilisateur dataChinese piratage groupe les portes dérobées, produits à partir de trois Asiatique de jeu companiesBanking les chevaux de Troie d’inondation de l’entreprise, Android attaques de surtension
Comment faire pour activer SSL et TLS 1.3 sur NGINX TechRepublicAndroid programme de sécurité a permis de fixer plus de 1M des applications dans Google Play CNET

Rubriques Connexes:

De sécurité de la TÉLÉVISION

La Gestion Des Données

CXO

Les Centres De Données