Archives de catégorie : A retravailler

Ransomware

Un ransomware (ou rançongiciel) est un programme malveillant qui bloque l’accès à votre poste ou à vos données, en réclamant une rançon pour le débloquer. La plupart du temps, les données du poste sont chiffrées (données locales mais aussi les données des partages réseaux). 

Le déchiffrement est impossible, et les pirates ne redonnent pas nécessairement l’accès aux données, même en payant la rançon, souvent par manque de compétence.

En pratique

Comment éviter d’être touché ?

Ce programme malveillant se propage via des mails contenant soit un fichier exécutable dans une archive, soit un lien vers un site web compromis. La vigilance reste de mise : n’ouvrez jamais des pièces-jointes de mails douteux, et ne cliquez jamais sur des fichiers exécutables (.exe, .scr, .cab…), même si le mail semble provenir d’un expéditeur connu.

Par ailleurs, une bonne pratique est de réaliser régulièrement des sauvegardes de ses données importantes, autant à titre professionnel qu’à titre personnel. 

Quelle réaction si j’ai ouvert une pièce-jointe suspecte ?

Tout d’abord, sachez qu’il ne sert en général à rien de payer la rançon : les pirates ne proposent que très rarement un service après vente…

Les seules actions à entreprendre sont de contacter immédiatement votre correspondant sécurité (si vous êtes en entreprise) et d’éteindre votre poste immédiatement pour arrêter le processus de chiffrement et limiter les dégâts, surtout si vous n’avez pas de sauvegarde.

Par ailleurs, il est conseillé de ne pas rallumer le PC ni de se connecter à sa session (dans le cas des utilisateurs Citrix) avant que la désinfection ne soit confirmée.

Creusons

Regardons ce qui s’est passé du côté de deux grandes affaires récentes.

WannaCrypt et NotPetya

Tout d’abord un grand bravo et un grand merci aux Shadow Brokers : pour avoir (officiellement) voulu empêcher la NSA de nous espionner (en révélant leurs outils), ils nous empêchent juste d’utiliser nos ordis. On dirait du Wikileaks ou des Anonymous…  

Ces empaffés sont loin de connaître le principe de responsible disclosure, même s’il est vrai que les outils qu’ils ont mis au jour utilisaient des failles corrigées par Microsoft, mais force est de constater que la mise-à-jour des systèmes informatiques est une discipline difficile, et qu’il est à peu près certain qu’une faille même corrigée peut être exploitée encore longtemps ! Leur seule excuse est qu’ils sont peut-être liés à des acteurs russes1 ou autres, dont l’intérêt est au contraire de perturber le plus possible les systèmes d’informations étrangers (et la NSA du même coup).

Premier bilan

Des dizaines de milliers d’ordinateurs contaminés2 par WannaCrypt ! Moi je dis : chapeau. Ces publications sont une aubaine pour les perturbateurs de tout poil (cybercriminels, états, groupe d’intérêts divers)3.

Cyberattaque

On a parlé dans les media de cyberattaque. Mais ça n’est pas parce que les dégâts sont visibles et parfois importants que nous sommes face à une vraie cyberattaque. Ici, on s’approche plus de la pêche à la ligne que dans la salve de roquettes : on balance un  hameçon et on regarde ce qu’on accroche au fil du temps. On est plus confronté à une cyberdéfaillance ou une cyberinfection qu’à une cyberattaque : l’ampleur des dégâts est proportionnelle à la négligence des services IT qui tardent à faire passer les mises-à-jour de sécurité ou à migrer sur des produits maintenus. Maintenant, les causes profondes peuvent être diverses (le budget IT étant sujet à tellement de contraintes…).

Et ensuite ?

Après, peu importe qui est derrière l’attaque (bien que ce mot soit galvaudé et hors de propos, cf. les propos de Jean-Marc Manach4, bien que je sois habituellement méfiant de ce qui vient de Slate.fr) : n’importe qui peut être derrière5, et c’est bien le problème. Il va falloir vivre avec cet héritage de la NSA et de toutes les agences de renseignements du monde dont une cible majeure est désormais nos ordinateurs ; enfin, les ordinateurs des méchants, mais les programmes malveillants ne font pas la différence, et si ces derniers tombent dans des mains criminelles ou inexpérimentées, le scenario de WannaCry se reproduira.

