Bonjour à tous,
 
Dans le cadre de mes études informatique, je dois réaliser un exposé sur le protocole SSL.
J'ai donc un plan à respecter dans lequel je dois traiter des limites et de la concurrence lié à ce protocole
 
Concernant les limites, j'avoue de pas avoir dénicher grand chose.  
 
La principale limite du protocole SSL que j'ai pu trouvé est que ce protocole ne sécurise QUE les échanges d'informations et de données entre le poste client et le poste serveur mais ne garantie en aucun cas une sécurité pour les systèmes client ou serveur en eux même.
 
Ainsi, si un pirate installe par exemple un enregistreur de frappe (keylogger) sur le poste client, il sera en mesure de récupérer les mots de passe ou toute information confidentielle, même si celle-ci a été émise lors d'une session SSL.
 
Pour les plus experts d'entre vous, connaissez vous d'autres limites liées au protocole SSL  mis à part celui que j'ai déjà cité ci dessus ?
 
Je dois ensuite traiter de la concurrence de ce protocole et des nouveaux moyens qui peuvent bien le remplacer et combler ses faiblesses. J'ai entendu parlé du protocole SET mais je n'ai pas bien compris ce qu'il apportait de plus par rapport au protocole SSL et s'il était déjà en place sur certain serveur.
 
J'aimerais aussi avoir une précision sur le protocole SSH car je n'ai pas compris quelle était la différence entre SSL et SSH et si SSH était un concurrent à SSL.
 
 
Merci à tous pour vos précisions et passez un bon dimanche    
 
Michaël

Ce sujet a été déplacé de la catégorie Systèmes & Réseaux Pro vers la categorie Emploi & Etudes par Je@nb

Les limites de SSL : il y a pas mal d'attaques dessus (overflow, man-in-the-middle). le gros problème du SSL c'est qu'il ne scale pas bien quand tu as beaucoup de sessions, tu dois donc passer par des équipements d'accélération externes avec des cartes de crypto dédiées. L'accélération SSL a quelques inconvénients : perte de l'ip source, perte des infos du certificat client (tu peux tout envoyer dans un header HTTP mais ça limite la feature à HTTP)
 
La gestion des certificats et des CRLs peut être un peu complexe dans des environnements importants. La nécessité de passer par des CA externes dans des environnements publics est également une source de coûts.
 
Le fait qu'un certificat soit lié à un nom FQDN (même avec un wildcard pour un domaine et le Subject Alternative Name) impose quelques limitations dont les solutions sont parfois non triviales.
 
Le fait que ce soit crypté pose des problèmes avec les protocoles ouvrant des ports dynamiques (FTP over SSL) car tu ne peux pas lire la signalisation, cela impose des restrictions très fortes en environnement entreprise.
 
SSH v2 est effectivement plus secure que SSL et plus simple

Merci beaucoup pour ces réponses très précieuses.

Je vais pouvoir bien avancer dans mon exposé.

J'ai cependant quelques questions encore à vous poser:

- Quelle est la différence concrètement entre le protocole SSH et le protocole SSL ? Par exemple, sur un site internet, peut-on substituer le protocole SSL par le SSH v2 (qui est plus sécurisé et plus simple à manier selon vos dires)

- Connaissez vous le protocole SET (remplacé depuis 2000 par 3-D Secure) et est-il un concurrent par rapport à SSL ?

Dernière question, peux tu me réexpliquer cette phrase que je n'ai pas très bien compris "Le fait que ce soit crypté pose des problèmes avec les protocoles ouvrant des ports dynamiques (FTP over SSL) car tu ne peux pas lire la signalisation, cela impose des restrictions très fortes en environnement entreprise. "

Merci beaucoup !
A très bientôt

alors d'une je ne connais pas SET
 
Sinon tu ne peux pas remplacer SSL et SSH de manière transparente car ça ne fait pas la même chose.
 
SSH c'est pour Secure Shell, donc de l'accès distant sécurisé en shell. Le "concurrent" via SSL ce serait Telnet over SSL. En plus tu peux faire du transfert de fichier distant via SCP (qui peut être une bonne alternative à FTP over SSL typiquement).
 
Après tu peux utiliser SSH pour faire des tunnels et encapsuler n'importe quoi mais c'est non trivial et "pas fait pour ça".
 
Pour la dernière question, pour tous les protocoles avec de la signalisation out of band (typiquement FTP avec son canal control et son canal data) qui ouvrent des ports dynamiques, ben comme c'est chiffré tu ne peux pas lire les ports négociés donc tu ne peux pas ouvrir les bons flux, donc typiquement le FTP over SSL est en général à proscrire (mais il y a des workaround : https://supportforums.cisco.com/docs/DOC-1647.pdf )

