Pourquoi les principaux navigateurs ne prennent-ils pas en charge TLS au-dessus de la version 1.0?
TLS 1.0 semble être vulnérable à Beast , Lucky13 et peut-être à d'autres attaques et est tout simplement obsolète. Solution de contournement couramment utilisée, par exemple par Google devait utiliser RC4 qui a également été récemment cassé, mais aucun des principaux navigateurs ne semble implémenter une version plus récente de TLS, à l'exception de Microsoft IE pour les versions plus récentes de Windows).
Y a-t-il une raison pour laquelle il y a eu si peu de mouvement?
Edit: presque la même question . Pourquoi était-il fermé? Mystère sur stackexchange.
Versions TLS prises en charge au 2011-09-22
Dois-je penser que pour éviter les problèmes avec TLS 1.0, vous devez l'interdire ? Cela peut prendre du temps.
Je vais abuser de mes questions pour répondre à Thomas Pornin car cela ne rentre pas dans le commentaire.
Comme d'habitude, vous écrivez beaucoup de lettres :)
"La rupture du RC4 reste" académique "
Vous souvenez-vous de l'histoire du WEP? En 2001, seuls certains modèles clés étaient vulnérables, ce qui pouvait être exclu sans changer le protocole, en 2004 ce n'était plus le cas et en 2007, seuls 40 000 paquets étaient suffisants. Les attaques ne s'aggravent jamais, mais en mieux. Et dans la vraie vie, toutes les mises à jour ont besoin de temps, des années s'écouleront jusqu'à la mise à jour de tous les serveurs, bien que ce ne soit pas tellement comme sur les routeurs soho. Pouvez-vous prédire avec une probabilité fiable quand cela deviendra réaliste? À propos des solutions de contournement - sont-elles rétrocompatibles? Combien de temps vont-ils tenir? N'est-il pas plus facile d'utiliser une version TLS plus récente?
La mise à niveau du support client vers TLS 1.2 ne changera rien du tout tant que la plupart des serveurs ne seront pas mis à niveau également.
Les mises à niveau ont donc besoin de temps, plus tôt nous commencerons, plus tôt c'est fait.
comparaison avec IPv6
Eh bien, avec IPv4, vous pouvez prédire quand vous n'avez plus d'adresse IP. Cela dépend en grande partie du pays - ceux qui étaient premiers sur Internet n'ont généralement aucun problème :) Ceux qui sont hors IP avancent IPv6, comme la Chine.
En pratique, plusieurs navigateurs largement utilisés s'appuient sur le code SSL/TLS du système d'exploitation sous-jacent
Lesquelles O_o? Je pensais que IE fait cela, qui s'en soucie sans AdBlock fonctionnel.
La principale raison pour laquelle il y a peu de mouvement est que les "pauses" ne sont pas assez pratiques pour apparaître sur le radar.
BEAST ne fonctionne plus . Premièrement, cela nécessite un moyen pour le code client dans le navigateur (hostile Java ou Javascript hostile) d'émettre des requêtes interdomaines avec un niveau de contrôle élevé au niveau du bit; les deux façons connues de faire cela (une version préliminaire de WebSockets et une vulnérabilité dans le Java VM) ont été corrigées. Deuxièmement, les navigateurs et le système d'exploitation ont ajouté des solutions de contournement, à savoir la division 1/n-1: chaque fois qu'un enregistrement TLS doit être émis, deux enregistrements sont envoyés, le premier ne contenant qu'un octet de données d'application Cette solution de contournement empêche l'application de BEAST.
La rupture du RC4 est toujours "académique" . On savait depuis un certain temps que le RC4 présentait de sérieux biais. Les résultats récents (mars 2013) sont des mesures systématiques qui montrent qu'il y a plus de biais qu'on ne le pensait, de sorte qu'une véritable attaque ne nécessite "que" d'observer quelques millions de connexions avec le secret cible toujours au même endroit. Alors que "quelques millions" est plutôt faible, il reste peu pratique, du point de vue de l'attaquant, dans un contexte Web. Ainsi, aucun cookie n'a été volé dans la nature grâce à l'utilisation de RC4. De plus, il existe solutions de contournement possibles qui sont plus faciles à implémenter dans un navigateur.
Ainsi, il n'y a aucune réelle incitation à une mise à jour en masse des implémentations TLS client. En effet, les éditeurs de navigateurs sont habitués à faire face, sur une base hebdomadaire, à des vulnérabilités beaucoup plus dévastatrices que cela (impliquant généralement un détournement hostile de l'ensemble du système client). Il est peu probable qu'un exploit quelque peu théorique de la cryptographie en SSL soit même remarqué, et encore moins donné suite. Ce qui pousse les fournisseurs de navigateurs vers des versions plus récentes est le publicité qui est fait à propos de ces attaques cryptographiques.
De plus , et c'est le point important, la version du protocole qui sera utilisée pour une connexion donnée est limitée par ce que les logiciels client et serveur prennent en charge. La mise à niveau du support client vers TLS 1.2 ne changera rien du tout tant que la plupart des serveurs ne seront pas mis à niveau également. De même, la mise à niveau de la prise en charge du serveur n'est pas très utile tant que les clients ne sont pas mis à niveau. Il s'agit de l'impasse mexicaine classique, dans laquelle personne ne bouge, car cela nécessiterait un commutateur de mise à niveau massif simultané de plusieurs fournisseurs distincts. D'ailleurs, c'est la même histoire qu'avec IPv6 (qui devait être largement adopté en 2007).
En pratique, plusieurs navigateurs largement utilisés s'appuient sur le code SSL/TLS du système d'exploitation sous-jacent, de sorte que toute mise à niveau de masse devra attendre la fin de vie de Windows XP (planifié par Microsoft pour l'année prochaine).
Je ne sais pas ce que vous entendez par non pris en charge. Actuellement, les navigateurs suivants prennent en charge TLS 1.1 et 1.2:
- Chrome - v30 prend en charge TLS 1.2. Auparavant, seul TLS 1.1 était pris en charge
- Firefox - v27 active TLS 1.1 et 1.2 par défaut
- Internet Explorer - v11 prend en charge TLS 1.2 à partir de février 2013
- Opera - v17 a ajouté la prise en charge de TLS 1.2. Les versions 10-12 prenaient en charge TLS 1.1 et 1.2 mais le désactivaient par défaut, et les versions 14-16 prenaient en charge TLS 1.1 mais pas 1.2.
- Safari - v5 sur iOS et v7 sur OS X ont ajouté la prise en charge jusqu'à TLS 1.2.
BEAST a été fixe sur les navigateurs modernes.
Alors que les gens devraient vraiment passer aux nouvelles versions de TLS, il n'y a pas eu d'adoption significative des nouveaux protocoles. Il y a eu des problèmes de compatibilité avec des serveurs qui n'ont pas activé les nouveaux protocoles. Voir ceci lien pour plus d'informations. Cependant, l'article a presque un an, il pourrait donc y avoir eu des améliorations depuis ce temps.
Une raison plausible de ne pas passer aux versions TLS plus récentes est que les développeurs ont appliqué des pansements aux anciens protocoles pour corriger les vulnérabilités. Ce n'est évidemment pas viable à long terme. Espérons que la récente vague d'attaques contre SSL/TLS poussera les gens à accélérer le passage à de nouvelles versions du protocole.
La raison pour laquelle Firefox ne prend pas en charge TLS 1.2 est que le backend de sécurité qu'ils utilisent Network Security Services ne le prend pas en charge. Une implémentation est en cours, voir ce rapport de bogue
Mise à jour: Depuis le 13 juin 2013 Chrome Canary prend désormais en charge TLS 1.2 car le bogue correspondant est maintenant corrigé.