Internet: le chiffrement et les sites sécurisés « Propos et Commentaires du Climenole

Internet: le chiffrement et les sites sécurisés

2- Le chiffrement des communications sur Internet

Dans l’article précédent, nous avons donné un aperçu du niveau normal de confidentialité des données lors du transit des données sur Internet. Cette confidentialité a été qualifiée de «niveau carte-postale».

Dans cet article et les suivants, nous verrons les méthodes les plus simples pour acquérir un niveau de confidentialité supérieur lorsque les communications requièrent une protection accrue pour des informations plus «sensibles» de natures personnelle, commerciale ou politique au moyen d’applications telles que le courriel, les messageries instantanées, la VoIP, l’accès sécurisé à des sites qui n’offrent pas ce type de connexion par défaut, etc.

Au fait, quel est le texte dont la version chiffrée apparaît sur l’image?

: Voici un exemple de chiffrement avec GnuPG.

Le texte chiffré est celui du titre de l’image, “Voici un exemple…” Avec l’algorithme RSA sur 4096 bits…

Tout d’abord des précisions sur le vocabulaire correct en cryptographie/cryptanalyse. Le procédé utilisé pour rendre un message illisible à quiconque ne possède pas la méthode valide pour lire en clair le message ainsi codé se nomme «chiffrement» (et non “cryptage”) Ce procédé fait appel à une clé de chiffrement.

Le procédé utilisé pour transformer un message rendu illisible par chiffrement au moyen de la clé valide se nomme «déchiffrement» (et non “décryptage”). Ce procédé fait appel à la clé de déchiffrement.

Les méthodes utilisées pour rendre lisible un message chiffré sans posséder la clé de déchiffrement valide se nomme «décryptage». Ces méthodes font partie de la cryptanalyse.

Les méthodes et procédés pour chiffrer des messages, tel que le programme GnuPG, se nomment «cryptographie».

Chiffrement des données en transit et chiffrement du contenu “bout-en-bout”

Il est important de bien distinguer le chiffrement du transit des données d’avec le chiffrement des données elle-mêmes car si des protocoles tels que Pop3S/Smtp TLS assurent le chiffrement des données durant la connexion aux serveurs, ce chiffrement ne concerne que le transit des données et non le chiffrement des données une fois parvenues à destination.

Autrement dit, si un protocole sécurisé chiffre la communication client/serveur – ce qui implique le chiffrement des données en transit – le chiffrement de ces mêmes données parvenues à destination doit être généré par l’expéditeur avant l’envoi de façon à n’être déchiffrables que par le destinataire, à l’exclusion des tiers.

Pour donner un exemple précis; l’envoi d’un courriel avec le protocole Smtp TLS en utilisant le service Gmail de Google chiffre le transit des données mais non le contenu du courriel une fois celui-ci parvenu à destination tant sur sur les serveurs de courrier de Gmail que sur celui du destinataire.

Le contenu du courriel rendu à destination est lisible en clair par l’expéditeur, le destinataire et les gestionnaires des serveurs concernés! Dans le cas particulier de Gmail, ces courriels sont effectivement lus par des logiciels robots permettant à Google d’afficher les publicités (discrètes et) ciblées basées sur l’analyse du contenu (non-chiffré par l’expéditeur) de ces courriels.

Dans ce exemple, l’utilisation d’une méthode de chiffrement telle que GnuPG + enigmail avec Mozilla Thunderbird, assurerait le chiffrement du contenu même parvenu à destination: les serveurs smtp Gmail et le serveur de réception (Pop3 par ex.) du destinataire. C’est ce qui permet un chiffrement bout-en-bout, le contenu étant lisible exclusivement par l’expéditeur et le destinataire.

a) Les protocoles chiffrés ou le chiffrement des données en transit

Présentation des phases de connexions avec TLS v.1 (ex-SSL)
Exemple d’une connexion sécurisée sans «login» sur le site des extensions de Mozilla (capture avec wireshark)

Négociations: Client HELLO
Négociations: Serveur HELLO
Négociations: le Serveur envoie son certificat au Client
Le Client vérifie le certificat
Échange de clés, spécifications de chiffrement et message chiffré vers le Serveur
Échange de clés, spécifications de chiffrement et message chiffré vers le Client
Application Data: la connexion chiffrée est établie.