Il faudra redoubler d’attention lors des sauvegardes afin de ne pas sauvegarder les fichiers chiffrés ! Ou sinon s’assurer qu’une gestion de version conservera les versions précédentes, accessibles à l’utilisateur légitime. Microsoft a intégré une protection6 contre le chiffrement non souhaité dans ses solutions Office 365/OneDrive et Outlook. Reste que j’aimerai bien que Microsoft mette également une solution de chiffrement souhaité.

Quand à NotPetya, arrivé dans la foulée, d’autres éléments tendent à nous faire penser que l’apparence est trompeuse et qu’il s’agirait plutôt d’une véritable attaque informatique camouflée en ransomware ! Chiffrer des données sans garder aucun trace de la clé de chiffrement constitue un très bon moyen d’effacer ces données7, et donc potentiellement toutes les traces d’une activité illégale.

Voilà l’occasion de rappeler que l’attribution d’une attaque est souvent difficile.

Faut pas payer mais pourtant…

En 2019, les attaquants se sont rendus compte qu’une entreprise était bien plus disposée à payer pour récupérer ses données, car il est souvent plus facile de le faire en payant la rançon qu’en restaurant à partir de sauvegardes (on a vu en pratique que cela peut prendre plusieurs semaines). Exemples : Baltimore, Cognac…

Ainsi, deux fois plus d’entreprises (40% en 2019 contre 19% en 2018) touchées par un ransomware on payé la rançon pour récupérer leurs données. Un signal très positif pour les cybercriminels… De son côté le FBI estime que 140 millions de dollars de rançon8 ont été versés en six ans.

Après, on peut aussi prendre une assurance couvrant ce risque, mais certaines d’entre elles conseillent, lorsque le sinistre se produit, de… payer la rançon ! Car cela coûte moins cher que de remettre en état le SI, et donc l’assureur aura moins d’argent à débourser en remboursant l’équivalent de la rançon… C’est du joli !

Voir aussi :

Des exemples à ne pas suivre

Voilà ce qui arrive quand on paye : ça recommence ! Une fois la rançon payée pour éviter la divulgation, que vont faire les pirates qui s’ennuie ? Ils vont redemander une rançon… Ca peut durer longtemps.

Les recommandations du FBI

De plus en plus sollicité sur le sujet, le FBI a émis les recommandations suivantes :

  • Ne pas payer !
  • Avoir des sauvegardes hors-ligne de ses données essentielles (et plus) ;
  • Avoir des copies des données essentielles en ligne dans le cloud (NDLA : chiffrées) ou sur un disque externe (un peu redondant avec la précédente, mais on peut interpréter cela comme « avoir plusieurs jeux de sauvegardes sur différents supports ») ;
  • Sécuriser ses sauvegardes, en les rendant inaccessibles aux intrus (au moins interdire les modifications et l’effacement) ;
  • Avoir un antivirus sur chaque terminal (çà ne mange pas de pain) ;
  • N’utiliser que des réseaux sûrs et maîtrisés (facile à dire !), imposer les VPN pour les connexions externes, éviter les Wifi publics ;
  • Utiliser une authentification renforcée (au moins deux facteurs robustes) ;
  • Mettre-à-jour les postes et applications (NDLA : et les infras) avec les correctifs de sécurité ASAP.

A bien y regarder, ce sont les conseils de base pour tout système informatique, quelle que soit la menace.

Sources

DNS

