<center>

# Cryptographie - Travaux pratiques SSL/TLS
</center>

## 1. Introduction
## 2. Mise en place du service de vidéo-surveillance



Toutes les machines sont joinables entre elles.

Après l'éxecution de `iptables`, la video est affichée comme précedemment:


### Manoeuvre du hacker


Après l'attaque sur `iptables`, la vidéo est differentes: Cette fois l'homme suspicieux disparaît:


## 3. Mise en place de l’infrastructure à clé publique

#### Que pensez-vous de l’option `-nodes` ?

L'option `-nodes` veut dire `NO DES`. Cette on n'utilise pas cette option, `openssl` demandera un mot de passe pour encrypter la sortie l'agorithme `3DES`.

Ajouter un mot de passe n'est jamais mal si possible. Je ne suis pas sûr pourquoi on n'utilisera pas cette option en production mais dans notre cas c'est peut-être pour simplifier le TP ?

#### Qu’en concluez-vous concernant les droits d’accès devant être définis sur le fichier `private/cakey.pem` ?

Seulement `root` aura accès à ce fichier.

Les utilisateurs peuvent utiliser un `sudo` ou `setuid` pour les commandes reliés à cette clé.

Au pire cas où la machine est compromise le hackeur peut simplement créer sa nouvelle clé donc une protection de plus ne sert pas.

Pour voir le contenu du certificat `cacert.pem`, on peut utiliser la commande `openssl x509 -in cacert.pem -text` comme ci-dessous:


Pour voir le contenu de la clé privée, on peut utiliser la commande `openssl rsa -in private/cakey.perm -text`:


## 4. Génération du certificat du serveur


#### En particulier, quelle différence voyez-vous entre un certificat et une demande de certification ?

On voit que certains champs on changés. Un qui saute immédiatement aux yeux est le champs `Validity - Not After`.

En ligne j'ai trouvé qu'un CSR est auto-signé (bonne pratique pour la consistence, etc?), bien qu'un certificat est signé par la CA.

Après la concatenation des paramètres de Diffie-Hellman, les lignes suivantes sont ajoutées au certificat:

## 5. Mise en place d’un tunnel SSL entre Visu et Camera

Succès:

Grâce à wireshark, on voit que les machines `Visu` et `Camera` échanges des packets utilisant le protocole `TLS`:

`ssldump` réussit à identifier du traffic SSL:


Après qu'on a lancé le script `attack_iptables.sh`, la vidéo est coupée avec l'erreur suivante:


Ceci peut-être du au fait que `stunnel` attend un certificat mais ne le reçois pas.

#### Forgerie de certificat

Sur la machine de l'attaquant, on copie le fichier le configuration de `openssl`.

On génère un certificat auto-signé.
Une crée une demande puis un certificet pour l'attaquant: `attackcert.pem`.
On ajoute le paramètre de Diffie-Hellman.

Il faut tricher pour installer `stunnel4` (ajouter une interface réseau NAT sur la machine `Attaquant`).

Et finalement on lance le service avec `sudo stunnel4 ./stunnel.conf`.

On obtient de nouveau la video où l'homme suspicieux a disparu.

Ceci se produit parce que pour l'instant, rien ne garentit l'identité du caméra. Il faut authentifier le certificat SSL délivré par le serveur.

#### Solution

On copie de certificat d'authorité de la machine `camera` dans la machine `visu` et on demande à `stunnel4` à vérifier les certificat.

- On copie ce certificat dans `/usr/lib/ssl/certs` et on execute `c_rehash`
- On ajoute une ligne `verify = 3` ou `verifyChain = yes` dans `stunnel.conf`. on re-execute avec `stunnel4 ./stunnel.conf` (décommenter quelques lignes)

Le certificat envoyé par le serveur sera ainsi authentifié.

## 6. Attaque de la librairie OpenSSL