ssl

17. Introduction generale
SSL/TLS Protocole
Problematique
Les Attaques MITM Dans SSL / TLS
Solution propose
Conclusion

18. Il existe des situations où il existe une exigence de sécurité pour assurer la confidentialité ou
l'intégrité du trafic réseau, ce qui est généralement réalisé à l'aide de mesures cryptographiques,
Donc lorsque vous vous connectez sur un serveur la connexion se fait toujours en HTTPS pour
des raisons de sécurité que se passerait il si la communication se faisait en http?
c'est simple toutes les informations échangées transiteraient en clair ce qui veut dire qu'une
personne malveillante peut intercepter les échange entre vous et votre serveur
En fait le https c'est une connexion http dans un tunnel chiffré ssl/tls ce tunnel va sécuriser vos
échange car même si une personne malveillante intercepte vos échange les informations sont
chiffrées.

19. Secure Socket Layer / Transport Layer Security (SSL / TLS) est généralement intégré à l'application pour protéger les données envoy
via HTTP entre les clients et les serveurs, également appelé HTTP sur TLS
(HTTPS).
Le protocole SSL / TLS est composé par sous-protocole Handshake permet au client d'authentifier le serveur communicant
en utilisant le certificat de clé publique du serveur
voici le processus comment un client et un serveur utilise le protocole de prise de contact pour négocier comment échanger des
données en toute sécurité
étape 1: le client envoie un message "clienthello« qui répertorient des informations telles que la version SSL / TLS les algorithmes
cryptographiques méthodes de compression de données prises en charge par le client
étape 2: le serveur répond par un message "serverhello » qui contient les algorithmes cryptographiques choisis par le serveur à pa
de la liste fournie par le client l'ID de session le serveur envoie également son certificat numérique et sa clé publique
étape 3: le client contactera l'autorité de certification du serveur et vérifie le certificat numérique du serveur confirmant ainsi
l'authenticité du serveur Web
Certifica et signature
étape 3: établit essentiellement la confiance sur le serveur Web une fois que le client fait confiance au serveur Web il faudra
l'étape 4: échange de clé client avec cette étape, le client envoie une clé secrète partagée à utiliser dans la conversation suivante la
secrète est chiffrée avec la clé publique du serveur
étape 5: le client envoie un message terminé qui est chiffré avec la clé secrète indiquant que la partie client de la négociation est
terminée

20. le problème va venir de la transmission de la clé publique dans la cryptographie asymétrique
notamment si personne
malveillantes se positionne entre le client et le serveur
se fait passer pour l'un d'eux et donne a clé publique a la place
Ces derniers temps, une menace potentielle, connue sous le nom de main-in-the-middle
(MITM)
attaque, a été exploitée par des attaquants d'applications Web compatibles SSL / TLS,
en particulier lorsque des utilisateurs naïfs souhaitent se connecter à un serveur Web
compatible SSL / TLS.

21. Une attaque MITM est une forme d'attaque active dans laquelle l'attaquant intercepte et
modifie de manière sélective les données interceptées afin de se faire passer pour une partie légitime
impliqué dans la communication client et serveur.
Basé sur les services et l'activité prévus perspectives, plusieurs applications Web compatibles SSL / TLS
n'emploient pas de client authentification comme une exigence, à la place les applications Web
activent SSL / TLS dans mode d'authentification du serveur
Main in the middle va donc intercepté et modifié les échanges de clé entre le client et le serveur du
coup lorsque le client envoie un message a serveur Il va l'envoyer en chiffrent avec la clé publique
supposée appartenir a le serveur en fait MITM va intercepter le message il va le déchiffrer avec sa clé
privé et lire le message
ensuite pour pallier le il va chiffré le message avec la clé publique de serveur et envoyer le message
comme ca le serveur peut déchiffré avec sa clé prive pour lire les message
MITM est donc capable de lire les conversation entre les 2 et de récupéré information importante