Le protocole DNS permet de connaître l’adresse réelle d’un serveur web. Plus précisément cela transforme le nom de domaine inclus dans une URL (adresse symbolique du genre https://secu.si) en adresse technique (adresse IP).

Pour cela, de très nombreux serveurs se répartissent la tâche sur toute la planète web. Pour des raisons d’efficacité, nous nous retrouvons souvent connectés directement à un serveur géré par notre fournisseur d’accès internet. Rien de bien fameux, sauf que les fournisseurs d’accès gardent souvent des traces, pour leur usage propre ou parce qu’on leur demande1.

Vie privée ?

A priori pas d’influence de l’utilisation d’un service de DNS sur sa vie privé. Et pourtant…

Transparence et traçabilité

Nous laissons des traces de notre activité dès qu’on sollicite ces serveurs DNS classiques. Même en navigation privée, le serveur DNS sait sur quels sites nous surfons. Il peut aussi interdire la navigation sur certains sites qui lui sont désignés par le pouvoir public.

Autre problème : il existe plusieurs types d’attaques sur la résolution de nom de domaine via DNS. D’où l’intérêt d’utiliser un service DNS à la fois respectueux de la vie privée mais également sécurisé. On peut par exemple savoir ce que vous faites, même si le serveur ne garde pas de traces d’activité, en écoutant les requêtes DNS circulant de façon non sécurisée, en clair.

DNSSEC

?

Les différentes options

Le serveur FAI

L’avantage premier d’utiliser le serveur du FAI est de rester dans la légalité (et donc dans la censure dans certains pays), ainsi que la simplicité d’utilisation vu que c’est le paramétrage par défaut à l’installation de votre ligne d’accès internet.

Les services dédiés

Tout dépend ensuite de la confiance que vous accordez au fournisseur que vous allez sélectionner. Il s’agit parfois d’un moindre mal : on accepte les défauts et contraintes des fournisseurs pour pouvoir contourner des blocages de type censure.

Google

Google n’est pas forcément votre ami. Oui, il vous aide à trouver presque tout ce que vous voulez, mais quand il propose des services périphériques, il y a souvent anguille sous roche. Certes il est très rapide, il y a des gens qui ont essayé, et je suppose qu’ils ont eu de problèmes. Je suppose, soyons honnête, je n’ai pas entendu de cas suspect suite à l’utilisation de Google DNS, mais si techniquement il est extrêmement rapide (c’est vrai), il appartient à Google dont le principal revenu est la publicité, et donc son fond de commerce2 est basé sur le ciblage des utilisateurs. Méfiance, donc.

Les IP du Google DNS sont :

  • 8.8.8.8
  • 8.8.4.4

Des IP simples, on n’en attendait pas moins d’un géant du web.

Quad9

Cette solution est un peu particulière, car il existe deux versions :

  • 9.9.9.9 ou 2620:fe::fe qui utilise DNSSEC et qui renvoie une liste filtrée et épurée des IP dangereuses ou malveillantes, comme celles utilisées par des botnets ;
  • 9.9.9.10 ou 2620:fe::10 qui ne filtre rien, mais qui ne fait pas de DNSSEC contrairement à 9.9.9.9.

Proposée au départ par IBM via X-Force3, elle est gérée par une association à but non lucratif. Pas mal non plus pour le choix des adresses IP.

OpenDNS

Je ne connais pas bien OpenDNS, mais le service a connu des oppositions liées à l’usage publicitaire ayant été fait des données d’utilisation. Aujourd’hui cela appartient à Cisco, la publicité a été arrêtée4, mais là encore la méfiance est de mise.

CloudFlare

CloudFlare est connu pour ses solutions industrielles, notamment anti-DDoS, ayant servi dans différents événements et attaques. Sans être philanthrope, on sait que cette société tient à garder une image propre et elle est plutôt encline à défendre la veuve, l’orphelin et l’internaute.

En avril 2018, CloudFlare a lancé un service de DNS gratuit et sécurisé sur l’adresse IP 1.1.1.1 (chapeau pour avoir mis la main sur cette adresse5).

SPOF

CloudFlare ou Quad9 sont bien placés pour emporter la mise et protéger notre vie privée. Attention toutefois au paramétrage de vos serveurs DNS : une bonne idée pourrait être de panacher les fournisseurs pour éviter le risque de déni de service, car on tombe dans le risque du SPOF si on ne choisit qu’un seul fournisseur. Par contre il faut avoir bien confiance en les deux que vous retiendrez.

Références

Microservices

L’architecture en microservices est une approche intéressante dans la construction de systèmes d’informations, en particulier sur des infrastructures cloud où ce type d’architecture s’adapte naturellement. Cependant, cela reste un choix d’architecture, dans la filiation du SOA, avec des cas d’usage plus ou moins adaptés1.

En premier lieu, construire une architecture en microservices implique de choisir un niveau de granularité (de finesse) des services, qui n’obéit à aucune règle prédéfinie : on propose généralement d’avoir un service par fonctionnalité, mais plus le service est gros, plus on se rapproche d’une application monolithique, et à l’inverse plus le service est fin, plus la complexité induite peut être importante. Il faut donc que le service (ou la fonctionnalité) soit suffisamment indépendante du reste mais pas trop complexe non plus.

La transition entre l’architecture monolithique des applications des années 90 et les applications à base de microservices actuelles. © PWC via JDN

Ensuite on les fait communiquer et interagir, soit par des API REST, soit par des échanges asynchrones. Ces derniers sont peu évoluées, mais robustes : leur but n’est pas d’ajouter des fonctionnalités mais uniquement d’assurer un échange fiable de messages et d’informations entre plusieurs services, justement en n’ayant que peu ou pas de couplage ou de friction.

Enfin, on orchestre ces services, en les déployant, en les monitorant, etc. Souvent, l’organisation DevOps est adaptée à cette architecture, en institutionnalisant l’indépendance des équipes et donc des services composants le système final. L’équipe DevOps doit en théorie être responsable de son service, y compris de son suivi en production, mais certains éléments comme la sécurité du service et la sécurité globale du système sont difficiles à positionner dans ce contexte.

Le passage à une architecture en microservices est l’occasion d’adopter une organisation de type DevOps. Ca manque toutefois un peu de sécurité, non ? © Adrian Cockcroft / Slideshare via JDN

Facebook

Facebook mérite à lui tout seul toute notre attention et toutes nos critiques. Vu la position dominante du réseau social, et son pouvoir d’influence, il devrait être irréprochable et il ne l’est pas. Un peu comme YouTube, d’ailleurs, quand on y pense.

Pire que les autres ?

La vie privée est (encore) un droit.

La vie privée est (encore un peu) un droit.

Je ne crois pas que FB soit pire que les autres, mais comme je le dis en introduction, vu sa position et la quantité de données personnelles qu’il charrie, la moindre erreur a des conséquences colossales. Cela dit, le business de FB est celui des données (très) personnelles, et pour attirer un maximum d’utilisateurs, il doit en collecter un maximum de façon à répondre à leur curiosité.

Un bug et ses conséquences

Prenons un exemple concret. En mai 20181, suite à une erreur lors d’un test interne, Facebook a modifié les paramètres de confidentialité de 14 millions d’utilisateurs. Le tir n’a été corrigé que plusieurs jours plus tard.

Trop tard

Comme souvent en informatique, Facebook a commis l’erreur inexcusable de ne penser aux conséquences de son activité que bien trop tard, alors que le site était déjà lancé et que le nombre d’utilisateurs dépassait l’imagination de ses concepteurs. Facebook a été créé en 2004, et ce n’est qu’en 2018 qu’il commence à se dire qu’il n’a peut-être pas bien pris en compte tous les enjeux de son activité, principalement sur la vie privée des utilisateurs, mais aussi sur l’influence qu’il peut avoir y compris sur des élections.

Notons.

  • L’application Facebook sur Android récupère des SMS et des données sur les appels (ArsTechnica)
  • Les données d’utilisateurs Facebook détournées (Digital Journal)
  • Deux milliards de comptes compromis par Cambridge Analytica (Hacker News)
  • Communiqué Facebook sur les données collectées (Facebook)
  • Analyse NextInpact sur une fuite de données concernant 50 millions d’utilisaterus (NextInpact)
  • Récupération de données sans même avoir de compte ! (The Register)

L’aveu

Je prends ça comme un aveu d’impuissance mais aussi d’incompétence : Mark Zuckerberg en appelle aux gouvernements pour l’aider à réguler le contenu des réseaux sociaux, dont le sien2. Trop fort : on fait des conneries, on a trop d’influence et on ne sait pas le gérer, donc faites-le pour nous.

Quelques fuites de données

Le coup du mot de passe

Un « incident » qui en dit long : mars 2019, on apprend que Facebook stockait des centaines de millions de mots de passe… en clair3 ! Il apparaît qu’il s’agit d’une erreur similaire à ce qu’ont pu connaître Twitter et Github4, à savoir des logs contenant le mot de passe en clair.

Est-ce volontaire ?

Je serai tenté de dire oui, mais sans aucune preuve. Il semble qu’ils aient déjà tellement de moyens de récupérer d’informations sur les utilisateurs qu’ils n’ont peut-être pas besoin de ça. Par contre, ça ne va pas les aider en cette période de tentative de reconquérir la confiance des utilisateurs…

Relativisons

Le problème ne touche que l’application Facebook Lite. Donc uniquement quelques centaines de millions d’utilisateurs, et non pas le milliard++ d’inscrits. Et ça ne date que de 2012. Et les logs n’étaient pas accessibles depuis l’extérieur.

La défense périmétrique est, on le sait, infranchissable…

146 Go

Rien de moins ! Et stocké sur des buckets s3 en clair ! Vu en avril 20195, on est presque dans un cas d’école. Ce qu’on comprend dans cette affaire, c’est que des tiers ont accès à une quantité impressionnantes de données sur les utilisateurs Facebook, et donc que pour espérer un peu de sécurité sur FB, il faudrait à la fois que FB réduise la quantité (et le type) de données accessibles aux tiers (ce qui serait contraire à leur modèle économique) et que les tiers en question soient eux aussi plus fiables. Autant dire que ça n’arrivera jamais.

Plus d’infos sur le site d’UpGuard.

Autres « bugs »

  • Mai 2019 : une faille dans WhatsApp (= Facebook) permet l’installation de logiciel malveillant6 sans aucune action utilisateur.
  • Fin 2019, pas de chance : un disque dur non chiffré contenant des données sur les employés de FB a été volé dans une voiture (à sourcer).

Au sujet de WhatsApp, zataz.com propose une analyse intéressante7 selon laquelle cette appli ne sera jamais vraiment sécurisée. Ce qui est surtout intéressant est de remarquer que Telegram est interdit en Iran ou en Russie, et pas WhatsApp qui reste autorisé. Une explication ?

Le coup de la panne

Sous surveillance

Il y avait déjà eu un précédent, a priori mal respecté8…

DMZ

J’ai toujours eu du mal à cerner la notion de DMZ. Pour moi, il s’agit d’une zone sans arme, et je vois difficilement aller au combat (à savoir : se connecter à internet) sans être un minimum équipé.

Pour la clarté de l’explication, le local sera le gentil, l’extérieur sera le méchant, et le gentil cherche à se protéger du méchant.

Dans ce contexte, une DMZ est bien une zone réseau à part, servant de tampon entre les deux zones de conflit (le réseau local et le réseau extérieur, qui est en général internet). Son rôle est bien d’éviter une propagation des menaces de part et d’autre, mais les moyens employés sont bien plus coercitifs qu’un gentleman agreement, avec la différence notable qu’une des parties (le gentil) s’autorise à militariser tout ce qu’il veut, et que le but d’une DMZ réseau est de désarmer uniquement l’attaquant, et non les deux parties simultanément.

DMZ avec un seul pare-feu

Source : wikimedia.org.

Cette solution est simple à mettre en place, mais elle est moins sûre dans l’absolu, car tout repose sur une seule brique : le pare-feu. Cela suffit si la zone à protéger n’est pas trop critique, mais tout problème sur le pare-feu impacte l’efficacité de ce type de DMZ. C’est ce qu’on appelle une SPOF (Single Point Of Failure).

De plus, l’équipement utilisé pour le pare-feu doit savoir gérer tous les types de flux, ainsi que le cloisonnement demandé, ce qui en fait un équipement complexe.

DMZ avec deux pare-feu

Cette architecture est la plus sécurisée, car même si un des pare-feu est attaqué, l’autre reste disponible.

Source : wikimedia.org.

Ici, tout flux provenant d’internet arrive sur le 1er pare-feu, et il est redirigé vers la DMZ : il est donc impossbile d’aller dans le réseau local.

A l’inverse, un utilisateur du réseau local (LAN) peut accéder à la DMZ pour aller chercher ce dont il a besoin. Il peut aussi éventuellement accéder à internet, si on lui en donne l’autorisation (c’est un choix qui n’influe pas directement sur le niveau de sécurité de la DMZ).

Enfin, un équipement se trouvant à l’intérieur de la DMZ n’a accès… à rien : il est bloqué par les deux pare-feu. Il peut y avoir des exceptions, par exemple pour des mises-à-jour logicielles des équipements de la DMZ.

Sources

http://www.commentcamarche.net/contents/995-protection-introduction-a-la-securite-des-reseaux
https://www.1and1.fr/digitalguide/serveur/securite/quest-ce-quune-zone-demilitarisee-dmz/

SSL/TLS

SSL et TLS sont deux noms différents pour la même chose. Enfin presque : il y a eu plusieurs versions de SSL (notamment v2 et v3) puis l’appellation TLS a remplacé SSL. Nous avons donc eu TLS 1.0, puis TLS 1.1 et maintenant TLS 1.2.

SSL est un protocole permettant de sécuriser des échanges de flux réseaux. Comme tout protocole, il n’est constitué que de spécifications : on dit quoi faire et comment. Après, ce sont des programmes (des librairies…) qui implémentent (mettent en oeuvre en pratique) ce protocole.

SuperFish

Etablissement d’une session TLS

Avant d’échanger des messages de façon sécurisée, il faut commencer par se mettre d’accord sur la façon de faire.

Hello client (ClientHello)

Le 1er message est envoyé par le client au serveur. Ce message contient :

  • Le numéro de version de la version TLS la plus récente supportée par le client ;
  • la date et heure client ;
  • 28 octets aléatoires ;
  • un numéro de session (en cas de reprise de session) ;
  • la liste des méthodes cryptographiques supportées par le client ;
  • la liste des méthode de compression supportées ;
  • certaines valeurs spécifiques comme le nom du service demandé (Server Name Indication).

Premier retour serveur

Le serveur va ensuite envoyer un paquet de messages pour avancer dans le dialogue.

Hello serveur (ServerHello)

Le serveur va d’abord poliment renvoyer son bonjour. Il va indiquer :

  • La version du protocole SSL/TLS qu’il souhaite utiliser ;
  • la date et heure côté serveur ;
  • 28 octets aléatoires ;
  • un numéro de session si besoin ;
  • l’algorithme cryptographique et l’algorithme de compression retenus pour cette session, en fonction de ce que supporte le client.

Présentation des certificats du serveur (Certificate)

Le serveur envoie ensuite ses certificats.

à approfondir

Echange de clé serveur (ServerKeyExchange)

Le contenu de cette partie est variable. Elle est fonction de ce qui a été négocié auparavant, principalement des algorithmes cryptographiques retenus.

  • Dans le cas d’un échange de type Diffie-Hellman, ce message contient les paramètres de cet échange. Ils sont générés aléatoirement par le serveur et signés par la clé privée du serveur (sauf dans le cas d’un échangé DH/ECDH anonyme).
  • Dans les autres cas, ce message n’existe pas car les informations nécessaires sont dans le certificat.

Fin du bonjour (HelloDone)

Ce message marque la fin de cette étape. Mais ça n’est pas fini pour autant.

Pre-master secret

Voici maintenant une étape tout aussi importante dans l’établissement de l’échange : l’échange d’un pre-master secret, valeur essentielle pour la connexion, et qui ne doit être connue que des deux parties (Alice et Bob). Il existe plusieurs méthodes pour cela :

  • RSA : la valeur secrète est générée par le client, aléatoirement, et elle est envoyée au serveur chiffrée avec la clé publique du serveur (donc seul le serveur peut la déchiffrer), dans un message ClientKeyExchange.
  • Diffie-Hellman ou Elliptic Curve Diffie-Hellman (DH ou ECDH) : la valeur secrète est négociée via l’algorithme de Diffie-Hellman. Il en existe une variante basée sur les courbes elliptiques. Les paramètres côté serveur sont inclus dans le certificat ; côté client, c’est également dans le certificat si le client en présente un, sinon il doit en générer aléatoirement.
  • Diffie-Hellman Ephemeral (DHE) avec également une variante basée sur les courbes elliptiques (ECDHE) : les valeurs secrètes sont générées aléatoirement, dans tous les cas, et de façon unique pour chaque transaction. Côté serveur, les paramètres sont signés avec sa clé privée.
  • Diffie-Hellman anonyme, avec variante EC : C’est du DHE mais sans chiffrement côté serveur. En conséquence, cette négociation est vulnérable aux attaques MITM.

On en parle, hélas

Oui, on parle de SSL malheureusement, car on se rend compte de son importance et de la menace représentée par les failles du protocole ou de son implémentations. Freak, Poodle ou Heartbleed sont des exemples de failles ayant fortement impacté le monde informatique mais aussi, indirectement, les utilisateurs.

Quelles versions utiliser ?

Le conseil général est le suivant : toujours utiliser la dernièr version quand c’est possible.

Est-ce toujours possible ?

Comme le titre le laisse entendre : non. Comme vu plus haut, la connexion en SSL/TLS se fait sur la base d’une négociation entre le serveur (le site internet) et le client (le navigateur web). Les deux essayent généralement d’utiliser les versions les plus récentes et les plus sécurisées, mais il arrive souvent que les navigateurs ne soient pas à jour et ne connaissent tout simplement pas les versions récentes de TLS.

Y a-t-il des versions à éviter ?

Oui, car certaines versions contiennent des failles intrinsèques (par exemple Poodle). Par ailleurs, avec le temps, certaines attaquent deviennent plus faciles : soit parce qu’elles sont mieux connues, soit parce que la puissance de calcul nécessaire est plus facilement accessible. A fin juin 2015, on considère que SSL v2 et SSL v31 ne doivent plus être utilisées.

Liens

Liens internes

Liens externes