déjà, première chose: une bonne partie des sujets ont été traité dans ce poste:
http://www.davidmanise.com/forum/index.php/topic,29394.0.htmlet dans le Guide proposé par Phil67:
[...]
http://guide.boum.org/news/troisieme_edition/
Tome 1 : http://guide.boum.org/tomes/1_hors_connexions/
Tome 2 : http://guide.boum.org/tomes/2_en_ligne/
Le but est ici de faire des didacticiels vraiment basique pour aider à comprendre les principes généraux.
Le but aussi sera d'aller droit à l'information. Inutile d'aller dans le detail.
Je n'ai pas la science infuse et l'information retransmise ne provient la plupart du temps que de l'interpretation
des données que j'en ai fait. En clair, si je dis des c0nner1es ou que c'est incomplet, n'hésitez surtout pas le dire/corriger.
Comme c'est assez long, je le ferais en plusieurs réponses sur ce fil et en cas de besoin, je me reserve le droit (respectueusement),
de corriger tout ce que j'aurais pu dire comme erreur ou completer (il y aura donc un edit pour préciser) et si d'autres veulent en faire aussi... avec joie.
J'aimerais traiter ici des sujets suivants:
* qu'est ce que l'https/comment lire un certificat
* qu'est ce que le phishing (online/offline)
* comment tenter de sauvegarder son identité (je ne m'y connais pas assez, juste les bases)
* adresses IP/cacher son IP etc...
* sécurité des mots de passe (cf les deux liens plus haut
http://guide.boum.org/news/troisieme_edition/ et
http://www.davidmanise.com/forum/index.php/topic,29394.0.html)
* etc...
pour les Admins svp: si trop hors sujet, à supprimer. si moyennement HS, rajouter dans
http://www.davidmanise.com/forum/index.php/topic,29394.0.html . Si ca va pas, pas de doute que vous n'hésiterez pas
Qu'est ce que l'https et le SSL en généralQu'est ce que l'httpLe HTTP est un protocole simple pour faire transiter des données autour de mots clefs simple GET, POST, etc....
La connexion se fait en général sur le port 80.
Un client web se connecte à un serveur, lance une requete du type:
$ telnet www.google.com 80
Trying 173.194.45.52...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0
host: www.google.com
HTTP/1.0 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.fr/?gfe_rd=cr&ei=3kcmVIaQE8nI8ge0qIDwCw
Content-Length: 258
Date: Sat, 27 Sep 2014 05:15:10 GMT
Server: GFE/2.0
Alternate-Protocol: 80:quic,p=0.01
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.fr/?gfe_rd=cr&ei=3kcmVIaQE8nI8ge0qIDwCw">here</A>.
</BODY></HTML>
Connection closed by foreign host.
en gros, le client se connecte à
www.google.com sur le port 80 en telnet, on écrit le texte suivant:
GET / HTTP/1.0
host: www.google.com
<< pas oublier les 2 retour chariot
Le serveur de google répond:
HTTP/1.0 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.fr/?gfe_rd=cr&ei=3kcmVIaQE8nI8ge0qIDwCw
[...]
et google dit gentiment d'aller sur la version google.fr (car mon IP a été vu comme étant en France)
Les choses à retenir:
- c'est très simple comme protocole
* première ligne de contexte ou de requête
* lignes suivantes d'entête
* un retour à la ligne vide
* du contenu si necessaire
- ca passe en clair, n'importe qui qui sniff le réseau peut voir vos requêtes
Qu'est ce que l'httpsLe HTTPS est simplement le protocole HTTP sur une couche de SSL.
En général, la connexion se fait sur le port 443.
Qu'est ce que le SSLC'est un mode de cryptage asymétrique, qui gère principalement 3 aspects:
- l'authentification : savoir que le serveur ou le client est digne de confiance
- le cryptage
- la validité des clefs
L'authentificationL'authentification est assez complexe et l'on va y revenir après.
L'authentification permet :
- que le client dise au serveur qui il est
- que le serveur dise au client qui il est
Tout le monde peut générer un certificat, il existe donc:
- les certificats auto signés (généré par vous, moi...)
- les certificats généré par une autorité de certification (verisign, globalsign) on y reviendra
Pour les certificats auto signés, sachez simplement que :
- OpenSSL est capable d'en générer facilement
- Que des logiciels comme
http://www.ejbca.org/ permettent de monter une autorité de certification privée ou public (sous certaines conditions, très cher)
C'est un peu une usine à gaz, mais ca fonctionne bien.
Cf: plus bas, la description des certificats
Le cryptageavec 2 clefs (1 privée, 1 public) par hôte.
dans certains cas, autre que le HTTP, il peut y avoir plusieurs couches de cryptage qui se superposent.
Imaginons A se connecte à B.
A à 1 clef public [Apu] et une clef privé [Apr]
B à 1 clef public [Bpu] et une clef privé [Bpr]
A initie la connexion.
B répond
A envoi à B sa clef public [Apu] avec l'authentification dans le certificat client
B envoi à A sa clef public [Ppu] avec l'authentification dans le certificat serveur
=> des données cryptées peuvent commencer s'échanger.
A crypte les données pour B en utilisant [Apr] + [Bpu] que B va décrypter en utilisant [Apu] + [Bpr]
B crypte les données pour A en utilisant [Bpr] + [Apu] que A va décrypter en utilisant [Bpu] + [Apr]
La taille des clefs, exprimée en bits (512/1024/2048 bits) déterminé la complexité du cryptage et
aussi la charge pour les deux parties d'encrypter et de décrypter les données
QQQ Question, je ne trouve pas la réponse QQQ
je ne connais pas le process de génération des clefs coté navigateur.
Théoriquement, chaque navigateur de chaque poste à du générer à un moment ses clefs ou sont elle générée à chaque connexion?
j'ai bien trouvé ca :
https://www.ssllabs.com/ssltest/viewMyClient.html
https://www.evsslcertificate.com/ssl/description-ssl.html
mais pas réellement sur le process de génération des clefs privée/public client.
QQQ FIN Question QQQLa validitéChaque certificat est soumis à une date heure de début et une date heure de fin de validité.
En dehors de cette periode, le certificat n'est plus accepté comme sécurisant (mais peut être validé par manipulation manuelle)
Il y a quelque temps, une banque n'avait pas mis à jour ses certificats en temps et en heure. ca affichait des messages d'erreur
que l'on devait ignorer pour aller plus loin, d'où l'utilité de comprendre la lecture du certificat.
Qu'est ce que le STARTTLSC'est très simple, c'est au début d'une requete sur un protocole non crypté qu'en général on utilise le mot clef STARTTLS et cela initialise une couche SSL, le reste des données étant alors crypté.
Ca existe pour le POP/IMAP/FTPS et plein d'autres, mais pas le HTTP!!
pourtant:
http://www.faqs.org/rfcs/rfc2817.htmlmais visiblement, pas généralisé à minima. (mais ct simple d'en parler ici)
Comment lire un certificat en HTTPSCes captures sont faites sous firefox, mais tous les navigateurs ont a peu près les mêmes options
Comment visualiser simplement un certificat
Une description sommaire
Une description complete
On y voit les 4 niveaux de certificat:
Builtin Object Token : Equifax Secure CA
-> GeoTrust Global CA
-> Google Internet Authority G2
-> *.google.com
Plus il y a de niveau, est moins la sécurité est importante, car il suffit qu'un élément soit corrompu pour poser problème aux fils.
3 - 4 niveaux, ca reste normal pour le domaine public (5 max à mon sens). Moins, sauf si c'est un gros, genre GeoTrust ou Verisign, sinon, ce n'est pas normal.
Builtin Object Token certifie l'authenticité de GeoTrust Global CA
GeoTrust Global CA certifie l'authenticité de Google Internet Authority G2
Google Internet Authority G2 certifie l'authenticité de *.google.com
Les 3 premiers sont donc des autorités de certifications pour le dernier.
le premier est une autorité de certification
les 2 suivants des certificats intermédiaires
le dernier, le certificat du serveur qui nous concerne.
le *.google.com veut dire que c'est un certificat Wildcard, en gros, ca certifie
www.google.com comme mail.google.com.
Ces niveaux de certificat sont la première chose que je regarde, voir si c'est cohérent, s'ils sont bien public, si la plus haute autorité semble cohérente aussi.
Les dates de validité:
la clef public du serveur :
Un autre exemple sur yahoo.com cette fois, l'autorité est verisign.
Un certificat simplement auto signé, aura cette tête là:
Les types de certificatsIl existe différent type de certificat; les principaux sont les suivants:
- certificat pour un ensemble domaine et un sous domaine, par exemple
www.google.com (google.com est le domaine), on peut souvent y ajouter des SAN, c'est à dire des autres ensembles domaines + sous domaines
- certificat pour une IP données
- certificat wildcard *.google.com : tous les sous domaines pour un domaine sont autorisé (cf certificat google.com plus haut)
Ce type de certificat est moins sécurisant, par le fait qu'on installe le même certificat pour l'ensemble des serveurs, mais tellement plus simple à gérer.
Il faut savoir qu'un certificat peut être révoqué par l'autorité de certification qui l'a émis. En gros, il est publié alors sur une liste qui mentionne les certificats révoqués.
(option à valider dans le navigateur)
Qui certifie la première autorité de certification ?Bêtement ? NOUS !
En fait, pas tout a fait. Les navigateurs incluent dans leur système des ensemble de certificats d'autorités de certifications.
AMHA (mais pas certain du tout, quelqu'un peu confirmer peut être), une autorité comme verisign paie très cher firefox pour figurer parmis la liste de ceux qu'ils sont naturellement considérés comme des autorités.
Les systèmes d'exploitation comme OSX en ont aussi.
Un certificat d'autorité de certification peut être installé sur le navigateur.
Par exemple, un certificat créé par un projet comme ejbca peut être inclus dans le navigateur et tous les certificats qui en découleront seront automatiquement considéré comme secure.
Ca n'a d'intérêt que si l'on a beaucoup de système et pas envie de s'embêter avec les acceptation de certificats auto-signés
Sujet: Didacticiels sécurité informatique (Lu 1658 fois)
