ssl

1. Application
SSL/TLS
MINI-PROJET
Année Universitaire:
2020/2021
Elaboré Par :
Loussaief Sabrine
et Louati Omaima

2. Plan 2
1
2
3
4
Introduction General
SSL/TLS Protocol
Problematique
Solution propose
5
Les Attaques MITM Dans SSL
/ TLS
Conclusion
6

3. Introduction
General
3

4. 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.
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
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 si la communication
se faisait en http?
4

5. SSL/TLS
Protocol
5

6. Secure Socket Layer / Transport Layer Security (SSL / TLS) est
généralement intégré à l'application pour protéger les données
envoyées via HTTP entre les clients et les serveurs,
également appelé HTTP sur TLS
(HTTPS).
01
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.
02
Aujourd'hui c'était qui est utilisé ssl étant obsolète mais on parle
encore parfois de SSL/TLS pour parler juste de TLS le chiffrement
consiste a transformer vos données afin de les rendre illisibles
grâce a un algorithme de chiffrement et de clé
la clé de chiffrement est utilisé par l'algorithme pour chiffré et
déchiffré des données.
03
6
Il offre un certain nombre de services de sécurité
tels que la confidentialité des données transmise
ou l'authentification des interlocuteurs a l'aide de
certificats électronique.
04

7. 6
01
02
03
04
05
06
le serveur répond au client avec un
"message terminé qui est crypté avec
la clé secrète indiquant que la partie
serveur de la négociation est terminée
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
échange de clé client, le client
envoie une clé secrète partagée à
utiliser dans la conversation
suivante la clé secrète est chiffrée
avec la clé publique du serveur
le client envoie un message
« clienthello » qui contaient des
informations telles que la version
SSL / TLS les algorithmes
cryptographiques etc.
le serveur répond par un message
"serverhello » qui contient les
algorithmes cryptographiques et
son certificat numérique et sa clé
publique
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
Handshake
Protocol

8. Pour pouvoir lire les données entre le client et le serveur
il est nécessaire de connaitre l'algorithme et la clé de chiffrement
pour les déchiffrer que se soit cryptographie symétrique
ou cryptographie asymétrique
chiffrement symétrique quand il utilise la même clé pour chiffrer et déchiffrer.
chiffrement asymétrique quand il utilise des clés différentes :
une paire composée d'une clé publique, servant au chiffrement,
et d'une clé privée, servant à déchiffrer.
01
02
03
8

9. Problematique
9

10. En particulier lorsque des
utilisateurs naïfs souhaitent
se connecter à un serveur
Web compatible SSL / TLS.
Donc c'est quoi l'attaque
« l'homme au milieu » dans
SSL/TLS?
Ces derniers temps, une menace
potentielle, connue sous le nom
de main-in-the-middle (MITM)
A été exploitée par des
attaquants d'applications Web
compatibles SSL / TLS,
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
Le problème va venir de la
transmission de la clé publique
dans la cryptographie
asymétrique
10

11. Les Attaques
MITM Dans
SSL / TLS
11

12. Ensuite pour pallier l'il va chiffrer le message
avec la clé publique de serveur et envoyer le
message comme ça le serveur peut déchiffrer
avec sa clé prive pour lire les messages
MITM est donc capable de lire les conversations
entre les deux et de récupérer information
importante.
Main in the middle va donc intercepter et
modifier les échanges de clés entre le client
et le serveur du coup lorsque le client envoie
un message à serveur Il va l'envoyer en
chiffrent avec la clé publique supposée
appartenir au serveur en fait MITM va
intercepter le message il va le déchiffrer
avec sa clé privée et lire le message.
Basé sur les services et l'activité prévues
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.
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ée dans la
communication client et serveur.
L’homme au milieu 11

13. Solution
proposé
13

14. 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.
Nous présentons ensuite une
solution efficace utilisant
l'authentification cliente basée
sur un jeton logiciel qui peut
résister à SSL / Application
compatible TLS contre les
attaques MITM.
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 discutons des solutions
existant pour contrer les
attaques MITM sur SSL / TLS.
Comme la plupart des solutions
considèrent l'authentification
client comme facteur important
12

15. 13
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.
Il est un forme ou une séquence d'éléments de matrice A (i, j)
(Kumar et Raghavan, 2008).
01
02
03
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
04

16. Fonctionnement
 La figure suivante montre que 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 la 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) 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.

17. Fonctionnement
 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.
 S’il 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
Figure suivante.
 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.

18. Conclusion Nous avons discuté de la menace MITM pour les
applications Web compatibles SSL / TLS.
Nous avons examiné les approches existant pour
l'authentification des utilisateurs et proposé une
authentification utilisatrice basée sur un jeton
logiciel.
13
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
matière de calcul et fournit des sécurités
en plus de la force de sécurité du
protocole SSL / TLS.

19. Merci Pour Votre Attentions