On va étudier le (long) voyage d’un petit paquet IP
sur le grand réseau Internet
Et regarder comment sécuriser chacune des étapes !

• Sécurité physique / locale
• Sécurité des communications
• Sécurité des services / hébergements
• le bordel problème du web

Internet, ce n’est malheureusement pas ça…

Internet, c’est ça…

• Utiliser du logiciel libre ⇒ GNU/Linux
• Mettre à jour régulièrement son système
  ⇒ Au moins 1× par semaine ⇒ Au mieux 1× par jour !
• Gérer correctement ses mots de passe
  ⇒ Pas le même partout ! ⇒ KeepassX
• Chiffrer ses données
  ⇒ TrueCrypt, , LUKS pour les disques durs
  ⇒ SMSSecure , pour les SMS

• Pare-feu efficace
  ⇒ Tout ce qui n’est pas autorisé est interdit
• Ne pas laisser traîner son ordinateur tout seul
  ⇒ Verrouiller sa session
  ⇒ Machine en veille/hibernation
  ⇒ Éteindre complètement la machine
• Ne pas brancher un périphérique USB inconnu
  ⇒ Même pour charger un téléphone
  ⇒ Salons, conférences, séminaires
  ⇒ Transports
  ⇒ Supports publicitaires
• Si vraiment machine tierce / environnement critique
  ⇒ Tails

« imirhil.fr » est inconnu d’un point de vue réseau
Besoin de l’adresse IP (5.135.187.37 ou 2001:41d0:8:c425::1) ⇒ DNS Généralement, on utilise le résolveur DNS de son FAI

• but commercial : pub, trafic…
• but « technique » : mise-en-cache, optimisation… (généralement sur mobile)
• sur demande judiciaire : loi terrorisme
• dictature : censure

ARP spoofing, injection de paquet, IP spoofing

Installer son propre résolveur local
Interroge directement les serveurs DNS racine d’Internet
(Ce qui n’est pas très cool pour les chatons 😿)

Vraiment en situation d’urgence : (Merci Google…)

Vraiment en situation d’urgence : (Merci Google…)

Les communications circulent de routeurs en routeurs,

2 modes de protection

• Point-à-point (TLS…)
  
• End-to-End (GPG, OTR…)
  

• 1994 :  SSL v1.0 (théorie, jamais mise en œuvre)
• 1995 : SSL v2.0 (trop moisi, SSL v3.0 lancé dans la foulée)
• 1996 : RFC 6101, SSL v3.0 (tout moisi aussi, + 2014 : Poodle)
•  
• 1999 : RFC 2246, TLS v1.0
• 2006 : RFC 4346, TLS v1.1
• 2008 : RFC 5246, TLS v1.2

Les chiffrements symétriques (AES, RC4, DES) sont

Les chiffrements asymétriques (RSA, DSS, ECDSA) sont

SSL/TLS est un protocole couplant

• un échange de secret par chiffrement asymétrique
• un chiffrement symétrique avec ce secret

SSL/TLS doit assurer 3 fonctions :

• l’authentification
• le chiffrement
• l’intégrité

• un attaquant peut enregistrer l’intégralité du flux chiffré
• il peut mettre la main sur la clef privée par la suite
• il peut alors déchiffrer l’intégralité des communications enregistrées !

• Un site peut commencer en clair et décider ensuite de faire du HTTPS
• Tout le monde peut faire des liens vers n’importe qui et n’importe comment
• Il y a des gros michants qui s’amusent avec le réseau (SSLStrip)

On a quand même envie de protéger nos utilisateurs et de les obliger à passer en HTTPS

• S’il clique sur un (vieux) lien HTTP
• S’il clique sur un lien qu’on ne maîtrise pas
• S’il y a un gros michant sur sa ligne

⇒ En-tête HSTS

Une fois le site consulté une 1ère fois, il mémorise qu’il doit obligatoirement revenir dessus en HTTPS

S’il voit du HTTP, il redirige automatiquement et sans aucune requête en clair vers la version HTTPS

Très dépendant de la compétence des administrateurs https://imirhil.fr/tls/index.html

Très dépendant de la compétence des administrateurs https://www.ssllabs.com/ssltest/

4 lignes pour se mettre à l’abri

SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES;+HIGH:+MEDIUM
#SSLCipherSuite AES256+EECDH:AES256+EDH:AES128+EECDH:AES128+EDH:+SHA
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
SSLCompression off

TLS est basé sur une chaîne de confiance :
Les amis de mes amis sont mes amis.

CACert, autorité de certification communautaire

• Considération purement technique/physique
  
  • Résister à 1600° pendant 2h
  • Résister au crash d’un Boeing à pleine vitesse
• Mais qu’une didactature ou une entité commerciale/gouvernementale ait accès à la clef privée n’est pas génant

P₂P repose uniquement sur la bonne coopération des différents acteurs techniques.

E₂E reprend les mêmes techniques que P₂P

Cryptographie à clef publique :

• On signe avec notre clef privée , notre destinataire nous authentifie avec notre clef publique
• On chiffre avec la clef publique de notre destinataire, qui déchiffrera avec sa clef privée

La chaîne de confiance devient :

Mes amis sont mes amis
Point.

Les 2 systèmes E₂E les plus utilisés sont GPG (mail) et OTR (IM)

Supportés nativement (KMail, Clawsmail) ou via extensions (Enigmail, Pidgin)

Les principaux obstacles à un usage plus massif sont :

• l’usage peu massif (œuf, poule, tout ça tout ça…)
• la distribution des clefs

pub   4096R/0xEFB74277ECE4E222 2013-12-23 [expire : 2015-12-31]
	Empreinte de la clef = 6A68 B761 2629 7666 ECF4  8F03 EFB7 4277 ECE4 E222
uid                [  ultime ] Aeris <aeris@imirhil.fr>
uid                [  ultime ] Nicolas Vinot <nvinot@april.org>
uid                [  ultime ] Aeris <aeris@terrorist.es>

Le prochain qui me dit qu’on
est associal, je le mord

Le serveur connaît l’adresse IP du client (lanceur d’alerte, journaliste, personne battue…)

Problème du « cloud »

• Où sont stockées mes données ?
• Qui y a accès ?
• Quel niveau de sécurité ?

On peut parfaitement s’auto-héberger

• Ça ne coûte pas cher
  • Raspberry Pi : 50€, 5W
  • Shuttle XS35v2 : 150€, 40W
  • Dédié Online : 7€/mois
• Ça ne demande pas forcément beaucoup de temps / compétences
  (Mais un peu quand même)
• C’est très formateur / intéressant
  Et ça ça n’a pas de prix

On peut s’adresser à des association
http://degooglisons-internet.org/

On peut auto-héberger plein de choses

• Jabber (Prosody), GNU/Social, Diaspora*
• Site perso , blog
• partage de documents (Owncloud)
• « Pad », pastebin (ZeroBin)
• Mail (Posfix/Dovecot/Roundcube)
• …

• HTTPS
• Tracking utilisateur (pub)
• « Cloud », appels externes
• Incompétences techniques
• Préoccupation purement commerciales
• « N00b » compliance