Autoriser tous les protocoles SSL pour node.js Demande HTTPS

Question

Est-il possible de faire en sorte que node.js https.request (client) négocie un protocole possible (même s'il n'est pas sécurisé) avec des serveurs distants? Je comprends le risque de sécurité, mais pour mon projet, certains sites Web ne fonctionnent qu'avec des protocoles SSL plus anciens/non sécurisés (&). Par exemple: https://www.dot.ny.gov ne fonctionne pas (timeout) avec curl ou la dernière configuration par défaut de node.js 7.10.1 sur Ubuntu Server 16.04. Il fonctionne uniquement avec curl en utilisant les options --tlsv1.0 ou --sslv3.

Donc est-il possible de faire renégocier la connexion SSL par node.js en utilisant une gamme de protocoles (du plus sûr au moins sécurisé), ou d'utiliser la configuration la plus large possible (via node.js ou OpenSSL sous-jacent) tous les protocoles SSL & ciphers?

Answer 1

L'un des packages NPM les plus populaires pour la création de requêtes HTTP (S) est le request. Selon sa documentation, vous êtes en mesure de spécifier les protocoles SSL que vous souhaitez accepter.

Si vous connaissez à l'avance les sites que vous allez visiter et quel protocole ils utilisent, vous pouvez le définir par demande. Sinon, j'imagine que vous pourriez écrire quelques conditions, bien que la surcharge de faire des demandes multiples serait lourde.

Answer 2

L'autorisation de ces protocoles ne résoudra pas le problème que vous décrivez sur le site. TLS est par nature principalement rétrocompatible, c'est-à-dire qu'un serveur correctement implémenté qui ne peut faire que SSL 3.0 ou TLS 1.0 répondra simplement avec le meilleur protocole supporté s'il est confronté à un ClientHello d'un client supportant TLS 1.2. En effet, le client annonce simplement la meilleure version possible et le serveur sélectionne alors la meilleure version prise en charge, égale ou inférieure à la version proposée par le client. Ce n'est qu'alors que le "autoriser" entre en jeu, c'est-à-dire si le client accepte la réponse du serveur avec la version inférieure.

Mais ce n'est pas le problème avec le site que vous montrez. Dans ce cas, le serveur ou un boîtier de test en face de lui a une pile SSL/TLS buggée qui croque simplement sur ClientHello inattendu. Ceux-ci peuvent être un ClientHello qui a une version inattendue de TLS, des extensions inattendues, des chiffrements inattendus, qui sont trop petits ou trop grands ou des particularités similaires. Dans ce cas précis, la version du protocole TLS ne semble pas du tout être le problème, mais elle ressemble plus à la taille de ClientHello est un problème peut-être parce qu'il existe un ancien équilibreur de charge F5 avec this bug en face de lui. Étant donné que les navigateurs ont tendance à n'offrir que quelques chiffrements, leur ClientHello est la plupart du temps assez petit pour ne pas être affecté par ce problème. Par exemple, si vous essayez avec un ensemble de chiffrement réduit comme dans openssl s_client -connect www.dot.ny.gov:443 -cipher 'AES128-SHA' vous réussirez même avec un ClientHello TLS 1.2 mais si vous en essayez un plus grand (comme -cipher 'AES') il se bloquera sans recevoir de réponse, probablement parce que l'équilibreur de charge cassé croassa sur le grand ClientHello. Et avec l'application de TLS 1.0 dans votre ligne de commande, vous avez juste veillé à ce qu'elle n'offre pas aussi les nouveaux chiffrements TLS 1.2 qui ont également réduit la taille de ClientHello. Il n'y a pas de manière générale de traiter de tels serveurs cassés en autorisant simplement tout parce que certaines parties du "allow" ne viennent qu'après que le serveur ait répondu (ce qui n'est pas le cas dans ce cas) et certaines pourraient causer encore plus de problèmes avec le serveur (comme offrir trop de chiffrements qui augmente la taille du ClientHello). Au lieu de cela, il faut déboguer le problème, savoir ce que le serveur endommagé aime et ce qu'il déteste et ensuite concevoir une prise de contact TLS spécifique (version, chiffrements, extensions, taille ...) pour que le serveur l'aime. Et un bon moyen de savoir ce que le serveur spécifique accepte est de regarder le analysis by SSLLabs.