Très bien merci, que signifie "CA externes " ? (cf: "La nécessité de passer par des CA externes dans des environnements publics est également une source de coûts. " )

Que signifie également "'SSL ne scale pas bien quand tu as beaucoup de sessions ". Enfaite c'est le mot scale que je ne comprend pas lol

Après je te laisse tranquille merci.

Quelques oublis en vrac : différences entre SSH et SSL
 
SSH tourne dans la couche 7 du modèle OSI alors que SSL/TLS c'est couche 4 (Transport Layer Security)
 
1 - les CA externes : quand tu parles de certificat (induits avec SSL) le certificat est fourni par une autorité de certification (CA) qui le signe. Pour des certificats publics, les certificats racines de ces CA sont fournis par des autorités "bien connues" dont les certificats racines sont dans tous les browsers web du marché.
 
http://en.wikipedia.org/wiki/Certificate_authority
 
2 - SSL écroule les performances quand tu as beaucoup d'ouvertures de sessions simultanées. En gros 50 sessions SSL/secondes n'importe quel serveur tient la charge. 500 sessions/secondes s'il n'y a pas de carte accélératrice le serveur est mort.

Bonjour à tous,

J'ai présenté mon exposé à l'oral la semaine dernière et je l'ai assez bien réussi puisque j'ai obtenu la note de 15/20.

Je voulais remercier particulièrement dreamer18 pour m'avoir aidé dans ces recherches en m'apportant avec pédagogie et pédagogie les précisions que je recherchais sur le protocole SSL.

Pour ceux qui serait intéréssé, voici le dossier écrit de mon oral:

Intérêts du Protocole SSL

• Authentification du serveur : le protocole permet d’authentifier le serveur internet qui transmet les données. Cela est nécessaire pour assurer que c'est un site, et pas un autre, qui émet le certificat.

• Confidentialité des informations transmises et échangées : le paquet envoyé ne pourra être reçue que par le destinataire final .

• Intégrité des données échangées : le certificat doit être assez « puissant » pour s'assurer qu'aucun paquet n'a subi de modification quelconque (attaque dite active) durant son trajet.

Limites du protocole SSL:

• Ne sécurise pas les systèmes clients ou serveur : Une session SSL/TLS correctement établie va donc protéger les échanges entre les parties, mais ne sera en aucun une garantie de sécurité pour les systèmes client ou serveur. Ainsi, si un pirate installe par exemple un enregistreur de frappe (ou keylogger) sur le poste client, il sera en mesure de récupérer les mots de passe ou toute information confidentielle, même si celle-ci a été émise lors d'une session SSL/TLS. De même, un serveur qui utilise des sessions SSL/TLS pour récupérer des données sensibles peut être compromis et les données recueillies pourront être volées.

• Ne permet pas la non-répudiation: le protocole SSL ne permet pas de vérifier que l’envoyeur d’un paquet est bien celui qui prétend avoir envoyé le message.

• Informations envoyée par l’utilisateur non cryptées : les paquets envoyés par l’émetteur ne sont pas cryptés lors de la réception ce qui signifie que le récepteur du message aura en sa possession les informations « en clair ». Ainsi, un marchand e-commerce disposera des numéros de carte bleue de tous ses clients. Si celui-ci est peu scrupuleux, il pourra s'en servir à son compte.

• Gestion des certificats complexe dans des environnements importants : SSL écroule les performances lorsqu’il a beaucoup d'ouvertures de sessions simultanées. Ainsi, n’importe quel serveur pourra tenir la charge s’il reçoit 50 sessions SSL/secondes. En revanche, dans le cas ou il y aurait 500 sessions/secondes, le serveur aura besoin de carte accélératrice pour pouvoir supporter le débit.

Concurrents au protocole SSL

• Protocole SET : (Secure Electronic Transaction) Considérablement plus complexe, il a été mis au point par les sociétés Visa et Mastercard. Il fait cette fois intervenir aussi les banques du client et du commerçant. Greg envoie cette fois directement son numéro de CB à la banque du commerçant. Celle-ci vérifie les coordonnées bancaires, et confirme au commerçant si elles sont valides ou non. Les deux inconvénients précédemment cités sont éliminés.

• Protocole ITP (Internet Tunneling Protocol) est un protocole permettant le transport de données sécurisées sur un réseau IP. l’ITP permet de chiffrer le contenu de chaque paquet IP pour éviter que quiconque ne le lise, chose que le protocole SSL n’assure pas. A l’instar du SSL, le protocole repose sur un mécanisme de chiffrement asymétrique avec une identification par certificat. Il est en constante évolution car il est soutenu par une grande population technique et scientifique. De ce point de vue, ITP s'annonce comme un concurrent sérieux de SSL.

Bye