La connexion s’établit d’abord avec le handshake habituel en trois étapes:

192.168.2.202 addons.acelb.sj.mozilla.com

TCP 52827 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=9618974 TSER=0 WS=5

Ethernet II, Src: Cisco-Li_6e:5f:40 (00:21:29:6e:5f:40), Dst: 192.168.2.2 (00:1c:f0:ef:76:2e)
Internet Protocol, Src: 192.168.2.202 (192.168.2.202), Dst: addons.acelb.sj.mozilla.com (63.245.209.91)
Transmission Control Protocol, Src Port: 52827 (52827), Dst Port: https (443), Seq: 0, Len: 0
addons.acelb.sj.mozilla.com 192.168.2.202

TCP https > 52827 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460

TCP 52827 > https [ACK] Seq=1 Ack=1 Win=5840 Len=0

puis passe aux phases du Transport Layer Protocol proprement dites:

1- Phase de négociation

séquence 1
Le client envoi vers le serveur sécurisé un message «Client HELLO» précisant la version TLS utilisée ainsi que la liste des méthodes de chiffrement et de compressions supportées

192.168.2.202 addons.acelb.sj.mozilla.com TLSv1 Client Hello

suivi de l’acquittement en provenance du serveur:

addons.acelb.sj.mozilla.com 192.168.2.202 TCP https > 52827 [ACK] Seq=1 Ack=200 Win=6432 Len=0

séquence 2
Le serveur répond avec un message «Server HELLO» indiquant la version du protocole TLS sélectionnée, les méthodes de chiffrement et de compression à partir des données envoyées par le client dans la séquence précédente et possiblement un identifiant de session permettant de reprendre le “handshake” de la connexion.

addons.acelb.sj.mozilla.com 192.168.2.202 TLSv1 Server Hello,

suivi de l’acquittement venant du client:

192.168.2.202 addons.acelb.sj.mozilla.com

TCP 52827 > https [ACK] Seq=200 Ack=1461 Win=8760 Len=0

Le serveur envoi les informations sur certificat et le message d’acquittement pour compléter la séquence de négociation.

addons.acelb.sj.mozilla.com 192.168.2.202 TLSv1 Certificate

Ethernet II, Src: 192.168.2.2 (00:1c:f0:ef:76:2e), Dst: Cisco-Li_6e:5f:40 (00:21:29:6e:5f:40)
Internet Protocol, Src: addons.acelb.sj.mozilla.com (63.245.209.91), Dst: 192.168.2.202 (192.168.2.202)
Transmission Control Protocol, Src Port: https (443), Dst Port: 52827 (52827), Seq: 2921, Ack: 200, Len: 711
[Reassembled TCP Segments (3537 bytes): #24(1375), #26(1460), #29(702)]
Secure Socket Layer

Selon le contexte d’utilisation, une vérification du certificat peut être alors effectuée en ligne avec OCSP (Online Certificate Status Protocol)

suivi par l’acquittement venant du client:

192.168.2.202 addons.acelb.sj.mozilla.com

TCP 52827 > https [ACK] Seq=200 Ack=3632 Win=14600 Len=0

séquence 3
Le client répond avec un message «Client Key Exchange» contenant les informations nécessaires pour le chiffrement selon la méthode choisie à la phase 1 séquence 2.

192.168.2.202 addons.acelb.sj.mozilla.com TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

Le client et le serveur utilisent alors des nombres aléatoires générés dans les séquences précédentes ainsi qu’une information nommée «PreMaster secret» afin de calculer une nouvelle information secrète commune nommée «Master Secret» qui sera utilisée pour la suite de l’échange de données chiffrées.

2. Phase d’échange des spécifications de chiffrement «ChangeCipherSpec» vers le client

Séquence 1
Le serveur envoi alors un enregistrement du «ChangeCipherSpec» indiquant au client qu’à partir de ce moment les envois de données seront authentifiés et chiffrés selon la méthode résultant des phases précédentes.

addons.acelb.sj.mozilla.com 192.168.2.202 TLSv1 Change Cipher Spec, Encrypted Handshake Message

suivi de l’acquitement venant du client:

192.168.2.202 addons.acelb.sj.mozilla.com TCP 52827 > https [ACK] Seq=514 Ack=3679 Win=14600 Len=0

Séquence 2
Selon le contexte d’utilisation le client peut envoyer un message authentifié et chiffré contenant un «message authentication code (MAC)» et une fonction de hachage (somme de contrôle ou empreinte numérique).

Le serveur tente alors de déchiffrer le message final du client et vérifie la fonction de hachage et le code d’authentification du message et retourne un acquitement vers le client. Si la vérification ou le déchiffrement échoue, le “handshake” est considéré comme ayant échoué et la tentative de connexion sécurisée est terminée.

3. Phase d’échange des spécifications de chiffrement «ChangeCipherSpec» vers le serveur

Séquence 1
Selon le contexte d’utilisation, le client peut envoyer à son tour un enregistrement «ChangeCipherSpec» indiquant au serveur qu’à partir de ce moment les envois de données seront authentifiées et chiffrées avec le trousseau de clés associé au certificat du serveur.

Séquence 2
Le serveur envoi alors son message de complétion authentifié et chiffré vers le client finalisant le “handshake”

addons.acelb.sj.mozilla.com 192.168.2.202 TLSv1 Change Cipher Spec, Encrypted Handshake Message

suivi de l’acquitement venant du client:

192.168.2.202 addons.acelb.sj.mozilla.com TCP 52828 > https [ACK] Seq=514 Ack=3679 Win=14600 Len=0

Ethernet II, Src: Cisco-Li_6e:5f:40 (00:21:29:6e:5f:40), Dst: 192.168.2.2 (00:1c:f0:ef:76:2e)
Internet Protocol, Src: 192.168.2.202 (192.168.2.202), Dst: addons.acelb.sj.mozilla.com (63.245.209.91)
Transmission Control Protocol, Src Port: 52828 (52828), Dst Port: https (443), Seq: 514, Ack: 3679, Len: 0

Le client procède à son tour à la vérification et au déchiffrement et en cas d’échec, le ‘handshake’ de la connexion sécurisée est considéré comme ayant échoué et la tentative de connexion sécurisée est terminée.

4. Phase Application

Cette dernière phase est en réalité la continuation des échanges de données sécurisée (authentifiées et chiffrées) entre le client et le serveur jusqu’à la terminaison de cette connexion. Il s’agit de la connexion TLS proprement dite.

addons.acelb.sj.mozilla.com 192.168.2.202 TLSv1 Application Data

Ethernet II, Src: 192.168.2.2 (00:1c:f0:ef:76:2e), Dst: Cisco-Li_6e:5f:40 (00:21:29:6e:5f:40)
Internet Protocol, Src: addons.acelb.sj.mozilla.com (63.245.209.91), Dst: 192.168.2.202 (192.168.2.202)
Transmission Control Protocol, Src Port: https (443), Dst Port: 52827 (52827), Seq: 18826, Ack: 1931, Len: 1358
[Reassembled TCP Segments (15958 bytes): #37(1460), #38(1460), #40(1460), #43(1460), #45(1460), #47(1460), #49(1460), #51(1460), #54(1460), #56(1460), #58(1358)]
Secure Socket Layer

[...]

RFC 5246 : The Transport Layer Security Protocol

secure.wikimedia.org: Transport Layer Security

RFC 2818 : Http over TLS

secure.wikimedia.org Fr: HTTPS

La particularité importante à souligner ici est que l’utilisation d’une connexion sécurisée à un site web ne dépend pas du choix de l’utilisateur mais de celui du propriétaire du site qui permet ou non une telle connexion et sous certaines conditions. De plus une connexion sécurisée Https n’implique pas que le chiffrement soit robuste et de plus, sur certains sites, il peut y avoir des passages de la connexion entre Https et Http sans avertissement par le site: il existe à ce propos des options de sécurité de Firefox permettant de signaler de tels cas: Préférences de Firefox -> Sécurité -> Messages d’avertissements -> bouton paramètres…

Note sur les fonctions de connexions sécurisées de Firefox

Voir les articles de Geckozone sur les fonctions de sécurité de Firefox v. 3 et les certificats des sites web

agent gris: pas d'information d'identité L69xH69_png_agent-bleu-a5667 L69xH69_png_agent-vert-87b4b L70xH70_png_agent-jaune-00e08 L70xH70_png_agent-rouge-2f77b

- Le bouton d’identification des sites

- Les certificats auto-signés

Quelques protocoles sécurisés alternatifs

La plupart des protocoles utilisés couramment ont un protocole sécurisé alternatif qu’il est préférable d’utiliser chaque fois que la possibilité vous est offerte. Dans le cas du protocole Https nous avons vu que son utilisation est limitée par le site web, que le chiffrement n’est pas toujours complet et souvent chiffré sur le nombre de bit minimal: 128 bits.

Certains sites offrent cependant une version sécurisée et laissent le choix à l’utilisateur de prendre l’un ou l’autre des accès Internet tel que Wikipedia qui offre un accès SSL (AES 256 bits):

Wikipedia Version Http vs Wikipedia Version Https

Le site des moteurs de recherche Mycroft permet aussi d’ajouter SSL Wikipedia à vos moteurs de recherche Firefox.

Voici une liste partielle des variantes sécurisées des protocoles courants ainsi que les ports utilisés par les applications correspondantes:

{NNTPS} port 563; par exemple le service offert par Motzarella
{SMTP-TLS} port 587, {POP3S} port 995, {IMAP-SSL} port 993; par exemple le service Gmail
{SILC} port 706 ; toujours chiffré: alternative à Irc avec un client Silc tel que Pidgin
{FTPS-data} port 989 + {FTPS-ctrl} port 990; par exemple en utilisant Filezilla serveur ou client
{XMPP-alt} port 5223; en utilisant les fonctions SSL de PSI un client Jabber

Autres utilisations du chiffrement des données en transit

On doit noter aussi que d’autres applications Internet telles que celles pour les partages de fichiers Pair-à-Pair, de VoIP, de VisioConférence peuvent aussi permettre des connexions sécurisées. Dans le cas des communications audio-vidéo en “temps réel”, bien que des solutions soient disponibles, elles sont loin d’avoir atteintes un niveau acceptable, analogue aux protocoles mentionnés ci-haut. Skype, par exemple, offre bien un accès chiffré mais au moyen d’un logiciel à source fermée dont chiffrement repose sur la “sécurité par l’obscurité“ tandis que d’autres solutions sont loin d’être à un degré d’achèvement auquel on est en droit de s’attendre pour de telles applications.

La VoIP et la VisioConférence en mode sécurisé sont offerts par exemple avec QuteCom (ex-WengoPhone) et le protocole SRTP ou encore le projet Zfone de Phil Zimmerman.

b) Digression sur les requêtes DNS et l’utilisation de serveurs DNS alternatifs

Le chiffrement des communications concerne principalement les applications utilisant le protocole de transport TCP, cependant l’utilisation de serveurs DNS alternatifs, id est, indépendants de ceux du FAI (Fournisseur d’accès Internet) peut contribuer dans une certaine mesure à préserver la confidentialité des communications sur Internet ou plus correctement à limiter et compliquer la traçabilité de vos connexions Internet par un tiers. Un FAI “au long nez” par exemple …

C’est un motif suffisant pour aborder brièvement cette question même si elle ne concerne pas directement la question du chiffrement des connexions.

La requête DNS, préalable aux connexions Internet

Internet ne marche qu’au moyen d’adresses IP et les applications Internet obtiennent la correspondance entre un URI et son adresse IP qu’au moyen de requêtes Domain Name System, protocole de la couche Application lui-même encapsulé dans le protocole UDP de la couche Transport du modèle TCP/IP.

URI, URL, URN: précisions

Un URI (Uniform Resource Identifier) est un ensemble identifiant une ressource sur Internet et incluant un URL ou (ou inclusif) un URN.

Un URL (Uniform Resource Locator) est un élément d’un URI permettant d’accéder à la ressource Internet

Un URN (Uniform Resource Name) est un élément qui identifie une ressource Internet par son nom dans un espace de nom.

La syntaxe d’un URI comprend le schéma identifiant le protocole utilisé, suivie par le signe deux-points et l’adresse de la ressource suivie ou non par une requête et terminée ou non par un fragment:

URI= <schéma>: partie hiérarchique [ ? <requête> ] [ # <fragment>]

schéma ou URN du protocole= protocole utilisé { http, https, ftp, irc, mailto, etc.}

partie hiérarchique ou URL= autorité {[ utilisateur "@" ] hôte [ ":" port ]} {chemin {absolu, sans racine, vide}

Les URI avec http, https sont bien connus mais ne s’y limitent pas. Quelques exemples:

XMPP xmpp:<utilisateur>@<hôte>[:<port>]/[<ressource>][?<requête>]

IMAP imap://[<utilisateur>[;AUTH=<type>]@]<hôte>[:<port>]/<commande>

SMTP mailto:<adresse>[?<entête1>=<valeur1>[&<entête2>=<valeur2>]]

NNTP nntp://<hôte>:<port>/<nom du groupe>/<numéro d'article>

SIP sip:<utilisateur>[:<mot de passe>]@<hôte>[:<port>][;<paramètres uri>][?<entêtes>]

SIPS sips:<utilisateur>[:<mot de passe>]@<hôte>[:<port>][;<paramètres uri>][?<entêtes>]

RSS feed:<uri absolu> ou feed://<partie hiérarchique>

L’utilisation en mode local est aussi possible pour des fichiers, des pages locales, des ressources d’applications.

Par exemple les interfaces de paramétrage des routeurs telle que http://192.168.0.1 , des fichiers locaux avec file:///<chemin>/nom de fichier ou des ressources d’applications comme celles des programmes développés par Mozilla:

chrome://<paquetage>/<section>/<chemin> (où <section> est soit “content”, “skin” ou “locale”) ou “about: nom de ressource”… Voir le KB de MozillaZine: «About protocol links» et «Chrome URLs»

Voir plusieurs exemples sur le site du développeur de l’extension Firefox «Linkification»: Testcases

Voir RFC 3986

La désignation la plus courante est «URL» mais la dénomination correcte pour les adresses dont nous parlons est «URI» et son utilisation devrait être préférée dans les discussions et documents techniques.

Dans le cas – par exemple – d’un navigateur, l’entrée dans la barre d’adresse de l’URI d’un site web déclenche une série d’étapes préalables à la sollicitation de connexion vers ce site web:

La vérification du fichier HOSTS

Le navigateur vérifie la présence ou non de l’URL (l’URI sans l’URN du protocole) dans le fichier HOSTS du système d’exploitation; si l’adresse est trouvée sous la forme {IP} {au moins 1 espace} {URL} la connexion est établie sans requête DNS (normalement mais ce n’est pas toujours le cas…) vers l’adresse IP indiquée (et qui n’est pas nécessairement la bonne!), si l’URL est trouvé sous la forme {127.0.0.1} {au moins 1 espace} {URL} alors la connexion ne se fait pas (bouclage sur localhost) mais habituellement l’URL n’est pas présent dans le fichier HOSTS si bien que;

La requête DNS

Le navigateur envoie à l’adresse IP du serveur DNS, configurée au préalable dans les paramètres du système d’exploitation, un requête pour obtenir l’adresse IP correspondant à l’URI, en UDP vers le port 53 du serveur DNS qui retourne au navigateur l’adresse IP correspondante,

La sollicitation de connexion en 3 phases

Cette adresse IP étant obtenue, le navigateur peut alors utiliser cette adresse IP pour envoyer une sollicitation de connexion via le protocole TCP depuis le premier port dynamique local disponible vers le port 80 (Http) du serveur (dans le cas d’une connexion à un site web non-sécurisé) et suivant le Handshake en trois phases :

TCP + Syn out

le client (navigateur) envoie un paquet TCP avec le flag Syn depuis le premier port dynamique local disponible vers le port 80 du serveur Http,

TCP + Syn Ack in

le serveur répond à cette sollicitation de connexion par un paquet TCP avec le flag Syn-Ack , (si la connexion est acceptée sinon c’est un paquet TCP + Ack-Rst signifiant que le serveur est indisponible et le port fermé) envoyé au client vers le port dynamique du client choisi dans la première phase,

TCP + Ack out

le client confirme alors la connexion en renvoyant depuis le même port dynamique local choisi au début un paquet TCP avec le flag Ack (acquittement de connexion), la connexion entre dans l’état «established» et se poursuit entre le port dynamique choisi au début du côté client et le port 80 du serveur web avec lequel cette connexion est établie tant que dure cette connexion…

Les serveurs DNS alternatifs

Pour utiliser ces serveurs DNS alternatifs, il n’y a rien à télécharger ou à installer. Il suffit de modifier les paramètres de connexion Internet de votre système d’exploitation. Les explications détaillées sont données sur les sites web et pour les principaux S.E.

Connexions Réseau DNS

Le projet le plus complet est celui d’OpenDNS qui offre, en plus du service DNS, un ensemble de fonctionnalités de filtrage de contenu, d’auto-correction des adresses, d’anti-hameçonnage, etc. Cependant les Projet NIC est prometteur et s’il semble disposer de moins de fonctionnalités, c’est une option à considérer. Puisque l’utilisation de ces serveurs alternatifs est simple, un essai vous permettra de décider si les performances et les résultats vous conviennent.

- Open NIC project

88.191.51.140 – France
91.186.21.136 – Royaume-Uni
216.67.98.38 – USA, Alaska
216.87.84.209 – USA, Colorado
71.170.11.156 – USA, Texas
58.6.115.42 – Australie
58.6.115.43 – Australie
119.31.230.42 – Australie

- OpenDNS

208.67.222.222
208.67.220.220

secure.wikimedia.org: OpenDNS

Statut des serveurs OpenDNS

EDIT : Dim 2009/06/21 J’ai fait l’essai d’Open NIC pendant une semaine (serveur 71.170.11.156) et les résultats sont excellents: aucune requête n’a échouée et l’accès est aussi rapide – à vue de nez – qu’avec OpenDNS… Si vous en faites l’essai, n’hésitez pas à laissez un commentaire sur votre expérience.

Une des méthodes assurant un chiffrement des requêtes DNS est leurs transmissions au moyen d’un réseau d’«anonymisation» tel que Tor – The onion router – et à la condition que l’utilisation du réseau Tor soit faite correctement, id est, en prévenant toute «fuite DNS» (DNS leak) en provenance des applications «torréfiées».

Dans le prochain article de cette série consacrée au chiffrement des connexions Internet nous verrons d’abord un bref historique des méthodes de chiffrement puis des exemples précis de la manière de chiffrer soi-même et simplement:

Les certificats personnels
Gnu Privacy Guard
Thunderbird + enigmail
Evolution + SeaHorse
TrueCrypt + EasyCrypt
Le chiffrement de la messagerie instantanée Psi
Le chiffrement du clavardage avec Silc/Pidgin
Le chiffrement de BitTorrent avec Vuze (ex azureus)
L’utilisation du réseau d’anonymisation Tor – The onion router
Le réseau Privé Virtuel OpenVPN
Enfin le Projet Psiphon

À bientôt.

Rédigé par Claude LaFrenière

2009/07/19 à 13:12

	volvox sur Propos sur la bravoure planqué…
	ysengrimus sur Le Moulin à Provocations
	Claude LaFrenière sur Le Moulin à Provocations
	PLR sur Le Moulin à Provocations
	Claude LaFrenière sur Firefox: mes extensions et les…
	volvox sur Firefox: mes extensions et les…
	Claude LaFrenière sur Firefox: mes extensions et les…
	divaba sur Firefox: mes extensions et les…
	volvox sur Linus Torvald quote of the…
	Fabien Tassin (fta) … sur Linus Torvald quote of the…
	Claude LaFrenière sur Firefox 3.5 + Ubuntu: what…
	Nicolas Roberge sur Firefox 3.5 + Ubuntu: what…
	NoiA06 sur Linux pas à la hauteur éructe…
	Claude LaFrenière sur Linux pas à la hauteur éructe…
	Tantrazero sur Linux pas à la hauteur éructe…

Propos et Commentaires du Climenole

Internet: le chiffrement et les sites sécurisés

Auteurs

Blog Stats

RSS

Syndication

Comment Faire?

Catégories

Mises à jour de Twitter

Commentaires récents

Articles récents

Articles les plus consultés

Mots-clefs

Archives

Spam Blocked

Méta