Dans un billet, la responsable Jessica Krynitsky indique que les statistiques d’utilisation des deux vieilles versions du protocole TLS (Transport Layer Security) sont suivies de près depuis des années. Il est recommandé en effet depuis des années d’utiliser la version 1.2 (supportée par Windows 8), et si possible la 1.3 (prise en charge par Windows 11).
Maintenant que les statistiques sont jugées « suffisamment faibles », Krynitsky indique que le moment est venu d’agir :
« Afin de renforcer la sécurité des utilisateurs de Windows et d'encourager l'adoption de protocoles modernes, les versions 1.0 et 1.1 de TLS seront bientôt désactivées par défaut dans le système d'exploitation, à partir de la version Insider Preview de Windows 11 en septembre 2023 et des futures versions du système d'exploitation Windows. »
En pratique, il devrait s’agir de la mise à jour majeure 23H2 de Windows 11. Les prochaines versions de Windows seront bien sûr concernées.
Attention, on parle bien du système d’exploitation, pas des navigateurs. Edge et même Internet Explorer ont désactivé le support de TLS 1.0/1.1 depuis un moment déjà, comme tous les autres navigateurs.
Commentaires (36)
#1
C’est également désactivé sur tous les serveurs web correctement configurés.
Mais les configs de base de nginx par exemple, continuent de proposer au moins la version 1.1
#1.1
Il était temps !
Je ne connais pas d’admins systèmes compétents qui resteraient sur une config de base vulnérable… Au pire il y a des outils comme celui-ci : https://ssl-config.mozilla.org/
#1.2
Merci pour le lien, je connaissais pas. 😊
#1.3
Tu serais bien malheureux toi dans une grande organisation (voir toute organisation finalement) dont l’objectif premier n’est pas l’informatique.
Dès que tu as des contraintes budgétaires et que tu passes par une DAF dont l’unique but est de maximiser le profit, je peux te garantir que tu peux aller te brosser pour aller appliquer tes préceptes…
Tu as tellement de raisons plus ou moins légitimes de devoir utiliser de vieilles versions d’outils que j’ai sincèrement du mal à croire que tu te sois déjà confronté au monde du travail un jour…
Allez, j’ai trois exemples pour toi que j’ai rencontrés/subis à titre perso:
Budget de màj ? 40-50k€ pour 0 bénéfice sinon subir une attaque avec toutes les conséquences que l’on suppose…
comparé à une séparation du réseau tel+tel admin via des vlan avec un filtrage des flux pour 0€ en attendant de migrer sur une solution concurrente… Tu risques d’avoir du mal à vendre ton option de màj… (et franchement, tu risquerais de te faire jeter en un rien de temps si tu voulais forcer)
Cette appliance n’est plus maintenue et l’éditeur ne propose pas de migration (en sachant que les accès se font depuis une application métier qu’il faudrait également modifier derrière. Application métier qui a été décommiossionnée et n’est plus utilisée que pour des accès de consolidation/litige.
T’imagines pas à combien ça peut chiffrer et combien ça peut être compliqué à gérer et puis bonne chance pour avoir l’aval de ta direction derrière…
Alors on est bien d’accord qu’idéalement, ces applications devraient être suivies et budgétées mais tu peux rencontrer des problèmes qui font que ça passe pas (boite qui coule, boite qui se fait racheter, équipes qui se font délocaliser/redispatcher sans prise en compte de l’ensemble de leurs missions/équipes qui partent sans transfert de compétence/…)
Ensuite, pour te montrer que rien n’est jamais simple et qu’il faut toujours se concerter et s’adapter aux autres :
Je suis en train de me battre en ce moment avec l’un de nos logiciels MFT (version qui date de Mars 2023 pourtant) qui utilise un client java sftp incompatible avec le serveur d’un de nos partenaires…
J’ai appris aujourd’hui qu’il venait d’être màj par un type qui s’est cru tout seul dans son coin et a appliqué bêtement, j’imagine, un tuto précisant la suite de protocoles réputés fiables sans en comprendre le fonctionnement… /taunt
Changement fait sans concertation avec nous évidement et sans change/passage devant un CAB et sans procédure de retour arrière évidement…
Ce qui n’est franchement pas étonnant car j’ai du mal à imaginer qu’une personne capable de bloquer toute une série de clients pour assouvir ses envies les plus nobles puisse savoir ce que c’est que de travailler en équipe.
Donc par dogmatisme, nous avons un serveur sftp qui a été màj pour n’autoriser que l’algo “ssh-ed25519” pour la phase “HostKey algorithms” (me demande pas pourquoi, ce truc est toujours en draft à l’ietf)
là ou nous supportons que :
rsa-sha2-256
rsa-sha2-512
ssh-dss
ssh-rsa
Tout ça sans que nous n’ayons eu connaissance (j’ai du m’installer python + script ssh_scan sur mon poste pour tout te dire…)
¯_(ツ)_/¯
Bref. Je te suggère sincèrement de redescendre un peu sur Terre, d’arrêter de prendre les gens de haut et d’accepter que le monde ne tourne pas autour de ton serveur nginx et de ton site web
/cheers
#1.4
L’argument “mon objectif premier n’est pas l’informatique” pour justifier une mauvaise gestion, ça soulève pas mal de questions relatives aux périls qui pèsent sur l’activité.
Par exemple, pour reprendre le coup de la VM avec l’Alcatel Omni PCX sur ESX2, en partant du fait qu’ils ne doivent plus avoir de support ni pour le logiciel, ni pour la technologie de virtualisation … il se passe quoi si l’infra sur laquelle ça tourne claque? C’est quoi les objectifs RTO/RPO ? L’entreprise peut-elle juste se permettre de dire que cette infrastructure n’a jamais existé et que ce n’est pas grave, ou faudra t’il la reconstruire à l’identique? L’import des données/ de la configuration dans une nouvelle version du logiciel est-il possible?
Pareil pour le stockage de factures. Le problème n’est pas juste le fait que c’est du sslv3, de maintenir des interfaces obsolètes, … mais de savoir ce qui se passe en cas de perte de l’infrastructure ou de corruption des données.
Souvent le problème de compatibilité de la sécurité des protocoles est juste la partie visible d’un problème bien plus grave, quand un logiciel ou une infrastructure ne suivent plus aucun cycle de vie, c’est qu’ils ne sont plus viables.
#1.5
Bravo, tu m’as complètement cerné, ainsi que mon expérience professionnelle ! Maintenant, je t’invite à retourner au primaire et apprendre à lire. On parlait de config de base, lors d’un déploiement initial donc. Je veux bien croire que pour de multiples raisons organisationnelle une infra soit laissée à l’abandon dans une grande entreprise (j’ai juste bossé plus de 10 ans dans la cybersécurité de grandes boites), mais par contre qu’une infra soit déployée dans une configuration de base non sécurisée, ça par contre c’est criminel.
Donc ton post est intéressant à lire, et représente bien la réalité dans de nombreuses boites, mais n’a rien à voir avec ce qui a été dit avant.
J’avoue que j’ai aimé le temps que j’ai passé à bosser pour une banque Luxembourgeoise, où si la sécu dit non, le projet s’arrête tant que les problèmes de sécurité identifiés ne sont pas réglés. En même temps, le patron peut très bien aller en taule s’il y a un problème, pas comme en France.
#1.6
Perso, j’ai bossé pour une banque luxembourgeoise; et comme dans beaucoup de banques, tu pouvais te brosser pour voir un projet bloqué pour une raison de sécurité… genre “c’est stratégique”, “on a des délais à tenir”, “nos partenaires s’impatientent” … on fait une fiche de risque et on la classe verticalement …
Et les pires transgressions que j’ai vu question sécurité dans le monde bancaire… venaient de projets sécurité où quelqu’un avec trop de budget à dépenser achetait des solutions “sécurité” mal ficelées qui obligeaient à casser la sécurité des systèmes pour pouvoir marcher … “ah non, ça ne marche pas avec selinux actif”, “ah non, ‘nosuid’ sur la partition /home, ça bloque la solution”, “non, il faut changer les permissions sur /etc/shadow car l’outil doit pouvoir écrite dedans”, “vous devez désactiver iptables ou notre outil ne peut pas détecter les applications vulnérables” … ou encore mon préféré: “Non, c’est un projet sécurité, c’est urgent, tu dois donner accès root sur tous les systèmes à ce consultant pour qu’il puisse faire tourner ses
rootkitsoutils partout, et non tu n’as pas à auditer son code avant, mais bien sûr c’est ta responsabilité s’il casse un truc”#1.8
On n’a pas du bosser dans la même. J’ai clairement pu mettre un projet en attente le temps qu’ils résolvent leurs problèmes de sécurité. Bien évidemment, ça ne veut pas dire que c’est toujours le cas dans cette banque, mais pour en avoir parlé avec d’autres ingés sécu là-bas, c’était plutôt normal apparemment.
#1.7
Pareil ici, un serveur partenaire qui n’accepte que ssh-rsa alors que chez nous, maintenant, sur les nouveaux serveurs, par défaut c’est bloqué dans la config. Et qui a du débloquer ça, bibi. le partenaire ne va bien sûr pas évoluer, pourquoi faire, ça marche bien comme ça depuis 10 ans.
#2
En pratique, il devrait s’agir de la mise à jour majeure 23H2 de Windows 11 et de Windows 12.
Ne serait-ce pas windows 10 et windows 11 ? Windows 12 pas encore sorti aurait déjà une mise à jour majeure ?
#2.1
Windows 12 et la mise à jour majeure 23H2 de Windows 11
Comme ça pas de confusion
#2.2
Plus simplement, j’aurais écrit “les mises à jour majeures de Windows 11 et 12”
#2.3
Ah bien vu, la phrase prête à confusion :-)
#3
Il y a pas mal de contextes où des gens se retrouvent a faire de l’administration système un peu contre leur gré. Dans des associations par exemple.
Le fait que des softs majeurs tels que nginx ou samba nécessitent ce type de compétences pour atteindre un niveau de sécurité raisonnable me paraît problématique.
#3.1
Ce n’est pas problématique, ce qui est problématique est de vouloir gérer ce genre de système sans investir dans la compétence nécessaire pour le faire.
#3.2
Comme le dit ragoutoutou, le souci n’est pas le soft, mais l’incompétence des admins. Si personne dans la structure n’a les compétences nécessaires, il existe des hébergements clé en main (et pour vraiment pas cher s’il s’agit juste d’avoir un petit site vitrine/blog pour son asso).
Le problème ici c’est ni Edge ni Windows…
#4
Il est pourtant pas si loin ce temps, quelques mois, que je modifiais le paramétrage par défaut de Edge, réactivant ces vieilles versions de TLS pour permettre à des collaborateurs de se connecter à un serveur interne d’une grande entreprise d’ingénierie française.
#5
Il reste utile de pouvoir se connecter à de vieux équipements plus mis à jour.
Je pense à des switchs, à des KVM,…
#5.1
Si tu fais du 802.1x sur des vieilles installations ça peut poser problème, mais je pense qu’il doit être possible de déroger et d’utiliser du TLS 1.1 malgré tout.
#5.2
Dans ce cas autant y accéder en HTTP, ça pose moins de soucis.
Chez moi j’ai de vieux devices (antennes wifi) qui ne supportent pas le TLS 1.2 (seulement la 1.0), ben j’ai basculé en HTTP. Sinon il faut à chaque fois réactiver le support sur les navigateurs récents et c’est… chiant.
#5.3
Selon le type de matos, on peut mettre l’interface de gestion sur un segment réseau différent, ce qui peut permettre de parquer les interfaces à problème sur un environnement séparé, voir carrément non routé…
#5.4
Yep. Faudrait que je le fasse, vu que mon switch supporte les VLAN, mais flemme
En plus c’est prévu de base, y’a juste à sélectionner le port/VLAN voulu sur l’interface web (sur les antennes je parle) et le switch aussi, d’ailleurs.
#6
Quand tu peux….
Bien souvent tu peux carrément pas.
Je pense à des KVM dont je parlais avec des applets java moisies, de vieux switchs, mais aussi de vieux IDRAC / ILOE de serveurs.
Alors oui bien sur tu parques ça sur un segment réseau spécifique, mais le problème est que si ils retirent le support du navigateur ben même en sachant ce que tu fais tu peux plus….
Alors oui si il faut il faudra monter une VM avec une debian 9 mais bon… c’est un peu con…
#6.1
Ce genre de matos, c’est encore une autre paires de manches en effet. Quelle bonne idée d’avoir intégré du java là dedans…
#7
J’ai une question bête : dans quel cas Windows utilise t-il TLS, autre que via un navigateur ?
#7.1
Ça sert dès que tu installes IIS par exemple. Ça sert aussi pour compatibilité avec des vieilles versions du bureau à distance et d’autres services de ce genre.
C’est d’ailleurs galère : sur un Windows server 2012 par exemple, il faut exécuter un script powershell pour désactiver SSL2 et 3 ainsi que TLS 1.0 et 1.1. Sur des version plus récentes, SSL est bien désactivé mais pas les vieux TLS.
#7.4
Merci pour vos retours : j’avais pas pensé à l’utilisation des librairies fournies avec l’OS.
Je pensais qu’on utilisait des librairies fournies avec le framework ou des librairies “indépendantes”.
#7.2
Toute application qui utiliserait les librairies natives de Windows “Secure Channel” …
#7.3
Beaucoup d’applications de nos jours communiquent avec internet, souvent via des API accessibles via HTTP.
L’iDRAC de mon T620 qui n’est plus tout jeune est accessible sans problème avec les protocoles actuels. Bien sûr, il faut l’avoir mis à jour…
#8
Idée reçue №1 : les administrateurs systèmes décident toujours de la technologie qu’ils peuvent employer.
Par pitié : évitez de taper sur les bouts de chaîne. C’est bien souvent la double peine pour elles. Tapez plus haut, plus fort… plus cher.
Idée reçue №2 : les structures ayant le moins de moyens sont celles où les choses sont le plus mal faites.
Des structures à but lucratif ayant les moyens de réaliser les choses correctement ne le font pas par manque d’intérêt (pas de but lucratif & absence de pénalité), et parfois par désorganisation massive chronique.
Idée reçue №3 : une situation déplorable résulte toujours d’une volonté affirmée.
L’absence d’intérêt/de prise de décision est bien souvent plus destructrice. L’absence de choix est un choix.
#9
Idée reçue N¨4: faire une phrase bien construite mais pas en lien avec l’argumentaire précédent et s’y rattachent le moins possible donne l’impression d’être posé et réfléchi.
#10
Merci de lire avant de dégommer les posts des autres avec des arguments hors sujet. A aucun moment je n’ai parlé de moyens financiers.
Dans une association, on fait ce que l’on peut et on a pas forcément la chance de compter sur des compétences internes et encore moins la garantie d’une pérennité de ces compétences.
Les membres des bureaux des associations se retrouvent donc avec une dette technique importante et parfois des années d’abandon faute de savoir faire ou même de conscience du problème. C’est donc en premier lieu un problème de compétences internes.
Enfin, même si la structure peut se payer des solutions payantes, il faut un minimum de compétences pour choisir la bonne solution et le prestataire qui convient.
Pour terminer, il s’agit de situations que je vis au quotidiens dans plusieurs cadres associatifs donc tu peux ravaler les « idées reçues ».
#11
Il y a une différence entre avoir le choix de la techno employée, et correctement configurer la solution lors du déploiement initial. Autant l’admin sys n’a pas forcément le choix de la techno, autant il est censé savoir correctement configurer les systèmes qu’il administre.
#12
Ce qu’il voulait surtout dire c’est que c’est pas forcément différent quand la structure est plus grosse, même si théoriquement elle aurait les moyens de se payer ce qui te manque ici, ce n’est pas pour autant qu’elle le fera, c’est là qu’est l’idée reçue à mon sens.
#13
Sauf que j’ai parlé des petites associations initialement et je me suis bien gardé de donner un avis sur les structures plus grosses ou commerciales vu que je ne sais pas ce qui s’y passe. Donc il n’y a aucune idée reçue, juste un témoignage bien concret.
#14
Bon je sais pas, vous vous êtes pas compris, moi je comprends bien l’idée de ce qu’il a dit et ça me semble compatible avec ce que tu dis et sans dénigrement.