---
# System prepended metadata

title: '[TC2] TD4 - CSC'
tags: [TC2, S2, CSC]

---

# [TC2] TD4 - CSC
###### tags: `CSC`, `S2`, `TC2`
---
_Avec Nicolas_
[Le sujet](https://flesueur.github.io/csc/td4-ca.html)
##

## Echange direct

1. *Sans prendre en compte la sécurité, est-ce que cela peut fonctionner ?*

OUI, ça fonctionne


2. *Si cela fonctionne, quel peut être le risque (en prenant maintenant en compte la sécurité) ? A-t-on gagné quelque chose par rapport à une communication en clair ?*

Il y a des risques :  
- Usurpation d'identité (aucun moyen de check l'identite au premier echange)
- Interception de la communication (Man on the middle)

TOFU : trust on first use. Echange de clefs dans endroit sécurisé dans un endroit fiable. 

3. *Décrivez une attaque possible par man-in-the-middle.*

On prend le flux d'un côté et on le redistribue de l'autre côté

## Ajout d’un nouvel acteur : la CA

1. *À partir du cours, refaites la cinématique de CA/HTTPS dans ce modèle : les échanges entre B et C, puis entre B et A (A et C ne communiquent jamais directement !). Quel élément est le certificat ? Vous utiliserez les notations présentées en début de sujet.*

B demande son propre certificat à C. Il peut ensuite envoyer son certificat à A. A envoie son certificat à B et ils peuvent commencer à communiquer.

Certificat de B : (B, Pub~b~),{h((B,Pub~b~)}~PrivC~

2. *Comment C vérifie-t-elle l'association déclarée (B, PubB) ?*

Challenge?

[Challenge chez let's encrypt](https://letsencrypt.org/fr/docs/challenge-types/)

3. *Comment A vérifie-t-elle l'association obtenue (B, PubB) ? Quelle est la chaîne de confiance ?*

En vérifiant la signature grâce à Pub~C~. A fait confiance à C, qui a confiance en l'identité de B.

4. *Que déduire si le certificat reçu par A est bien signé mais pour une identité différente de B ? (en HTTPS, l'identité attendue, B par exemple, correspond au nom d'hôte de la requête, par exemple `www.insa-lyon.fr` pour une requête à `https://www.insa-lyon.fr/index.html`)*

Usurpation


## L’écosystème HTTPS


Grace au mecanisme expliqué ci-dessus, B ne demande jamais a C le certificat de A. De ce fait, si C est compromise, A ne l'est pas


## Révocation

### CRL

Les utilisateurs autres que les serveurs vont avoir besoin de récupérer cette liste de certificats révoqués et cela risque de surcharger les CA.

Si pas de CRL, on n'y va pas. Mais certains navigateur ne l'ont pas implémenté

Probleme de CRL, on peut apprendre des choses sur les services (mauvais payeurs, mauvaises gestion de sécu...)


### OCSP
1. Non ça résoud r
2. L'agrafage OCSP, c'est cool ça résoud le problème
3. Il faut refuser

Le probleme de l'agrafage, le CA sait quel site l'user visite


## Organisation d’une CA à étages











