Add section numbers
This commit is contained in:
parent
486a82ca03
commit
7a256cd825
2 changed files with 28 additions and 28 deletions
|
|
@ -63,9 +63,9 @@ Pour le lecteur intéressé, la sécurité de Telegram a fait l’objet de discu
|
|||
d’Apple iMessage [^IMSG]. WeChat ou encore Slack sont hors sujet, puisqu’ils ne
|
||||
proposent pas de chiffrement de bout en bout.
|
||||
|
||||
# Les protocoles inadéquats pour la messagerie quasi instantanée
|
||||
# 1. Les protocoles inadéquats pour la messagerie quasi instantanée
|
||||
|
||||
## OpenPGP
|
||||
## 1.1. OpenPGP
|
||||
|
||||
OpenPGP est un format de stockage de messages et de clés cryptographiques,
|
||||
spécifié dans sa version la plus récente en 2007 [^OPGP]. Il est notamment
|
||||
|
|
@ -95,7 +95,7 @@ est sujette à des attaques par dégradation du niveau de sécurité (*downgrade
|
|||
attack*) [^FORA] et l’autre use de signatures cryptographiques non répudiables,
|
||||
ce qui n’est pas toujours souhaitable.
|
||||
|
||||
## Off-the-Record
|
||||
## 1.2. Off-the-Record
|
||||
|
||||
Le protocole *Off-the-Record* a été spécifié, pour la première fois, en 2004 ;
|
||||
sa version la plus récente date de 2012. Ce mécanisme permet l’échange de clés
|
||||
|
|
@ -145,7 +145,7 @@ entiers de 1536 bits avec un groupe fixé par la spécification. L’usage de ce
|
|||
cryptographie datée est contraire aux bonnes pratiques actuellement reconnues.
|
||||
|
||||
|
||||
# X3DH+Double Ratchet
|
||||
# 2. X3DH+Double Ratchet
|
||||
|
||||
Les protocoles X3DH et Double Ratchet ont été inventés par Trevor Perrin et
|
||||
Moxie Marlinspike. En 2013, il s’agissait, en fait, d’un seul et même protocole
|
||||
|
|
@ -170,7 +170,7 @@ Pour effectuer ces opérations sur les clés, les deux protocoles emploient de l
|
|||
cryptographie moderne : XEdDSA, une extension à EdDSA, sur les courbes
|
||||
elliptiques curve25519 ou curve448 [^XDSA], SHA2 et HKDF [^HKDF].
|
||||
|
||||
## X3DH
|
||||
## 2.1. X3DH
|
||||
|
||||
Chaque utilisateur du protocole X3DH doit générer et publier un ensemble de
|
||||
biclés cryptographiques. Ces clés doivent être compatibles avec les fonctions
|
||||
|
|
@ -241,7 +241,7 @@ elle est non répudiable, ne prévient pas cette propriété puisqu’elle est
|
|||
totalement décorrélée de l’échange de clés et n’intervient que pour « certifier
|
||||
» la clé à moyen terme.
|
||||
|
||||
## Double Ratchet
|
||||
## 2.2. Double Ratchet
|
||||
|
||||
Double Ratchet repose sur deux mécanismes de rafraîchissement des clés. Ces deux
|
||||
mécanismes confèrent son nom à cet algorithme, puisqu’ils utilisent tous deux, à
|
||||
|
|
@ -296,7 +296,7 @@ noter que conserver ainsi les clés, au lieu de les supprimer dès que possible,
|
|||
peut mettre en péril la confidentialité persistante, en cas de compromission
|
||||
d’un équipement.
|
||||
|
||||
## Intégration de X3DH+Double Ratchet dans OMEMO
|
||||
## 2.3. Intégration de X3DH+Double Ratchet dans OMEMO
|
||||
|
||||
La première version d’OMEMO a été spécifiée par Andreas Straub en 2015, avec
|
||||
l’aide de Daniel Gultsch, développeur principal du client XMPP Conversations. En
|
||||
|
|
@ -352,7 +352,7 @@ confidentialité persistante. Il lui suffit d’envoyer un message « de service
|
|||
dont le seul objet est de rafraîchir le secret racine. Cette situation semble,
|
||||
dans tous les cas, préférable à l’absence totale du quatrième échange DH.
|
||||
|
||||
# Des divergences entre Signal et le protocole OMEMO
|
||||
# 3. Des divergences entre Signal et le protocole OMEMO
|
||||
|
||||
Signal et le protocole OMEMO sont par certains aspects très similaires.
|
||||
Certaines implémentations d’OMEMO utilisent, en effet, la bibliothèque
|
||||
|
|
@ -364,7 +364,7 @@ les identifiants et l’architecture réseau, l’infrastructure de gestions de
|
|||
l’usage qui est fait de ces clés, l’existence de documentation de qualité et la
|
||||
capacité à auditer le protocole.
|
||||
|
||||
## Les identifiants et l’infrastructure réseau
|
||||
## 3.1. Les identifiants et l’infrastructure réseau
|
||||
|
||||
Alors qu'OMEMO utilise une infrastructure répartie, où chaque utilisateur
|
||||
choisit son fournisseur de services, grâce au réseau fédéré XMPP, Signal préfère
|
||||
|
|
@ -423,7 +423,7 @@ exclusivement ou sur un mélange des deux. Finalement, pour la géolocalisation
|
|||
des serveurs, l’infrastructure répartie de XMPP permet de jongler à volonté avec
|
||||
la localisation administrative et juridique des serveurs.
|
||||
|
||||
## L’infrastructure de gestion de clés
|
||||
## 3.2. L’infrastructure de gestion de clés
|
||||
|
||||
Les serveurs gérés par Open Whisper Systems sont responsables du stockage des
|
||||
clés publiques de tous les utilisateurs, et de distribuer ces clés aux nouveaux
|
||||
|
|
@ -485,7 +485,7 @@ cryptographique de 256 bits. Il existe un risque d’utiliser plusieurs fois une
|
|||
clé à usage unique, mais le protocole prévoit une contre-mesure pour raccourcir
|
||||
la durée de l’incident.
|
||||
|
||||
## Usage des clés symétriques
|
||||
## 3.3. Usage des clés symétriques
|
||||
|
||||
Signal chiffre les messages à l’aide d’AES256 en mode CBC et ses motifs
|
||||
d’intégrité sont calculés avec HMAC-SHA256 dont le résultat est tronqué à 64
|
||||
|
|
@ -513,7 +513,7 @@ bombardement de messages frauduleux jusqu’à réussir à forger un motif corre
|
|||
En comparaison, OMEMO emploie AES256 avec le mode de chiffrement authentifié
|
||||
GCM, considéré à l’état de l’art.
|
||||
|
||||
## Documentation et audits
|
||||
## 3.4. Documentation et audits
|
||||
|
||||
Signal est une cible mouvante. Jusqu’alors dénué de documentation, par une
|
||||
volonté affichée de ses développeurs, ce n’est que sur la pression croissante de
|
||||
|
|
@ -531,7 +531,7 @@ extension expérimentale du protocole XMPP. Il a récemment subi un audit, ayant
|
|||
révélé divers points d’attention [^Audi], qui ont été rapidement pris en compte
|
||||
par le protocole et au moins certaines implémentations.
|
||||
|
||||
# Conclusion
|
||||
# 4. Conclusion
|
||||
|
||||
Cet article a détaillé les atouts et inconvénients de plusieurs protocoles
|
||||
permettant la sécurisation de messageries quasi instantanées. La figure 4
|
||||
|
|
@ -603,13 +603,13 @@ Pour le lecteur intéressé, l’application libre Conversations implémente OME
|
|||
|
||||
---
|
||||
|
||||
# Remerciements
|
||||
# 5. Remerciements
|
||||
|
||||
Je tiens à remercier mes relecteurs : Piotr Chmielnicki, François Contat, Arnaud
|
||||
Ebalard, Sarah De Haro, Olivier Levillain, Mickaël Salaün, et Guillaume Valadon.
|
||||
Les idées exprimées dans cet article ne sauraient les engager.
|
||||
|
||||
# Réferences
|
||||
# 6. Réferences
|
||||
|
||||
[^OTR]: https://otr.cypherpunks.ca/
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ d’intégrité cryptographique des enregistrements DNS, que ce soit pour récup
|
|||
les politiques de sécurité évoquées ci-dessus, ou pour effectuer une
|
||||
vérification de certificats efficace.
|
||||
|
||||
# État des lieux
|
||||
# 1. État des lieux
|
||||
|
||||
Cette section dresse un état des lieux du déploiement des technologies utilisées
|
||||
dans l’écosystème SMTP et qui peuvent être sécurisées grâce à DNSSEC. Des
|
||||
|
|
@ -61,7 +61,7 @@ mesures actives ont été effectuées par l’auteur de cet article en vue de
|
|||
présenter au lecteur une image dénombrée. L’outil de mesures, la méthodologie,
|
||||
ainsi que les résultats bruts peuvent être consultés en ligne [^collect].
|
||||
|
||||
## TLS pour SMTP
|
||||
## 1.1. TLS pour SMTP
|
||||
|
||||
Dans le précédent numéro de MISC, Arthur Provost et Olivier Levillain
|
||||
présentaient les résultats de mesures actives sur les serveurs SMTP afin
|
||||
|
|
@ -96,7 +96,7 @@ de sécurité pour les fournisseurs de service de courriers électroniques allem
|
|||
s’étant autosaisis de la problématique. Il est intéressant de noter que le BSI
|
||||
encourage l’emploi de DNSSEC dans son document.
|
||||
|
||||
## DNSSEC
|
||||
## 1.2. DNSSEC
|
||||
|
||||
L’auteur de cet article décrivait dans ces mêmes colonnes, en 2012, trois
|
||||
mécanismes employant DNSSEC afin de venir au secours de la validation des
|
||||
|
|
@ -123,7 +123,7 @@ Certaines autorités de certification, comme Let’s Encrypt, implémentent
|
|||
cependant la validation DNSSEC de leur propre chef pour l’émission de
|
||||
certificats DV ; un fait à porter à leur crédit.
|
||||
|
||||
## SPF
|
||||
## 1.3. SPF
|
||||
|
||||
{{< abbr SPF "Sender Policy Framework" >}} [^RFC7208] est une politique de
|
||||
sécurité permettant à un émetteur de courriers électroniques de spécifier la
|
||||
|
|
@ -151,7 +151,7 @@ premier niveau (en anglais, {{< abbr TLD "Top-Level Domain" >}}) « .fr » est
|
|||
d’environ 37%. Cependant, seuls 7,4% des zones étudiées contiennent des
|
||||
enregistrements SPF signés avec DNSSEC.
|
||||
|
||||
## DKIM
|
||||
## 1.4. DKIM
|
||||
|
||||
{{< abbr DKIM "DomainKeys Identified Mail" >}} Signatures [^RFC6376] est une
|
||||
politique de sécurité permettant à un émetteur de courriers électroniques de
|
||||
|
|
@ -197,7 +197,7 @@ pas DKIM. Seul 1% des domaines étudiés sont susceptibles d’utiliser DKIM et
|
|||
signés avec DNSSEC. Ces 1% constituent la borne haute du nombre de noms de
|
||||
domaine utilisant DKIM avec une protection contre les attaquants actifs.
|
||||
|
||||
## DMARC
|
||||
## 1.5. DMARC
|
||||
|
||||
{{< abbr DMARC "Domain-based Message Authentication, Reporting and Conformance"
|
||||
>}} [^RFC7489] est une politique de sécurité publiée dans le DNS, permettant de
|
||||
|
|
@ -226,13 +226,13 @@ dans la section 1.2, seuls 12,5% des domaines étudiés sont signés avec DNSSEC
|
|||
sont donc à l’abri de toute attaque active impliquant DMARC en vue d’exfiltrer
|
||||
le contenu des courriers électroniques.
|
||||
|
||||
# Modélisation d’un attaquant actif
|
||||
# 2. Modélisation d’un attaquant actif
|
||||
|
||||
Dans cette section, nous allons exposer une liste non exhaustive des
|
||||
possibilités d’un attaquant actif à l’encontre de SMTP sur TLS, en vue de casser
|
||||
la confidentialité des métadonnées ou des échanges en général.
|
||||
|
||||
## Négociation TLS
|
||||
## 2.1. Négociation TLS
|
||||
|
||||
Certains protocoles, comme IMAP ou POP disposent d’un mode d’usage de TLS dit «
|
||||
implicite ». Cela signifie que la version sécurisée de ces protocoles dispose
|
||||
|
|
@ -318,7 +318,7 @@ Certificate Transparency est une technologie et un écosystème qui permettent a
|
|||
|
||||
---
|
||||
|
||||
## Remplacement des enregistrements MX
|
||||
## 2.2. Remplacement des enregistrements MX
|
||||
|
||||
Lorsqu’un serveur SMTP cherche à envoyer un courrier électronique à un tiers inconnu, la recherche du serveur SMTP à contacter s’effectue grâce au DNS. Pour cela, une recherche d’enregistrement de type MX (pour Mail eXchanger, ou relais de courriers, en français) est initiée. Ces enregistrements contiennent les noms des serveurs SMTP à contacter, noms qui doivent ensuite être résolus en adresse IP. Voici un exemple d’enregistrements MX :
|
||||
|
||||
|
|
@ -385,7 +385,7 @@ Ensuite, utiliser SNI présente le défaut de divulguer une partie des métadonn
|
|||
(le nom du domaine du destinataire parmi les N domaines cohébergés) à un
|
||||
attaquant passif écoutant le réseau.
|
||||
|
||||
# La contre-mesure : DNSSEC et DANE
|
||||
# 3. La contre-mesure : DNSSEC et DANE
|
||||
|
||||
Comme vu dans les précédentes sections de cet article, DNSSEC fournit une aide
|
||||
contre les attaquants actifs. Notamment, les signatures cryptographiques des
|
||||
|
|
@ -462,7 +462,7 @@ le mode dane de Postfix permet un déploiement progressif, offrant une sécurit
|
|||
contre les attaquants actifs si DANE est employé, et conservant le chiffrement
|
||||
opportuniste dans le cas contraire.
|
||||
|
||||
# Conclusion
|
||||
# 4. Conclusion
|
||||
|
||||
Dans cet article, nous avons étudié différentes menaces pouvant affecter les
|
||||
échanges de courriers électroniques, en présence d’un attaquant actif. La figure
|
||||
|
|
@ -496,7 +496,7 @@ rapports dans son validateur DMARC, lorsque la configuration logicielle le
|
|||
permet, afin d’éviter les exfiltrations de métadonnées sur les courriers
|
||||
électroniques.
|
||||
|
||||
# Remerciements
|
||||
# 5. Remerciements
|
||||
|
||||
Je tiens à remercier mes relecteurs, Baloo (@baloose), Olivier Levillain et
|
||||
Christophe Malinge, pour leurs remarques constructives qui ont significativement
|
||||
|
|
@ -505,7 +505,7 @@ contribué à l’amélioration de cet article.
|
|||
Merci également à Claudio Fiandrino pour son code TikZ pour topologies réseaux,
|
||||
publié en [^CCBy].
|
||||
|
||||
# Références
|
||||
# 6. Références
|
||||
|
||||
[^collect]: Outil de mesures DNS développé pour cet article : https://github.com/X-Cli/collectDNSSECEmailStats
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue