Comment rendre les navigateurs TLS «modernes» et «obsolètes» conviviaux?

Le sujet a été suscité par une discussion du post précédent , dans lequel la voix d'un administrateur de serveur Web attentionné résonnait: TLS 1.2 et AEAD sont le choix d'une personne en bonne santé, mais qui regrettera les utilisateurs de navigateurs "obsolètes"? Discutons de ceci - l'incompatibilité présumée entre les navigateurs TLS «modernes» et «hérités».



L'hypothèse est la suivante: si seules des versions stables du protocole de sécurité de la couche de transport TLS (1.2 et 1.3) et des suites de chiffrement (AEAD) sont laissées sur le serveur Web, les utilisateurs de navigateurs "obsolètes" ne pourront pas accéder au site.



Prenons une excursion facultative dans l'histoire ... En 2005 (c'est-à-dire il y a 16 ans), la National Security Agency des États-Unis a annoncé un corpus de normes, directives, recommandations et autres documents justificatifs sur l'utilisation des algorithmes cryptographiques - NSA Suite B Cryptography.



En 2009, l'IETF a publié la RFC5430Profil Suite B pour la sécurité de la couche de transport, qui a établi les protocoles et suites de chiffrement à utiliser pour les connexions HTTPS afin de se conformer aux exigences de la NSA. Même dans ce cas, pour répondre à ces exigences, le serveur et le navigateur Web devaient prendre en charge TLS version 1.2 et les suites de chiffrement TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 et TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.



Autrement dit, depuis au moins 11 ans, les développeurs savent à quelles exigences leurs produits doivent répondre pour pouvoir se qualifier pour une commande du gouvernement américain. Par conséquent, vous percevrez probablement le fait suivant sans surprise: tous les navigateurs actuellement utilisés prennent en charge la suite de chiffrement mentionnée dans la version avec une clé de chiffrement de 128 bits, et beaucoup (mais pas tous) - et avec une de 256 bits.



Cela pourrait être la fin de l'article, recommandant à tous les administrateurs de serveurs Web de ne laisser le support que pour TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 et de ne pas s'embarrasser des mythes sur l'incompatibilité de TLS 1.2 avec les navigateurs "obsolètes", sinon pour une nuance: dans les versions TLS inférieures à 1.3, l'algorithme de signature numérique doit coïncider avec l'algorithme du certificat TLS, et moins de 6% des serveurs Web avec un certificat signé à l'aide de l'algorithme ECDSA dans la zone de domaine .RU , le reste est utilisé pour la signature RSA.



Qui est à blâmer est une question d'une étude distincte; nous sommes intéressés par ce qu'il faut faire? Rappelons tout d'abord que non seulement la combinaison ECDHE + ECDSA + AES recommandée par la NSA, mais aussi d'autres font aujourd'hui partie des ensembles de chiffrement forts:





Un total de 19 suites de chiffrement fortes, mais toutes ne sont pas adaptées à une utilisation réelle sur un serveur Web public: l'algorithme de chiffrement CAMELLIA, comme AES en mode CCM, est supporté par un peu plus que quiconque, avec CHACHA20 et ses fidèles compagnon POLY1305 ne sont que des navigateurs modernes relativement familiers, et pour utiliser des suites de chiffrement basées sur ECDSA, comme déjà mentionné, un certificat TLS approprié est nécessaire. Ainsi, nous n'avons plus que 4 suites de chiffrement «supplémentaires»:



TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.



Il est tentant de supposer que si le navigateur prend en charge la combinaison ECDHE + ECDSA, il fera certainement face à ECDHE + RSA, mais ce n'est pas toujours le cas - beaucoup ne peuvent faire que DHE + RSA, et afin de satisfaire les demandes de tous les anciens navigateurs, sur un site avec un certificat RSA, vous devez prendre en charge deux suites de chiffrement:



TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



Cela nous donnera la compatibilité avec au moins les systèmes d'exploitation et navigateurs suivants:



Android 4.4.2 + navigateur Android (Chrome);

Windows XP + Chrome 49 / Firefox 49 / Opera 12.18;

Windows 7 + Internet Explorer 11 / Chrome 31 / Firefox 31;

OS X + Firefox 29 / Chrome 37;

iOS 9 + Safari 9;

Java 8b.



Je ne parlerai pas des systèmes * nix - cela dépend de l'assemblage, mais il est évident que le problème n'existe pas en tant que tel. Le seul problème se posera avec Windows Phone 8.1 + IE 10, qui ne prend en charge qu'une seule combinaison stable - ECDHE + ECDSA.



Mais que doivent faire les utilisateurs de Windows XP + IE 6 ou d'Android 2.3? - demandera l'administrateur attentionné. Continuezassis sans accès à l'Internet moderne, - je répondrai, - parce que même le support du protocole de serveur Web SSL 2.0 ne les aidera pas. Le fait est que même si vous roulez sur Windows XP toutes les mises à jour publiées pour celui-ci (jusqu'en mai 2019) et mettez à jour le navigateur standard vers la version 8, cela ne prendra en charge que TLS 1.2, mais pas les suites de chiffrement stables. De plus, Windows XP ne savait ni n'apprendrait ce que sont l'indication de nom de serveur (SNI), HTML 5 Live HTML et CSS 3.



Êtes-vous prêt pour le bien des "un et demi creuseurs" tenaces à conserver une adresse IP dédiée pour le site et à ne pas mettre à jour la mise en page? Ajoutez ensuite la prise en charge, par exemple, TLS_RSA_WITH_AES_256_CBC_SHA256, mais vous devriez plutôt supposer qu'un utilisateur moderne de Windows XP utilise depuis longtemps un navigateur alternatif qui prend même en charge TLS 1.3. Il en va de même pour Android 2.3, en installant Firefox 27 sur lequel nous aurons un support complet pour les suites de chiffrement TLS 1.2 et AEAD, et sans installation - nous ne pourrons tout simplement pas utiliser une partie importante des sites modernes, même via HTTP.



Tout ce qui précède, bien sûr, n'est pas un appel à abandonner le support de suites de chiffrement plus puissantes, qui seront exigées par les navigateurs modernes, et qui devraient être proposées pour négociation en premier lieu.



Afin de ne pas vous lever deux fois, considérez brièvement la situation avec des courbes elliptiques. NSA Suite B Cryptography ne reconnaît que deux d'entre eux - NIST P-384 et NIST P-256, dont le support sur le serveur Web donnera accès au site pour les navigateurs modernes et "hérités". En fait, il suffit de prendre en charge uniquement NIST P-384 pour les "anciens" et Curve25519 pour les navigateurs modernes; enfin, sauf peut-être pour ajouter le NIST P-521, pour certains "oldies avancés".



Pour résumer: si nous voulons que le site reste accessible pour les navigateurs "obsolètes", mais en même temps ne supporte que les versions stables du protocole de sécurité de la couche de transport et des suites de chiffrement, nous procéderons comme suit.



Pour un site avec un certificat TLS signé à l'aide de l'algorithme ECDSA, activez la prise en charge de la suite de chiffrement TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.



Pour un site avec un certificat TLS signé à l'aide de l' algorithme RSA , activez la prise en charge des suites de chiffrement TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 et TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



Pour les deux sites, nous activerons la prise en charge de la courbe elliptique NIST P-384 ou NIST P-256 et définirons l'ordre de préférence pour les ensembles de chiffrement et les courbes elliptiques, selon lequel les ensembles et les courbes ci-dessus sont proposés aux navigateurs pour une correspondance après plus stables, par exemple, après TLS_ECDHE_RSA_WITH_AES_ 256 _GCM_SHA 384 et Curve25519, respectivement.