gni???
Je ne connais pas mes utilisateurs (ils sont anonymes! Ca ne marche pas, ils partent et je ne les revoient jamais; et au pire, ils écrivent dans les forum que je suis pourri car ça ne marche pas chez eux et que je suis le seul à faire chier car je n'ai pas fait un choix collégial, bon la à la limite du coup je peux les contacter, un par un... Mais trop cher, donc non).
À mon avis le problème de compréhension doit venir de là. Aries ne doit pas faire de commerce, et donc de la relation client; ou alors sur un marché de niche avec des clients qui comprennent la problématique.
Si je résume la situation, telle que je l'ai comprise :
le serveur supporte une liste LS de suites de chiffrement possibles
le client supporte une liste LC de suites de chiffrement possibles
pour savoir si une attaque de type downgrade est possible, on prend le plus petit dénominateur commun des deux liste : à savoir l'intersection de LS et LC. Si cette dernière comporte une suite faillible, une attaque active par un homme du milieu est possible : la sécurité de la communication n'est pas garantie à 100 %.
La condition nécessaire et suffisante pour sécuriser la communication est donc que l'intersection ne contienne pas de suite faillible. Comme il s'agit d'une intersection, cette condition peut aussi se formuler ainsi :
soit LS n'a pas de suite faillible (sécurisation par le serveur)
soit LC n'a pas de suite faillible (sécurisation par le client)
Cette dernière formulation, qui est celle proposée par Xion345, est une disjonction (non exclusive) : ou bien la configuration serveur garantie la sécurisation, ou bien la configuration client garantie la sécurisation.
Le problème qui se pose pour chacune des parties est donc la suivante : comment faire pour que tous ceux à qui je m'adresse (tous les clients pour un serveur, tous les serveurs pour un client) m'assurent une intersection non vide et sans suite faillible ?
En dehors d'une coordination complète entre tous les serveurs et tous les clients, qui est impossible, un tel problème n'a pas de solution absolue.
Un serveur, qui est un fournisseur de service, cherchera avant tout à s'assurer le marché le plus large possible : son intérêt est donc de supporter le plus de suites possibles, et donc également les faillibles, afin de se garantir que l'intersection est non vide. Le critère qu'il cherchera à optimiser en priorité est le côté non vide et non l'absence de suites faillibles. Et sauf s'il est sur un marché de niche, avec des clients au fait des problèmes de sécurité, la meilleure solution pour lui est de supporter le plus de suites possibles.
Du côté du client, s'il veut s'assurer la sécurité il ne doit pas supporter de suites faillibles. Il prend le risque d'avoir des intersections vides, et de ne pas communiquer de manière sécurisée avec certains services, mais de toute façon cette sécurité n'était que de façade. Au final, c'est le service qui prend surtout le risque de perdre un client.
Dans un système commerciale de libre concurrence, la pression vient toujours du client : si une concurrent propose un service en plus que l'on ne fournit pas — ceteris paribus — alors, à terme, la clientèle ira chez lui.
Alors, certes, le client du modèle client-serveur n'est pas la même personne que le client du modèle client-service. Ce dernier ne développe pas lui-même son navigateur-client : il est également client, sur le plan commercial, du développeur-service de son navigateur. Mais quel est le rapport numérique entre le nombre de navigateurs et le nombre de service web ?
Si Chrome et Firefox, qui représente une bonne part de marché, retirent le support des vielles suites, tout en communicant visuellement dans leur interface sur les raisons de l'absence de chiffrement dans une communication lors de la connexion à un serveur mal configuré : qu'adviendra-t-il ? Les utilisateurs changeront de navigateur pour pouvoir tout de même se connecter au site, ou l'administrateur adaptera sa configuration pour ne pas perdre de client ?
Je laisse chacun apporter la réponse qu'il souhaite à cette dernière question.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Let’s Encrypt
Posté par kantien . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
À mon avis le problème de compréhension doit venir de là. Aries ne doit pas faire de commerce, et donc de la relation client; ou alors sur un marché de niche avec des clients qui comprennent la problématique.
Si je résume la situation, telle que je l'ai comprise :
pour savoir si une attaque de type downgrade est possible, on prend le plus petit dénominateur commun des deux liste : à savoir l'intersection de LS et LC. Si cette dernière comporte une suite faillible, une attaque active par un homme du milieu est possible : la sécurité de la communication n'est pas garantie à 100 %.
La condition nécessaire et suffisante pour sécuriser la communication est donc que l'intersection ne contienne pas de suite faillible. Comme il s'agit d'une intersection, cette condition peut aussi se formuler ainsi :
Cette dernière formulation, qui est celle proposée par Xion345, est une disjonction (non exclusive) : ou bien la configuration serveur garantie la sécurisation, ou bien la configuration client garantie la sécurisation.
Le problème qui se pose pour chacune des parties est donc la suivante : comment faire pour que tous ceux à qui je m'adresse (tous les clients pour un serveur, tous les serveurs pour un client) m'assurent une intersection non vide et sans suite faillible ?
En dehors d'une coordination complète entre tous les serveurs et tous les clients, qui est impossible, un tel problème n'a pas de solution absolue.
Un serveur, qui est un fournisseur de service, cherchera avant tout à s'assurer le marché le plus large possible : son intérêt est donc de supporter le plus de suites possibles, et donc également les faillibles, afin de se garantir que l'intersection est non vide. Le critère qu'il cherchera à optimiser en priorité est le côté non vide et non l'absence de suites faillibles. Et sauf s'il est sur un marché de niche, avec des clients au fait des problèmes de sécurité, la meilleure solution pour lui est de supporter le plus de suites possibles.
Du côté du client, s'il veut s'assurer la sécurité il ne doit pas supporter de suites faillibles. Il prend le risque d'avoir des intersections vides, et de ne pas communiquer de manière sécurisée avec certains services, mais de toute façon cette sécurité n'était que de façade. Au final, c'est le service qui prend surtout le risque de perdre un client.
Dans un système commerciale de libre concurrence, la pression vient toujours du client : si une concurrent propose un service en plus que l'on ne fournit pas — ceteris paribus — alors, à terme, la clientèle ira chez lui.
Alors, certes, le client du modèle client-serveur n'est pas la même personne que le client du modèle client-service. Ce dernier ne développe pas lui-même son navigateur-client : il est également client, sur le plan commercial, du développeur-service de son navigateur. Mais quel est le rapport numérique entre le nombre de navigateurs et le nombre de service web ?
Si Chrome et Firefox, qui représente une bonne part de marché, retirent le support des vielles suites, tout en communicant visuellement dans leur interface sur les raisons de l'absence de chiffrement dans une communication lors de la connexion à un serveur mal configuré : qu'adviendra-t-il ? Les utilisateurs changeront de navigateur pour pouvoir tout de même se connecter au site, ou l'administrateur adaptera sa configuration pour ne pas perdre de client ?
Je laisse chacun apporter la réponse qu'il souhaite à cette dernière question.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.