Discussion:Transport Layer Security

message: Le ton de cet article me semble plus partisant que encyclopédique. Quelques exemples :
"Avec un système SSL/TLS, tous les risques sont écartés, et le client ne risque absolument rien. " Le "absolument" me semble un peu fort...
"qui est, d'après différentes études, environ 20 fois plus risqué que d'utiliser la toute première version de SSL". Cette affirmation manque de référence.
"Depuis 2002 jusqu'à ce jour, en 2009, absolument aucune attaque n'a été réalisée sur le protocole SSL,(...)" . Ce absolument est fort aussi... Il vaut peut être mieux dire qu'on n'a pas connaissance d'attaque qui ai réussi.
"Le protocole SSL v3.1 est actuellement le protocole de chiffrage le plus sûr au monde, et est considéré comme inviolable" Manque de référence.
----
"Avec un système SSL/TLS, tous les risques sont écartés, et le client ne risque absolument rien. Il serait d'ailleurs paradoxal de n'avoir pas confiance en cette technologie, et de préférer réaliser un paiement par chèque ou par mandat, qui est, d'après différentes études, environ 20 fois plus risqué que d'utiliser la toute première version de SSL. De plus il est à noter que les distributeurs bancaires courants utilisent presque tous cette même technologie pour faire transiter les informations vers la banque, et utilisent parfois même une version plus ancienne de SSL que les sites de e-commerce actuels, et sont donc pour certains vraisemblablement moins sécurisés (mais tout de même inviolables) qu'un achat sur Internet. Voila de quoi rassurer les anxieux."
Ha ha ha ha. Ha ha. Hum. Je propose humblement la suppression de ce passage de l'article, et son remplacement par quelque chose de plus neutre. "Le protocole SSL 3.0 est considéré comme l'un des plus sûr protocole de sécurisation actuellement en service sur le web. Bien que, comme tout système de cryptage, sa sûreté ne puisse jamais être prouvé avec certitude, le grand nombre de banque l'utilisant est généralement considéré comme un gage de sa résistance aux attaques malveillantes.". Ou quelque chose dans ce gout là, quoi. 195.5.192.158 (d) 9 septembre 2009 à 12:12 (CEST)
thread_title:  Ton de l'article 

message: Globalement l'article manque de structure, d'équilibre ou de cohérence (rayez les mentions inutiles).
La partie fonctionnement par exemple. L'article traite d'un sujet technique et pourtant la section concernant le fonctionnement est très légère.
La partie "Authentification du client SSL par certificat numérique" devrait être une sous-partie de "Fonctionnement" (la certification fait partie intégrante du protocole de sécurisation, elle n'est pas optionnelle). "Authentification du client SSL par certificat numérique" devrait peut-être renommé en "Certification d'authentification" (je trouve çà moins capillo-tracté :).
Ma dernière remarque concerne le lien externe "Utilisation du SSL". Je ne comprends pas la relation entre le titre du lien et l'article pointé.
The s0rc3r (d) 31 août 2009 à 23:23 (CEST)
thread_title:  Autres remarques 

message: Il s'agit d'un seul et même sujet qui est, selon les interwikis, traité sous un titre ou sous l'autre. Puisque TLS regroupe un sens plus large que SSL, je propose une fusion dans cet article (notamment dans la section Transport_Layer_Security#Protocole_SSL).
Cf. aussi la demande renommage récente sur SSL, où les avis étaient unanimes pour la fusion. Bibi Saint-Pol (sprechen) 4 novembre 2014 à 11:20 (CET)
thread_title:  Fusion de [[Secure Sockets Layer]] et [[Transport Layer Security]] 

message: Ce paragraphe présent depuis 2009 n'est pas très compréhensible (dès l'origine et les réécritures n'ont rien arrangé), on comprend quand même vaguement à l'avant dernière phrase qu'il s'agit d'une attaque man in the middle, par le biais de la mise en place d'un genre de proxy, sur lequel les communications vont transiter en clair, pas du tout de la "sécurisation du protocole". Ca parait confirmé par le blog en source  accessible via l'archivage. Maintenant c'est un article de blog disparu datant de 2009 et qui décrit la sécurité d'un point de vue très particulier, celui d'une entreprise qui veut casser à son profit la sécurité du protocole pour surveiller les entrées et sorties de son réseau. Ca vaudrait probablement le coup d'en parler, mais au chapitre "attaques" et à partir d'une source solide et plus récente (tout ça n'est pas si évident, sur quoi faut-il avoir la main, par ex. Pour que ça ne se voit pas sur les postes clients ? Et bien-sûr c'est pour le moins criticable comme pratique). Je propose d'effacer ce § en attendant, parce que là ça n'est vraiment pas du tout correct (ça n'a été sauvé jusqu'à présent que parce que c'est assez incompréhensible ama). Proz (discuter) 18 novembre 2014 à 23:20 (CET)
thread_title:  Sécurisation du protocole (?!) 

message: Proposé par : ✍TramwaySuspendu (talk) 29 mars 2018 à 03:49 (CEST)
thread_title:  "Le fond de cet article est à vérifier" - relecture technique nécessaire 

message: Bonjour,
Sans être entièrement faux, cet article contient de nombreuses approximations, pour lesquelles on pourrait trouver des sources allant dans le sens de l'erreur lorsqu'elles ne sont pas déjà présentes.
Je m'explique, tout ce qui est SSL/TLS, ça n'est pas épargné par l'évolution technologique. Au moins deux évolutions majeures impliquent de faire la chasse aux erreurs sur ce qui était vrai avant et ne l'est plus maintenant :
* l'apparition du Server Name Indicator (en),
* les adaptations de protocole pour éviter la latence parfois inutiles/optimisables liées au pingpong clinet/serveur à l'initialisation de la connexion.
Une relecture et une vérification technique me semblent donc nécessaires, et il y a surement des raisons supplémentaires qui ont échappé à mon coup d’œil rapide...
✍TramwaySuspendu (talk) 29 mars 2018 à 03:49 (CEST)
thread_title:  Raisons de la demande de vérification