22. Nous discutons des solutions existantes pour contrer les attaques MITM sur SSL / TLS enabled
applications. Comme la plupart des solutions considèrent l'authentification client comme
facteur important,
nous discutons de l'espace de solution pour le mot de passe, l'utilisateur graphique interface et
des approches basées sur des jetons pour l'authentification des utilisateurs.
Nous présentons ensuite un solution efficace utilisant l'authentification client basée sur un jeton
logiciel qui peut résister à SSL / Application compatible TLS contre les attaques MITM.
Nous analysons la solution proposée pour sa fonction de sécurité en plus de la sécurité du
protocole SSL / TLS, et fournir son efficacité par rapport à d’autres approches.

23. Les entités participantes de notre protocole sont les suivantes:
- Utilisateur / client, qui souhaite accéder aux applications compatibles SSL / TLS.
- Serveur qui héberge l'application compatible SSL / TLS.
Avant d'accéder à l'application, l'utilisateur / client doit s'inscrire auprès du serveur
en toute sécurité. Une fois l'inscription réussie, l'utilisateur partage son identité (UID), son mot de passe
(PWD) et un code de motif (PC) avec le serveur. Le code du modèle est un
mesure de sécurité qui s'ajoute à notre solution proposée. Le code de modèle est un
forme ou une séquence d'éléments de matrice A (i, j) d'une matrice de motifs (Kumar et
Raghavan, 2008). Chaque cellule de la matrice de motifs est une image qui représente un
personnage. Pendant le processus d'inscription, l'utilisateur reçoit un message généré de manière aléatoire
matrice de motifs et invité à choisir une séquence de positions en tapant
les caractères présents dans la matrice de motif, qui devient alors le motif de l’utilisateur
code, PC

24. La figure suivant montre le PC de l'utilisateur, qui est capturé dans la région ombrée (nous
notons que la séquence du PC de l'utilisateur est remplacée par les numéros 1 à 7 dans le
région ombrée), c'est-à-dire que PC sur la figure B {# (S7 &. Le protocole fonctionne comme
suit. Lorsque l'utilisateur / client souhaite accéder au serveur, le client et le serveur établissent
une clé de session SSL / TLS K utilisant le protocole de prise de contact SSL / TLS. Après cela,
le serveur génère un soft-token contenant le PC, l'UID et un code d'authentification, AC, où AC
= MAC (PC; h (tous les messages SSL / TLS précédents)) et MAC (.) Est un code
d'authentification de message. Le jeton logiciel fournit à l'utilisateur le caractère visuel retour par
caractère du PC une fois que l'utilisateur entre en courant alternatif. Le navigateur va également
avoir un petit écran où la valeur de hachage compressée de tous les SSL / TLS précédents les
messages seront affichés. Cette zone peut être personnalisée par l'utilisateur, ainsi éviter toute
attaque par usurpation visuelle. L'utilisateur génère AC en utilisant la valeur de hachage affiché
sur le navigateur et son code de motif PC. Ensuite, l'utilisateur soumet l'UID et AC au serveur.
Après avoir reçu le courant alternatif, le serveur calcule également le courant alternatif à l'aide
du valeur de hachage et PC correspondant à l'UID. Si le CA calculé est le même que le reçu AC
puis le client est authentifié par le serveur. L'utilisateur peut arrêter la saisie à AC si il / elle ne
voit pas le code de motif correspondant au motif choisi au moment de l'inscription. Le processus
d'entrée sur AC et d'affichage du PC est montré sur la Fig. 3. Chaque caractère d'AC est couplé
à la session SSL / TLS afin que l'adversaire ne peut pas utiliser le même message dans un
autre SSL / TLS session. Le protocole est donné ci-dessous: Figure.

25. Nous avons discuté de la menace MITM pour les applications Web compatibles SSL /
TLS.
Nous avons examiné les approches existantes pour l'authentification des utilisateurs et
proposé un authentification utilisateur basée sur un jeton logiciel.
En activant la solution proposée en SSL / Application Web compatible TLS, les attaques
MITM peuvent être évitées.
La proposition la solution nécessite un affichage de confiance (contrôlé par le serveur
légitime) sur le navigateur pour rendre la valeur compressée du hachage des messages
de négociation SSL / TLS.
La solution proposée est efficace en termes de calcul et fournit des sécurité en plus de
la force de sécurité du protocole SSL / TLS.