Propos et Commentaires du Climenole

Publié via web from climenole’s posterous

Publié via web from climenole’s posterous

Publié via web from climenole’s posterous

Publié via web from climenole’s posterous

200 years? That’s was a very good cipher code.

Publié via web from climenole’s posterous

Publié via web from climenole’s posterous

Publié via web from climenole’s posterous

3- Méthode de chiffrement du courrier électronique

• Certificats personnels
• Gnu Privacy Guard
• Thunderbird + enigmail vs Evolution + SeaHorse

Dans les articles précédents nous avons vu quel est le niveau normal de confidentialité sur Internet, celui-ci ayant été qualifié de «niveau carte-postale» puis nous avons eu un aperçu des méthodes de chiffrement habituelles offertes aux internautes et dépendant de l’offre de service des sites web.

Dans ce troisième article nous verrons des méthodes de confidentialité par chiffrement décidées par l’utilisateur en utilisant les moyens Open Source mis à sa disposition. Cet article porte sur les méthodes pratiques de chiffrement du courrier électronique pour passer par la suite, dans les articles suivants de cette série, à d’autres applications et enfin à des méthode de chiffrement de l’ensemble des connexions Internet.

a) Les Certificats personnels

• Les certificats: ce qu’ils sont.

Un certificat est une fichier d’identité numérique permettant d’identifier une entité.

Le certificat numérique est un lien entre une entité physique et une entité numérique. Pour être valide ce certificat doit être généré par une autorité de certification ou «tiers de confiance» qui atteste du lien entre l’identité physique et l’entité numérique. La norme utilisée est en général la X.509.

• Obtenir un certificat personnel:

………..

Il est possible d’obtenir gratuitement un certificat personnel pour le courrier électronique chez Thawte et StartSSL , ce certificat est valable pour une année et est importé d’abord dans le navigateur et doit être exporté depuis les options de sécurité du navigateur pour son utilisation dans votre application de courriel.

• Les certificats: utilisations pratiques et limites

Les certificats personnels de courriel peuvent être utilisés pour signer ou chiffrer / déchiffrer vos courriers. La signature numérique attachée à ceux-ci est en quelque sorte un authentification minimale de votre identité numérique… Il est possible de bonifier le degré de confiance de ce certificat au moyen de signatures obtenues de vos correspondants qui reconnaissent la validité de votre authentification en créant un Réseau de Confiance (Web of Trust)…

L’avantage principal d’un tel certificat numérique est d’être issu d’une autorité de certification reconnue. Cependant ces certificats numériques personnels sont limités à l’utilisation du courrier électronique et, éventuellement, du navigateur, ont une durée qui ne dépend pas de vous, ne permettent pas de choisir l’algorithme de chiffrement ni la longueur de la clé générée. Nous verrons plus loin une méthode de chiffrement reposant sur l’utilisation d’un logiciel à source ouverte qui offre plus de flexibilité d’utilisation: GnuPG.

b) Le chiffrement asymétrique ou “à clé publique”…

• Paire de clefs: clé privée et clé publique

Les détails des procédés de chiffrement et l’histoire de ceux-ci dépassent le cadre de cet article et ne seront pas abordés ici. Cependant je vous propose une présentation élémentaire de ce que l’on nomme «chiffrement asymétrique».

Exemple simple. Alice veut envoyer à Bob un message secret que seul Bob pourra lire. Alice met le message dans un coffre et le verrouille avec la clé spécifique à la serrure de ce coffre.

Alice doit donc envoyer à Bob le coffre contenant le message secret et la clé ou une copie exacte de celle-ci. Comme toutes les clés (du “monde physique”) celle-ci permet deux choses: verrouiller et déverrouiller ce coffre…

Alice peut envoyer à Bob le coffre et la clé en même temps ou à deux moment différent. Une fois que Bon a reçu le coffre et la clé, il peut déverrouiller le coffre et lire le message secret qui lui est destiné.

Dans le cas du chiffrement, l’utilisation d’une clé ou de sa copie pour chiffrer et déchiffrer se nomme «chiffrement symétrique». Vous avez sans doute relevé quelques inconvénients de la méthode présentée ici:

Quelque soit la méthode et le moment utilisé par Alice pour envoyer à Bob la clé ou le coffre, au moins l’un de ceux-ci peut être interceptée par un tiers, mettons Oscar, Eve ou Robert. Si la clé ou le coffre est interceptée alors Bob ne pourra pas ouvrir le coffre, si le coffre et la clé sont interceptés par un tiers alors Bob ne reçoit pas le message qui lui est destiné et Alice perd le secret de son message et au moins un tiers a accès à ce message…

Cette histoire pitoyable est celle de toutes les méthodes de chiffrement jusqu’à l’invention récente du «chiffrement asymétrique» par les cryptologues contemporains.

Le «chiffrement asymétrique» permet de séparer – pour les “clefs numériques” – les deux fonctions des clés “physiques” : une clé ou sa copie exacte ne servant qu’à “verrouiller le coffre” et l’autre ne servant qu’à “déverrouiller le coffre”.

La clé ne servant qu’à verrouiller se nomme «clé publique» tandis que la clé ne servant qu’à déverrouiller se nomme «clé privée».

Reprenons l’exemple d’Alice qui veut transmettre un message secret à Bob mais cette fois-ci en utilisant un trousseau ou paire de clefs “asymétrique” (privée + publique):

Alice place le message secret dans un coffre ne pouvant être verrouillé que par la «clé publique» de Bob ou sa copie exacte.

Alice envoie à Bob le message ainsi verrouillé avec la clé publique du destinataire: celle de Bob.

Bob reçoit le message d’Alice et utilise sa «clé privée» pour déverrouiller le coffre et lire le message d’Alice.

Alice et Bob n’ont plus besoin de tout cacher pour empêcher une interception du message secret par un tiers.

Par exemple Bob ne cache que sa clé privée et ne la transmet jamais si bien qu’elle a peu de chance d’être interceptée par un tiers.

Par contre il annonce partout sa «clé publique» (celle qui ne fait que verrouiller) si bien que quiconque veut lui faire parvenir un message secret peut utiliser cette clé publique ou sa copie exacte.

Bob veut-il répondre au message secret d’Alice par un autre message tout aussi secret?

Tout ce que Bob doit faire c’est d’utiliser une de copies de la clé publique de sa destinataire: Alice, de verrouiller ou chiffrer son message avec la clé publique d’Alice et de lui faire parvenir. Et à son tour Alice utilise sa clé privée pour lire (déverrouiller, déchiffre) son message secret.

C’est ce qui se nomme le «chiffrement asymétrique» ou le «chiffrement à clé publique».

• Gnu Privacy Guard

Gpg ou GnuPG (Gnu Privacy Guard) est le logiciel à source ouverte permettant l’utilisation de chiffrement/déchiffrement (fonction de confidentialité) et de signature numérique (fonction d’authentification) au moyen du chiffrement asymétrique.

• Aperçu de l’utilisation des commandes de gpg (GnuPG) version 1.4.9

Algorithmes supportés:

Clé publique: RSA, RSA-E, RSA-S, ELG-E, DSA
Chiffrement: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hachage: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Non-compressé, ZIP, ZLIB, BZIP2

Syntaxe: gpg {espace}[{-- double tiret}options]{espace}[données]

Exemples:

Version de Gpg:  gpg –version
Création d’une nouvelle paire de clefs: gpg –gen-key
Informations sur la paire de clefs: gpg –list-keys
Générer un certificat de révocation: gpg –gen-revoke
Exporter les clefs publiques: gpg –send-keys –keyserver hkp_server_URI key_ID
Importer une clé publique: gpg –recv-keys –keyserver hkp_server_URI key_ID

où:  hkp_server_URI=  l’URI du serveur de clés et key_ID=  l’identifiant de la clé

tels que: http://pgp.mit.edu/ et 0xD771CF94

Le format du nom de serveur est du type schéma_URN:[//]Nom du serveur:port]
où schéma_URN peut être http, hkp, ldap, mailto …

Voir URI, URL, URN: précisions in Le chiffrement sur Internet 1

Pour des détails supplémentaires: gpg –help ou man gpg

• Interfaces graphiques de GnuPG

Des interfaces graphiques permettent l’utilisation des principales commandes de GnuPG mais dans certains cas particuliers vous devrez passer par un terminal pour exécuter une commande du shell, Bash sous Linux et Mac os.

……………………………….

c) Thunderbird + enigmail vs Evolution + SeaHorse (Ubuntu)

• Thunderbird et l’extension enigmail

Dans Thunderbird l’accès au générateur de paire de clefs d’enigmail se fait ainsi:

OpenPGP / gestion des clefs / générer

D’abord il faut

[1] sélectionner le compte de courriel pour lequel la paire de clefs sera générée,

[2] entrer la phrase secrète ou phrase de passe qui doit être du même type que celles indiquées dans l’article L’art du mot de passe 1 de 3, III Méthode ccp – 1, notez que la casse des caractères et les espaces sont significatifs, vous pouvez ajouter un commentaire optionnel.

Notez que l‘option “Pas de phrase secrète” ne doit pas être utilisée sauf pour des tests.

Un des principes de la sécurité des systèmes d’information est la protection par couches (layered security) et le maillon faible d’un tel système est le comportement de l’utilisateur. N’êtes-vous pas d’accord avec moi pour dire que ce n’est pas une bonne idée de compromettre l’utilisation sécuritaire de GnuPG en négligeant la première de ces couches de protection?

[3] il faut ensuite choisir la période de validité de votre paire de clefs: sur ce point je suggère fortement de ne pas choisir l’option de «non-expiration» et de limiter la validité de la paire de clefs à une période allant d’un mois à un an au maximum.

Ceci pour vous assurer que les conséquences d’une paire de clefs compromise, d’une clé privée perdue (“crash” du disque dur de votre ordinateur personnel par exemple ) ou encore de la perte du certificat de révocation – quelques cas vous empêchant d’invalider cette paire de clefs – soient limitées dans le temps.

Une clé publique sans expiration et devenue inutilisable serait alors annoncée en permanence sur les serveurs HKP/LDAP sans possibilité de la révoquer et, utilisée par un correspondant, elle ne servirait qu’à vous transmettre des messages désormais indéchiffrables… Vaut mieux prévenir les mauvaises communications et les “prises de tête” résultantes n’est-ce pas? 

Notez cependant que cela implique que les messages chiffrés reçus ne pourront être déchiffrés que durant la période de validité de ce trousseau de clefs. Si un tel message doit être conservé pour une période au-delà de le limite de validité de la paire ou trousseau de clefs alors il devra être déchiffré et conservé dans cet état ou alors chiffré localement par exemple dans un volume chiffré avec TrueCrypt/EasyCrypt (que nous verrons dans un prochain article…)

[4] Et avant de procéder vous pouvez aussi choisir la taille de la clé ainsi que l’algorithme de chiffrement. [Tailles: 1024, 2048, 4096 - Algorithmes: RSA ou DSA+El Gamal ]. Par défaut la longueur de la paire de clefs est de 1024 bits et l’algorithme RSA.

Dans l’exemple donné nous avons une clé de 4096 bits avec l’algorithme DSA & El Gamal…

[5] La génération de la paire de clefs vous sera annoncée lorsque celle-ci sera terminée:

[6] Vous aurez ensuite la possibilité de créer un certificat de révocation ce que je vous suggère fortement car il vous permet de révoquer la validité de la paire de clé au cas où celle-ci serait compromise (vol de la clé privée par exemple ou perte de cette clé).

Ai-je besoin de préciser que ce certificat de révocation doit être sauvegardé par exemple sur une clé USB et placée dans un lieu sûr. (Juste au cas… )

Voici comment se présente ce certificat de révocation sous Ubuntu Linux dans l’environnement Gnome

Voici les paramètres de la paire de clefs générée:

[7] Il est préférable d’exporter la clé publique sur des serveurs HKP ou LDAP tel que, par exemple, celui du Massachusetts Institute of Technology car cela permet de vérifier le statut ou la validité de cette clé publique de chiffrement en évitant d’utiliser une clé invalide…

[8] Et enfin vous pouvez aussi annoncer cette clé publique dans votre signature de courriel, sur les forums, les Groupes de Discussion, ou sur votre profil public tel que le Profil Google.

Vos correspondants désirant communiquer confidentiellement avec vous n’auront qu’à utiliser votre clé publique pour chiffrer les courriels vous étant destinés et ceux-ci seront déchiffrés par enigmail lors de la réception.

Notez que la confidentialité porte dans ce cas sur le contenu de la communication et non sur le fait que A communique avec B… Il serait possible pour un tiers de connaître le fait que A a communiqué avec B tout en ignorant ce qui a été communiqué…

Nota Bene: Autrement dit si c’est confidentiel, ce n’est pas nécessairement anonyme!

Ces deux notions ne doivent en aucun cas être confondues:

La confidentialité porte sur le contenu des communications entre A et B et non sur leur identité ni sur le fait qu’il y a eu communication.

L’anonymat porte sur l’identité de A et B mais pas nécessairement sur le contenu de leurs communications. En attendant je vous invite à tenter de résoudre cette énigme amusante:

Question: Comment peut-on communiquer à la fois anonymement et confidentiellement? 

L’utilisation est fort simple: pour envoyer une courriel chiffré à votre correspondant vous devez simplement sélectionner sa clé publique et le contenu sera automatiquement chiffré par enigmail en faisant appel aux fonctions de GnuPG. Votre correspondant sera alors en mesure de lire en clair le message ainsi chiffré avec sa clé publique en utilisant sa clé privée correspondante.

Cette clé publique de votre correspondant est annoncée sur les serveurs HKP/LDAP vous permettant d’importer localement cette clé pour lui envoyer un message chiffré.

L’opération inverse est tout aussi facile: un courriel reçu et chiffré avec votre clé publique sera déchiffré par enigmail avec votre clé privée. Je parle bien entendu de la clé privée faisant partie du trousseau de clefs ou si vous voulez de la clé privée correspondant à la clé publique et pour la période de validité de cette paire ou trousseau de clefs!

Notez que les courriels chiffrés doivent être en format texte seulement et non en HTML …

De plus enigmail vous permet d’utiliser votre trousseau de clefs pour ajouter une signature numérique à vos courriels même non-chiffrés – ce que je vous encourage à faire systématiquement – car cela permet d’authentifier la provenance du courriel en question. Une telle signature utilisée systématiquement assure que personne n’utilisera votre identité pour envoyer des courriels usurpant votre identité…

Exemple de vérification de signature:

Exemple de sélection de l’option de chiffrement avec la clé publique du destinataire et combinée avec l’option de signature avec la clé publique de l’expéditeur. Il suffit de posséder la clé publique du destinataire par exemple via un serveur HKP… Le chiffrement est fait avec sa clé publique et la signature est (évidemment!) faite avec votre clé publique et non la sienne…

Voici maintenant un exemple de message chiffré:

Notez que le message a été chiffré par l’expéditeur avec la clé publique du destinataire et peut être déchiffrée par le destinataire avec sa clé privée correspondant au trousseau de clefs. Si la clé privée a été perdue ou si la paire de clé est expirée ou révoquée, alors ce message ne pourra jamais plus être déchiffré…

Digression: dans un article antérieur portant sur l’effacement sécurisé des données , j’avais présenté quelques solutions permettant de détruire sécuritairement des données avec des logiciels utilisant des techniques de ré-écriture du disque dur …

Si vous avez bien suivi jusqu’ici, nous venons tout juste de découvrir une autre méthode pour interdire à tout jamais à quiconque de lire ces données vouées au néant: les chiffrer avec GnuPG, ensuite supprimer sécuritairement la clé privée selon l’une des méthodes vues dans l’article mentionné (par exemple Gutmann 35 passes de ré-écriture) puis de supprimer le contenu ainsi chiffré de façon non-sécuritaire. Même dans ce cas, les données à détruire seraient irrémédiablement illisibles à quiconque. Elles pourraient bien être récupérables mais cela serait inutile car elles seraient sous une forme chiffrée sans possibilité ni de les déchiffrer (la clé privée ayant été sécuritairement détruite) ni de les casser par cryptanalyse (à moins de croire à la science-fiction), le chiffrement en question étant, jusqu’à nouvel ordre, incassable…

Bref

• La vérification de la signature numérique d’un message reçu se fait en consultant le statut de la clé publique du destinataire sur l’un des serveurs HKP/LDAP sur lesquels la clé publique a été exportée, enigmail permettant de réaliser facilement cette vérification.

• L’utilisation de la signature d’un message à expédier se fait en vérifiant localement le statut de votre trousseau de clé.

• Le déchiffrement d’un message chiffré avec votre clé publique se fait localement avec votre clé privée correspondante par la vérification qu’enigmail fait du statut de votre trousseau ou paire de clefs.

• Le chiffrement d’un message à expédier se fait en vérifiant la validité de la clé publique de votre destinataire sur l’un des serveurs HKP/LDAP sur laquelle sa clé publique est annoncée.

En somme, l’extension enigmail de Thunderbird permet d’utiliser facilement les fonctions de chiffrement/déchiffrement de GnuPG incluant la génération du trousseau de clefs, la génération du certificat de révocation et son utilisation le cas échéant, la signature numérique des courriers ainsi que toutes la plupart des fonctions reliées à l’utilisation de GnuPG.

Truc: pour essayer et pratiquer l’utilisation d’enigmail, il vous suffit d’avoir deux comptes de courriels, de générer un trousseau de clé pour chacun de ces comptes et de vous envoyer des messages chiffrés, signés ou les deux. Quand vous vous sentirez parfaitement à l’aise avec l’utilisation des fonctions d’enigmail, il vous sera alors plus facile de les utiliser avec vos correspondants. 

Passons maintenant à des applications alternatives: la messagerie Evolution et l’utilitaire SeaHorse. Notez que ces derniers, contrairement à «Tb + em» ne sont disponibles que sur Linux…

• Evolution et l’utilitaire SeaHorse

Dans le cas de la messagerie par défaut d’Ubuntu Linux, Evolution, il est possible d’utiliser un certificat numérique ou une clé Gpg mais la gestion des clés est faite via une application externe à Evolution: SeaHorse.

L’un des avantages de SeaHorse est qu’il permet la gestion des clefs de shell sécurisé, de courriel, d’applications telle que la messagerie instantanée Psi (Xmpp/Jabber) et de mots de passe pour les applications et le réseau.

Pour accéder à SeaHorse: en ligne de commande: seahorse ou via le bureau Gnome d’Ubuntu:

Applications / Accessoires / Mots de passe et clé de chiffrement :

La création d’une paire de clefs Gpg (ou “Pgp”) commence par le choix de cette option dans SeaHorse:

Puis par l’entrée d’informations analogues à celles déjà vues avec enigmail:

et enfin l’ajout de l’identifiant de la paire de clefs obtenu dans les paramètres du compte de courriel dans Evolution: Édition / Préférences / bouton «Compte de Messagerie» / sélectionnez le compte dans la liste puis «double-clic» pour l’éditer / onglet «Sécurité»:

Notez que

SeaHorse ne permet pas d’accéder à la fonction de création d’un certificat de révocation de la paire de clefs qui doit être fait via cette commande GnuPG:

gpg  –gen-revoke

Les développeurs de la messagerie Evolution ne prévoient pas intégrer un équivalent d’enigmail dans Evolution ce qui est déplorable AMHA…

cf.: Evolution FAQ: «Managing GPG/PGP is beyond the scope of Evolution.»

Dans les prochains articles de cette série nous verrons comment chiffrer la messagerie instantanée Psi, un client Xmpp/Jabber, le chiffrement du clavardage avec Pidgin utilisé avec sa fonction de client SILC, le chiffrement des échanges P2P avec Vuze, un client BitTorrent, le chiffrement des données locales avec TrueCrypt et EasyCrypt, l’utilisation du réseau Tor – The onion router -, le réseau privé virtuel OpenVPN et enfin le projet Psiphon.

À bientôt. 

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?

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)

1. Négociations: Client HELLO
2. Négociations: Serveur HELLO
3. Négociations: le Serveur envoie son certificat au Client
4. Le Client vérifie le certificat
5. Échange de clés, spécifications de chiffrement et message chiffré vers le Serveur
6. Échange de clés, spécifications de chiffrement et message chiffré vers le Client
7. 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

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: 0, Ack: 1, Len: 0
192.168.2.202         addons.acelb.sj.mozilla.com

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

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: 1, Ack: 1, Len: 199
Secure Socket Layer

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

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: 1, Ack: 200, 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,

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: 1, Ack: 200, Len: 1460
Secure Socket Layer

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

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: 200, Ack: 1461, 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

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: 200, Ack: 3632, 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

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: 200, Ack: 3632, Len: 314
Secure Socket Layer

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

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: 3632, Ack: 514, Len: 47
Secure Socket Layer

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

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: 514, Ack: 3679, 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

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: 52828 (52828), Seq: 3632, Ack: 514, Len: 47
Secure Socket Layer

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

-  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.

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. 

1- Le niveau de confidentialité: un aperçu du problème.

Le problème de la confidentialité des communications et de leurs traces laissées sur Internet est en général peu compris. On ne compte plus les soi-disant méthodes de protection de la confidentialité proposant comme panacée l’utilisation de proxys (serveurs mandataires) associées ou non à la suppression de certaines traces en local.

Inutile de dire que ces méthodes sont insuffisantes, créent une impression trompeuse de sécurité et sont  à la limite de la fausse représentation. Camoufler son adresse IP derrière celle d’un serveur mandataire remet le contrôle ầ un tiers qui ne mérite pas nécessairement notre confiance, effacer la journalisation du navigateur ne concerne que les traces locales et selon une méthode insuffisante, la suppression des données étant “logiques” et non “physiques”.

• [voir par ex.: Défragmentation et effacement sécurisé]

En mettant de côté, pour le moment, les traces locales, il serait peut-être utile de dresser un aperçu général de cette question importante pour la préservation de la vie privée.

a) Les étapes normales d’une connexion Internet vers un site Web

La meilleure façon d’aborder le problème est de suivre les traces laissées à partir du moment où une adresse web, un URL, est saisie dans le champ d’adresse du navigateur…

• Un URL (Uniform Ressource Locator) doit être associé à une adresse IP et la première étape  d’une connexion à un site est la requête DNS (encapsulée dans le protocole de transport UDP) et permettant de traduire l’URL dans son adresse adresse IP correspondante: cette traduction est assurée par un serveur DNS, en général celui du FAI, qui, on s’en doute un peu, peut conserver dans ses journaux la trace de cette requête.

Il est bien connu d’ailleurs que les principaux FAI conservent ces traces mais il est difficile de savoir pour combien de temps, quelle protection est assurée à ces informations et l’usage qu’ils en font ou pas…

Commissariat à la vie privée du Canada – Inspection approfondie des paquets

• Une fois cette adresse IP associée à l’URL, la connexion peut alors s’enclencher via le protocole TCP pour accéder au site mais cette connexion n’est jamais directe contrairement à ce que les apparences pourraient le laisser croire. La connexion passe par une série d’intermédiaires incluant les serveurs et routeurs du FAI mais ne s’y limitant jamais. Il est possible d’avoir un aperçu (pas toujours exact) avec un utilitaire de “Trace Route ” qui montre à qui en doute que le chemin le plus direct vers un site n’est pas celui qu’on croît…  Par exemple un chemin de connexion entre mon ordinateur et le serveur de WordPress (variable pour chaque connexion):

• Une fois que la connexion entre le PC et le site est établie tous les échanges entre ceux-ci via les routeurs intermédiaires sont EN CLAIR, c’est-à-dire, lisibles par n’importe lequel de ces intermédiaires sur la “route de connexion “…  Dans le cas par exemple du protocole Pop3 (Post Office Protocol v. 3), l’identifiant, le Mot de Passe (oui!) et le contenu du courriel sont transmis en clair. Le chiffrement d’une connexion ne se produit en général qu’avec le protocole Https [RFC  2817 - 2818] par exemple lors d’un paiement en ligne, connexion chiffrée sur 128 bits ou + et avec les implantations sécurisées de protocoles courants tels que par exemple:

……….Pop3S : port 995 en remplacement de Pop3  port 25
……….Smtp Tls :  port 587 en remplacement de Smtp port 110
……….Nntp Ssl : port 563 en remplacement de Nntp port 119
……….Ldap Ssl : port 636 en remplacement de Ldap port 389
……….Ftp Ssl :  ports 989-990 en remplacement de Ftp ports 20-21
……….Imap Ssl : port 993 en remplacement de Imap port 143
……….Irc Ssl : port 6697 en remplacement des ports 6667 à 6669

………..etc.

• Enfin, le site web sur lequel le PC est connecté peut lui aussi conserver des traces de cette connexion et peut récupérer des informations de configurations normales mais aussi d’autres informations telle que le referer et parfois beaucoup plus en utilisant des programmes exécutables du Web tels que les activeX (MSIE) , du Javascript, du Java, des Local Shared Objects, ou récupérant des informations de “cookies traceurs“…

• Notez que les exécutables en question sont d’abord téléchargés par le navigateur et exécutés localement: sur votre ordinateur. Pour dire les choses le plus simplement possible, un navigateur fait trois chose: téléverser, télécharger et mettre en forme. Lors d’une connexion le navigateur transmet des informations sur sa configuration de même que certaines informations telles que le referer, id est, l’adresse IP du site d’où vous arrivez. Il télécharge une copie du contenu du site web: texte, html, images et aussi les exécutables tel que des commandes en Javascript. Enfin il donne un rendu graphique à l’ensemble. Les ActiveX de MS I.E. sous Windows et le javascript dans les autres cas, peuvent et servent effectivement, de vecteurs à des parasites divers tels que les virus et spywares. Vous pouvez facilement vérifier ce que votre navigateur “upload” en utilisant les tests Browser Spy d’Henrik Gemal

C’est d’ailleurs au moyen de l’Inspection Approfondie des Paquets que les soi-disant Grand Pare-feu mis en place par le gouvernement chinois réussit à filtrer puis à bloquer le libre accès à Internet contrevenant au principe de la Neutralité des Réseaux (ceci sera l’objet d’un prochain article).

Des chercheurs de l’Université de Cambridge, U.K.: Richard Clayton, Steven J. Murdoch, et Robert N.M.Watson ont découvert comment passer outre à la censure d’internet par les autorités chinoises en étudiant le près les méthodes utilisée au niveau du protocole TCP-IP.

Ils expliquent que le soi-disant Grand Pare-feu de Chine fonctionne en grande partie en inspectant les paquets TCP pour repérer les mots-clés devant être bloqués. Si le mot-clé est présent alors un paquet TCP de réinitialisation (paquet TCP avec le flag RST) est retourné aux points d’origine et de destination de la connexion fermant ainsi la connexion. Toutefois le paquet original est passé sans modifications et si les points de connexion ignorent les paquets de réinitialisation provenant du filtre des censeurs, la connexion se poursuit sans problème. Une fois qu’une connexion a été bloquée le filtre des censeurs fait d’autres tentatives contournables pour bloquer la suite les tentatives de connexions des points d’origine et de destination. Cette dernière méthode peut alors causer une attaque en déni de service envers les points de connexion.

Les auteurs expliquent qu’ils ont d’abord accédés à une simple page web normalement comme ils s’y attendaient. Comme il peut être constaté avec la transcription du vidage de paquets montré ici, après la poignée de main en trois étapes normales (SYN, SYN/ACK, ACK) le client utilisant dans l’exemple le port 53382, envoie une commande HTTP GET au port HTTP 80 du serveur pour obtenir le dossier racine (/) qui est transféré normalement:

1. cambridge (53382) -> chine (http) [SYN]
2. chine (http) -> cambridge (53382) [SYN, ACK]
3. cambridge (53382) -> chine (http) GET / HTTP/1.0<cr><lf> etc.
4. chine (http) -> cambridge (53382) … Etc.
5. cambridge (53382) -> chine (http) [ACK] et ainsi de suite…

Par contre quand ils ont envoyé une requête incluant un petit fragment de texte (falun) dont ils avaient prévus le blocage la confirmation de leur hypothèse s’est rapidement produite:

1. cambridge (54190) -> chine (http) [SYN]
2. chine (http) -> cambridge (54190) [SYN, ACK] TTL=39
3. cambridge (54190) -> chine (http) [ACK]
4. cambridge (54190) -> chine (http) GET /?falun HTTP 1.0<cr><lf>…
5. chine (http) -> cambridge (54190) RST TTL=47, seq=1, ack=1
6. chine (http) -> cambridge (54190) RST TTL=47, seq=1461, ack=1
7. chine (http) -> cambridge (54190) RST TTL=47, seq=4381, ack=1
8. Etc.

L’étude “Ignoring the Great Firewall of China” est disponible au complet en format PDF:

Prises indépendamment les unes des autres, ces informations laissées en traces ici ou là ne sont pas en elles-mêmes des atteintes à la vie privée mais permettent le “Data Mining” c’est-à-dire, le recoupage d’information qui permettent de monter un profil identifié et associé à telle ou telles adresse IP (la vôtre) et en dernière analyse à une personne bien précise: l’internaute “X”.

De plus il est bon de savoir qu’un site web même supprimé laisse encore des traces (dont les vôtres possiblement) car Internet ne perd pas la mémoire: le Wayback Machine est là pour en témoigner.

En somme, le niveau de confidentialité normal sur Internet est en quelque sorte l’équivalent de la transmission du courrier avec une carte-postale et ne devrait par conséquent être utilisé que pour des informations aussi peu confidentielles que celles que nous avons l’habitude d’envoyer avec celles-ci.

Il est facile de tomber à ce propos dans une sorte de paranoïa, celle des “paranautes” © climenole et d’oublier que la possibilité de lire en clair ces communications ne signifie pas nécessairement qu’elles soient filtrées et lues ni que la vie privée des internautes est actuellement sous surveillance. Le sens commun nous préserve de ces exagérations sans toutefois nous empêcher d’utiliser d’autres méthodes lorsqu’il s’agit de données confidentielles, personnelles ou commerciales.

Dans le prochain article de cette série nous verrons les moyens à notre disposition pour préserver la privauté des données et des communications sur Internet: chiffrement des données locales, des courriels et des connexions Internet.

À bientôt. 

Dans le premier article de cette série, nous avons vu comment créer simplement des Mots de Passe raisonnablement robustes et facilement mémorisables de même que les limites inhérentes à cette méthode. Dans le second article, une solution plus adaptée a été suggérée: l’extension Firefox PasswordMaker permettant de passer outre aux limitations de la première méthode.

Dans ce dernier article portant sur l’authentification, nous verrons une nouvelle solution proposée pour simplifier la gestion de l’Identité Numérique et l’accès sécurisé aux nombreux services disponibles et de plus en plus utilisés par les internautes.

Mais tout d’abord une définition de ce qu’est OpenID:

« OpenID est un système d’authentification décentralisé qui permet l’authentification unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier auprès de plusieurs sites (devant prendre en charge cette technologie) sans avoir à retenir un identifiant pour chacun d’eux mais en utilisant à chaque fois un unique identifiant OpenID. Le modèle OpenID se base sur des liens de confiance préalablement établis entre les fournisseurs de services (sites web utilisant OpenID par exemple) et les fournisseurs d’identité (OpenID providers). Il permet aussi d’éviter de renseigner à chaque fois un nouveau formulaire en réutilisant les informations déjà disponibles. »

• Nom de la page : OpenID
• Auteurs : secure.wikimedia.org
• Éditeur : Wikipédia
• Dernière révision : 31 mai 2009 20:11 UTC
• Page consultée le : 5 juin 2009 15:36 UTC
• Lien vers la version citée
• Numéro de version : 41522023

La première étape consiste d’abord à obtenir une identité par l’un des fournisseurs OpenID. En créant un compte chez l’un des fournisseurs vous devez fournir un nombre limité de détails vous concernant tel que votre adresse de courriel, votre nom, votre pseudonyme et d’autres informations permettant de vous identifier plus précisément tel que par exemple l’adresse de votre site Internet.

Le fournisseur d’OpenID génère alors un certificat numérique qui relie le navigateur utilisé pour la création de votre compte et les informations que vous avez donné au moment de sa création. C’est ce certificat qui sera vérifié chaque fois qu’un accès à un site sécurisé sera obtenu via votre OpenID.

.

• l’utilisateur/client (navigateur+certificat): identifié par un URI telle que utilisateur.fournisseursOI.com
• le consommateur (Relying Party) : le site sécurisé vérifiant l’identité de l’utilisateur.
• le fournisseur d’identité (OpenID Provider) : le serveur d’authentification OpenID

Les 7 étapes du processus d’authentification lors d’une connexion sont les suivantes:

1. L’utilisateur/client fournit l’URI de son profil OpenID
2. Le site de connexion sécurisée contacte le site du fournisseur OpenID
3. Les deux sites échangent des informations numériques générant un «secret partagé»
4. Le site de connexion sécurisée redirige l’utilisateur/client vers le site du fournisseur
5. L’utilisateur/client entre son identifiant et son Mot de Passe [Voir Art. 1 et 2]
6. Le site fournisseur OpenID vérifie le certificat numérique du navigateur de l’utilisateur/client
7. Le navigateur de l’utilisateur/client envoie l’autorisation (obtenue par le «login» au fournisseur OpenID ) vers le site de connexion sécurisé pour compléter la procédure d’authentification.

Exemple avec VeriSign Labs Personnal Identity Portal

Je suppose ici que le compte OpenID a déjà été créé chez VeriSign Labs de la même façon que pour n’importe quel compte de site web: avec Identifiant et Mot de Passe généré selon les règles de l’art… et que l’extension Firefox VeriSign OpendID SeatBelt a été installé. Et que vous avez activé la connexion/vérification avec votre fournisseur OpenID, VeriSign en l’occurence…

Voici comment ça marche étape par étape pour l’utilisateur lors d’une première connexion:

La fenêtre de connexion sécurisé du site supportant OpenID s’ouvre et vous donne le choix entre le «login» habituel ou avec l’identifiant OpenID (L’URI de votre identité OpenID).

Votre fournisseur vous demande alors si vous autorisez l’utilisation de votre identité OpenID par le site de connexion. Cette autorisation peut-être refusée, autorisée temporairement ou en permanence …

… et ces paramètres peuvent être modifiées par la suite…

Finalement, si vous avez autorisé ce site à contacter votre fournisseur OpenID, la connexion se fera tout simplement avec pour seul identifiant l’URI de votre identité OpenID. Simple comme ça! 

Nota Bene:

• Vous avez peut-être déjà une identité OpenID, par exemple si vous avez un compte sur la plateforme WordPress… Si c’est le cas vous pouvez simplement utiliser l’URI de votre blog WP comme identifiant OpenID ou, selon votre choix, utiliser un autre fournisseur. Vous pouvez vérifier cela en consultant le répertoire des fournisseurs OpenID (en anglais).
• Je vous suggère néanmoins d’utiliser un fournisseur OpenID qui est déjà reconnu dans le domaine de la gestion des certificats numériques. C’est pourquoi je vous ai suggéré VeriSign.
• L’adoption d’OpenID n’est pas universelle et bien qu’elle se généralise, elle n’est pas encore une solution reconnue universellement ou en tant que norme ( un «standard»). Bon nombre de sites n’ont pas encore d’accès sécurisé via OpenID. De la même façon que certains sites web pourtant connus, tel que Digg, n’acceptent même pas de Mots de Passe robustes, alphanumériques + caractères spéciaux… Néanmoins Google, facebook et de nombreux services Web importants on déjà reconnu la méthode d’authentification OpenID. [LISTE] en anglais.
• Le certificat numérique généré lors de votre inscription à un fournisseur OpenID est indispensable et votre identification ne marche qu’avec le certificat généré pour ce navigateur. De plus, même s’il est possible de récupérer votre compte OpenID suite à la perte du certificat, il est préférable d’exporter celui-ci et de le conserver, par exemple sur une clé USB, juste au cas…

Dans les Préférences de Firefox: avancés, onglet chiffrement, bouton afficher les certificats, bouton sauvegarder. Le fichier à conserver est un certificat PKCS12.

Voilà. À bientôt!

Comment ajouter un OpenID associé à son nom de domaine par Volvox de Volvoxsoft

« La lecture de cet article m’a lancé à la conquête d’un openid associé à mon nom de domaine.

J’utilise MyopenID, bien coté, pour ce faire.

Avec une méthode alternative que celle de la validation avec un CNAME redirigé vers le domaine.

MyOpenId vérifie mon domaine à l’aide d’un mot de passe sur une page que j’ai ajouté consultable seulement par lui. La validation de la page et du domaine est faite à intervalle fixe. Le domaine étant validé, j’ai pu modifié la page habituelle du LogIn de WordPress (chez volvoxsoft) pour y ajouter la demande d’acquisition d’un OpenID valide pour mon domaine ou pour tout autre acceptant un OpenID.

DÉLÉGATION OPENID

Un truc, pour ceux qui peuvent éditer leur page d’accueil (exemple header.php, index.html). Il est possible de déléguer son openID vers le nom de domaine de son site. Il faut ajouter ces liens dans l’en-tête de la page (exemple appliqué pour le serveur myopenid.com):

<link rel=”openid.server” href=”http://www.myopenid.com/server“>
<link rel=”openid.delegate” href=”http://xxxxxxx.myopenid.com/“>

(xxxxx.myopenid.com étant l’authentification openid que l’on possède )

Ainsi, il suffit de taper le nom de domaine de son site pour n’importe quelle identification openid demandée. »

Merci à Volvox! 

Volvoxsoft est le développeur de plusieurs applications dont ALICE COMPTABLE et plusieurs autres logiciels de gestion ainsi qu’un grand nombre d’utilitaires sous Windows.

Volvox Lab

Logiciels commerciaux

Logiciels et utilitaires gratuits

Forum

Voir aussi cet article: Volvox: plusieurs utilitaires à découvrir

Dans l’article précédent nous avons vu les 2 critères de base des bons Mots de Passe et une méthode pour créer de tels Mots de Passe qui soient à la fois (raisonnablement) robustes et (facilement) mémorisables.

Nous avions aussi mentionné le problème des limitations pour son utilisation pratique dans un contexte de multiplication des demandes d’authentification sur le Web. Il est temps de passer, non à la solution mais à une suggestion de solution à ce problème: l’extension Firefox PasswordMaker d’Eric H. Jung.

PasswordMaker permet de générer des Mots de Passe robustes et de les utiliser via un simple clic sur l’icône dans la barre d’outils de Firefox, le menu contextuel ou un raccourci clavier. L’extension offre un ensemble de fonctionnalités et de paramètres capables de satisfaire les plus exigeants mais les options par défaut pourront suffire amplement aux besoins de la vaste majorité des utilisateurs.

Une de caractéristique important de PasswordMaker est que le vol de votre Mot de Passe principal est en lui même insuffisant pour permettre à un tiers d’accéder à vos ressource protégées par les MdP générés par l’extension.

En effet, PasswordMaker utilise jusqu’à 10 variables pour l’algorithme de calcul des MdP:

1. L’URL du site de connexion (+ 4 sous-variables)
2. Le jeu de caractères utilisé
3. L’algorithme de ‘hashage’ (9 en tout)
4. Le modificateur (si utilisé)
5. Le nom d’utilisateur (si utilisé)
6. La longueur du MdP
7. Le préfixe du MdP (si utilisé)
8. Le suffixe du MdP (si utilisé)
9. L’un des 9 niveau de ‘l33t speak’ (si utilisé)
10. Quand le ‘l33t speak’ est en usage (si utilisé)

Les MdP générés ne sont conservés nulle part mais sont recalculés à chaque fois que vous en avez besoin pour vous connecter à un site sécurisé. De plus la mémoire utilisée pour le calcul est automatiquement vidée ne laissant aucune trace en mémoire physique ou virtuelle, dans le fichier de pagination (swap file) ou dans un fichier quelconque. Enfin l’utilisation de PasswordMaker ne transmet rien sur Internet ou en bouclage local (sur 127.0.0.1) et vous met aussi à l’abri des ‘keyloggers’.

Qu’en est-il alors du MdP principal si l’on choisit l’option de le conserver sur le disque? Dans ce cas ce MdP principal est chiffré sur 256 bits dans le fichier passwordmaker.rdf dans votre profil d’utilisateur et celui-ci peut être à son tour chiffré par exemple avec GnuPG…

Les algorithmes de ‘hashage’ possibles sont: MD4   HMAC-MD4   MD5   HMAC-MD5   SHA-1   HMAC-SHA-1   SHA-256   HMAC-SHA-256   RIPEMD-160   HMAC-RIPEMD-160 , les plus robustes étant de l’avis général SHA-256, HMAC-SHA1, HMAC-MD5 et HMAC-SHA-256  mais les autres sont valables pour la plupart des usages courants et pour la majorité des utilisateurs.

Un mot à propos des collisions d’algorithmes, id est, la découverte ou plutôt la production d’au moins 2 séquences ou fichiers différents générant la même somme de contrôle avec l’un des algorithme de ‘hashage’. De telles ‘collisions d’algorithme’ ont été rapportées pour les algorithmes suivants: MD4, MD5, RIPEMD,  HAVAL-128 (non utilisé par PwdMkr) et SHA-1…

Beaucoup d’encre, de salive et de bande passante ont été utilisées à propos de ces ‘collisions’ en négligeant la plupart du temps de préciser que la production de tels événements nécessite des ressources et des compétences hors de l’ordinaire de telle sorte que la probabilité d’une ‘attaque’ massive contre ces algorithmes est faible. Certes, par prudence, les gouvernements et institutions devraient en général éviter d’utiliser un algorithme ‘compromis’ (si peu!) mais l’utilisation de l’un de ceux-ci dans le contexte dont nous parlons n’est pas pertinent.

De plus l’auteur de PasswordMaker n’est pas sans rappeler que

«…it’s important to note that the one-way nature of these algorithms has not been undermined. In other words, in the context of PasswordMaker, hash collisions do not empower someone with the ability to derive your master password if they have your generated (hashed) passwords. The hash collision attacks have no relevance to PasswordMaker except there is very small chance someone could choose a different master password than yours which hashes to the same generated password. However, he would still need your username and the URL in order to hack your account.»

Si bien qu’à moins de combiner l’imprudence, la malchance et une bonne dose de stupidité, il est – en pratique – impossible de compromettre vos comptes utilisant des MdP générés par PasswordMaker.

Enfin PasswordMaker offre des options d’export / import des paramètres et la possibilité d’auto-complétion des formulaires:

.

L’utilisation de l’extension est aussi simple que possible: lors de la connexion à un site demandant l’authentification par votre MdP, il vous suffit de compléter le champ MdP de la page de connexion via le menu contextuel ou une icône dans la barre d’outil du navigateur et le tour est joué! 1 clic.

.

En somme, il vous suffit de créer un seul mot de passe robuste ET mémorisable tel que vu dans la premier article puis de l’utiliser avec PasswordMaker pour respecter tout à la fois les critères d’interdiction d’accès à des tiers, de mémorisation facile du MdP et de la génération sécurisée d’un MdP robuste pour chacun des sites auxquels vous accédez. Simple non?

Dans le troisième et dernier article de cette série, nous verrons une méthode prometteuse pour l’authentification sécurisée au moyen d’OpenID, par contre les questions de certificats de sécurité, de chiffrement et de leur utilisation feront partie d’une autre série d’articles.  Alors à bientôt ! 

Avec la multiplication des services Internet et des sites de “Ouaibe Social” , les internautes sont confrontés à l’obligation d’utiliser à chaque fois une identification sécurisée avec Identifiant et Mot de Passe en plus des Mots de Passe locaux pour les comptes d’utilisateurs et d’administrateurs de système.

Dans cette série d’articles portant sur l’authentification, nous verrons tout d’abord une méthode simple mais d’apparence complexe à première vue pour créer et mémoriser un Mot de Passe d’un niveau de sécurité raisonnable, dans le second article nous aborderons une méthode pour faire face à la multiplication des besoins en Mots de Passe et enfin, dans un dernier article, nous aborderons l’authentification via OpenID.

Il ne s’agit pas uniquement du problème de la création de Mots de Passe robustes mais aussi et surtout de la mémorisation sécuritaire de ceux-ci, tâche si pénible que l’utilisateur lambda ne tarde pas à tomber dans le laxisme le plus complet en utilisant soit un mot de passe si faible qu’il peut être “forcé” rapidement, soit en ne comptant que sur un  Mot de Passe unique pour l’ensemble des demandes d’authentification sécurisée. Il n’est pas exagéré non plus de supposer qu’un nombre important d’internautes se fie à la combinaison potentiellement désastreuse des 2 défauts mentionnés. Devons-nous pour autant chercher le Mot de Passe «parfait»? 

.

L’Art du Mot de Passe

I) Les 2 critères pour un mot de passe

Un bon mot de passe doit empêcher un tiers d’accéder aux ressources protégées par celui-ci ET doit permettre au propriétaire de celles-ci d’y accéder…

Il doit avoir ces deux caractéristiques simultanément. On insiste généralement sur le premier critère mais le second est tout aussi important.

II) Les logiciels de génération de MdP et la mémoire des Yahous

Un mot de passe “incrackable” généré par un utilitaire de génération de MdP est une très mauvaise façon de procéder car il ne répond que rarement aux second critère.

À moins d’avoir une mémoire exceptionnelle vous aurez toutes les difficultés du monde à vous en souvenir surtout si celui-ci est nouveau ou s’il n’est pas utilisé fréquemment…

Je signale à ce propos que le mot de passe de l’utilisateur habituel ET celui du bios (si vous utilisez cette option) devraient être toujours les mêmes sinon… vous aurez deviné que dans ce cas le Mot de Passe du BIOS, très rarement utilisé, sera oublié et il ne vous restera plus comme options qu’une décennie de traitement psychanalytique, la Gestapo («Nouz avong les moyeng dé fous vaire barler!») ou les “Stations Balnéaires” de Dick Cheney…

III) méthode CCP

AMHA, la meilleure méthode pour créer un MdP respectant les 2 critères mentionnés ci-haut est la méthode CCP: Cerveau, Crayon, Papier.

Ceci et la méthode des phrases & formule que voici:

1- Il faut choisir des phrases que vous avez en mémoire mais qui ne le sont pas nécessairement dans celle des autres ou plus précisément pas autant que chez autrui.

Ce peut-être:

• des répliques de cinéma (« Atmosphère, atmosphère ! Est-ce que j’ai une gueule d’atmosphère ? » Arletty dans Hôtel du Nord de Marcel Carné)
• des passages de lectures (“… la graaaande mission civilisaaaatrice de la Fraaaance…” La France Coloniale Illustrée, Jan 1895)
• une strophe d’un poème (“Ô Grand Staline, Toi qui féconde la Terre.” Paul Éluard, poête et crapule stalinienne)
• une chanson ( “Ça arrive à ‘a manufacture, les deux yeux fArmés ben dur…” Robert Charlebois)
• un “mot d’enfant” ( “J’te fais confiance craBule.” De mon fils à l’âge de trois ans après avoir vu 100 fois le film Qui veut la peau de Roger Rabbit?)
• une remarque désobligeante du taré qui était votre patron ( “Si tu veux un cadenas t’a qu’à t’en ch*** un” M. x , PDG de …)
• la réplique assassine qui vous a conduit au divorce ( “Il vaut mieux voyager seul que mal accompagné Madame!“)

Voyez l’idée?

2- Il faut par la suite créer des formules simples pour traiter les phrases choisies pour les transformer en MdP respectant les 2 critères obligatoires.

Par exemple:
Φ1
Prendre la premier caractère de chaque mot incluant les signes de ponctuation
Φ2
prendre jusqu’à 5 caractères selon Φ1
Φ3
le dernier de ces caractères issus de  Φ2 en majusculE ou en double pour un signe de ponctuation
Φ4
insérer après le troisième caractère de Φ3 un chiffre
Φ5
Commencer la séquence des caractères issues de Φ4 par un caractère spécial tel que !”/$%?&*()#°µ}
placé entre le premier caractère et le second de Φ4

Les Φx doivent être appliquées séquentiellement au résultat de la Φ précédente.

Exemples:

A) Tiré de l’Iliade d’Homère

1- Phrase : Chante Ô Déesse la colère d’Achille
2- Φ mentionnée en exemple ci-haut
3- Étape par étape:
- Φ1 = CÔDlcd’A
- Φ2 = CÔDlc
- Φ3 = CÔDlC
- Φ4 = CÔD7lC
- Φ5 = C%ÔD7lC

Résultat: C%ÔD7lC

B) Tiré de la politique française

1- Phrase: Casse-toi sale con! (on m’a signalé que c’était “pauvre” plutôt que “sale”: tant pis!)
2- Φ mentionnée en exemple ci-haut
3- Étape par étape:
- Φ1 = C-tsc!
- Φ2 = C-tsc
- Φ3 = C-tsC
- Φ4 = C-ts9C
- Φ5 = C$-ts9C

Résultat: C$-ts9C

IV) En guise de conclusion temporaire (même si conclure est une bêtise selon Gustave Flaubert)

L’important est de créer une formule semblable à celle donnée en exemple et de s’y tenir.

Il faut mémoriser la formule en l’appliquant avec la mCCP sur plusieurs phrases tirées d’un peu partout.

Par la suite il faut choisir une phrase que vous avez déjà mémorisée depuis longtemps telle que:
“ma petite vache a mal aux pattes…”

et appliquer la formule type que vous avez choisie et pratiquée auparavant.

Ce qui est à mémoriser par la pratique selon la mCCP est la formule choisie et non les phrases que vous aviez déjà mémorisées depuis longtemps …

Pour un nombre limité de Mots de Passe, cette méthode quoique valable ne résout malheureusement pas tous les problèmes, non en raison de limitations “internes”, mais du fait de la multiplication de demandes d’authentification sur Internet.

Limitée à quelques mots de passe principalement d’usage “local” cette méthode est valable mais utilisée sans faire preuve de sens commun, elle irait au-delà de ses possibilités ne tardant pas à devenir un tel carcan que beaucoup s’empresseraient de la rejeter non sans motif.

Nous verrons dans le prochain article une autre méthode qui respecte à sa façon les 2 critères obligatoires mentionnés auparavant tout en surmontant les limitations que nous avons signalées ici.

… …………… Gentle Readers, Gentils Lecteurs … ……………

.

This night, instead of sleeping like most normal human being, I was up and running to check what’s happen to the recent Microsoft update for Windows XP, which was in an unattended installation…  And, by the way, instead of waiting for the result, I was surfing on Internet and checking the Yahoo! site called “Yahoo Answer”.  Whilst browsing in the site I found a question posted two hours ago from a user and, as usual when I know the answer, I prepare off-line, a complete answer to the asked question…

Subject & Themes / Sujet & Thèmes

The user was very confused and focus on an error message common to Windows OS in some circumstances: “The memory could not be read (or write) at the address… blah blah blah”.

But this user reveal some aspect of his [temporary?] status of InterNUT © climenole.

So, here my answer and the interesting aftermath… 

First let me give you the translation of the error description by Mr. Jean-Claude Bellamy, MS MVP, engineer at EDF and one of the most respected expert for MS Windows OS:

” This error stems from a software problem. The memory could not be read or write to mean a given moment in application running in the foreground, there is attempt to read a memory address that is “outside the boundaries” Under NT, preemptive multitasking OS, any application (user level) is assigned a memory, not shared with other applications, and conversely the application be held in this memory. If, by chance, it needs more memory, it made the request “official” system, which will award him the “rab” equally “official”. But she has no right to use any single one! ; +) It is totally forbidden to access (read or write) to the memory unauthorized.

This may occur, usually following a bug in the application (or install). The typical case occurs when using pointer (variable containing memory addresses). If the developer has failed to properly initialize the pointer to the execution the program will want to read or write to memory address “0″, which is (and because,in the case this address does not match anything).

Often, it is an irreparable error of the application (bug as already said). So contact the editor, expect a new version.

In other cases, it is a weird case, not provided by the publisher who crashed only with hardware configurations and / or very special software.” JCB

A) THE PROBLEM analysed

1) Now this is the error message you have:

“svchost.exe – Application error
the instruction at 0×46fe453a referenced memory at 0×46fe453a. the memory could not be written…”

a) The explanation given before may help you to understand what’s going wrong
but not the solution to fix that mess.

b) In the case of your problem it’s obviously a case of a “very special softwareS”:
at least one cracked software plus the “gifts” added with that kind of stuff.

2) This is the first error YOU make:

“I’ve downloaded a73 piano station w/ crack(i have no money to buy a license)”

Cracked softwares founded mainly in warez sites are one of the main sources of malwares.
When you get “free” stuff from them they also give you a “gift” with it: a dropper, a downloader
or any kind of malware to infect your system. I remark that your AntiVirus makes no warning
when you download and installed this cracked program…

Did I’m right? May be the “On Access” protection was not enabled or this is a very bad AV or there is some vulnerability in the security process…

To verify by yourself what I’m saying here I suggest you to use one of these Firefox extensions to check with trustable sources of information about the web sites you visit:

McAfee Site Advisor

WOT (Web of Trust)

As stated by Bruce Schneier, “Security is not a product, it’s a process” and the most important
factor into Internet security in the behaviour of the user not mainly the security tools used.
This is called the “Safe-Hex” and that’s the basic knowledge to avoid mess like the one we’re
talking about.

About B. Schneier

A reference for you:  Safe Hex – Safe Computing Tips
Courtesy of the alt.comp.virus newsgroup participants.

3) This is the second error YOU make:

“i left my computer open for 5 hours and when i was gone my brother messed it up…”

No Sir. You make the mess. Take your responsability please. You own this PC?
So you are the system administrator and responsible for what’s happen to it and with it.

4) This is one of the symptoms resulting from your first error:

“i used avg antivirus and hell it scanned 1672 virus infected files…”

Not one or two: 1672!

So for a cracked software you will have to loose your time and may be some of your
valuable data… What is the value of your time? How much per hour?

B) THE SOLUTIONS: hints to get out of that mess

[I guess you're using W xp using my Crystal Ball... ]

1) Boot the PC in Safe Mode

a) Stop the System Restore service

Malwares infect the SR files and makes them useless.
In the familly of malwares, the worms used also the
System Restore to restore … themselves!

Since we have no idea if it’s the case of your PC
and it’s possibly infected by at least one worm,
this is the best and reasonable decision.

From the Control Panel
System / System Restoration tab / check the option to disable SR
This will stop the SR service and delete all SR points in your system.

b) keep the system at minimal for booting:

Disable all programs running at the user startup
EXCEPT the anti-virus (and, if it’s apply, the 3 rd party Firewall)

Start / Run / msconfig
startup tab: uncheck all programs to disable them
Then reboot…

2) Check if you have an access to Internet

If you have an access to Internet:

a) update your AV and run a scan

b) make a cross check with an online AV such as:
….TrendMicro
….Works with any web browser and used Java to run the scan.

c) Use the COMBO FIX from Bleeping Computer:

….Read and follow carefully the instructions.

If you don’t have an access to Internet:

a) Use an other computer with an Internet access and:

.- download the Ultimate Boot CD for Windows
…This include many AVs: read the warning about AVs……

.- Burn the ISO file on a CD with your CD burner program or use this one:
…InfraRecorder

b) Boot the infected PC with this CD

- Check the Bios setup to be sure the CD reader is the First bootable device and the Hard disk the second…
- Boot on this CD and run the AVs
- Restart your computer at the very end of the process.

Hope this help. Let us know.

  Aftermath…

So I was a bit proud of my answer and I returned to the Yahoo Answer to reply to this user question and discover user delete the message posted a couple hours ago…

This story shows you what I mean by InterNUT:

• Post a question without giving all pertinent informations e.g. on which OS…
• Make no research by himself
• Download cracked programs as well as clicking on any link without thinking B4
• Reject his own responsability to others, in this case “his brother” (usually it’s Bill Gates)
• Have thousands infected files even with an AV installed
• Don’t wait for the answer and, I’m pretty sure of this, going to reinstall Windows from scratch loosing datas and the occasion to learn and becomes an Internaut  or, if you prefer, a cybercitizen.

Well, did I waste my time? Absolutely not: I posted this story here because I’m sure that you, my valuable readers, will learned from this and stay away of that “e-st00pidity”.

Your Comment… / Votre Commentaire…

.

Publishing tools / Outils de publication

.

[qeFr] [geFr] [χeFr]

[{p ٧ ¬p}W{p ۸ ¬p}] ٧ significare aut crepare ٧ σημασία ἤ θόρυβος …

Le problème des traces laissées sur Internet est en général très peu compris par beaucoup d’internautes. On ne compte plus les soi-disant utilitaires de protection de la confidentialité souvent gratuits, parfois payants et qui se limitent en général à supprimer certaines traces en local sur l’ordinateur personnel. Inutile de dire que tout cela est à la limite de la fausse représentation.

En mettant de côté, pour le moment, les traces locales, il serait peut-être utile de dresser un aperçu général de cette question importante pour la préservation de la vie privée.

La meilleure façon d’aborder le problème est de suivre les traces laissées à partir du moment où une adresse web, un URL, est saisie dans le champ d’adresse du navigateur…

Un URL (Uniform Ressource Locator) doit être associé à une adresse IP et la première étape (non locale) d’une connexion à un site est la requête DNS permettant de traduite l’URL en adresse IP: cette traduction est assurée par un serveur DNS, en général celui du FAI, qui, on s’en doute un peu, peut conserver dans ses journaux la trace de cette requête. Il est bien connu d’ailleurs que les principaux FAI conservent ces traces mais il est difficile de savoir pour combien de temps, quel protection ils assurent à ces informations et l’usage qu’ils en font.

Une fois cette adresse IP associée à l’URL, la connexion peut alors s’enclencher via le protocole TCP pour accéder au site mais cette connexion n’est jamais directe contrairement à ce que les apparences pourraient le laisser croire. La connexion passe par une série d’intermédiaires incluant les serveurs et routeurs du FAI mais ne s’y limitant jamais. Il est possible d’avoir un aperçu (pas toujours exact) avec un utilitaire de “Trace Route” qui montre à qui en doute que le chemin le plus direct vers un site n’est pas celui qu’on croît…

Est-ce nécessaire de préciser que ces intermédiaires peuvent tous journaliser cette connexion?

Admettons maintenant que la connexion entre le PC et le site est établie: en général tous les échanges entre ceux-ci sont EN CLAIR, c’est-à-dire, lisibles par n’importe quel intermédiaire sur la “route de connexion“…  Le chiffrement d’une connexion ne se produit en général qu’avec le protocole HTTPS par exemple lors d’un paiement en ligne, connexion chiffrée sur 128 bits… Ou encore lors de l’utilisation des protocoles POP3S et SMTP TLS pour les connexion de courriel chiffrées telles que celles avec Gmail.  Tout le reste est non-chiffré: en clair.

Enfin, le site web sur lequel le PC est connecté peut lui aussi conserver des traces de cette connexion et peut récupérer des informations de configurations normales mais aussi d’autres informations telle que le “referer” et parfois beaucoup plus en utilisant des ActiveX (sur IE) ou du javascript pour obtenir des informations plus intrusives…

Prises indépendamment les unes des autres, ces informations laissées en traces ne sont pas nécessairement des atteintes à la vie privée mais permettent le “Data Mining” c’est-à-dire, le recoupage d’information qui à la limite permettent de monter un profil identifié et associé à telle ou telles adresse IP (la vôtre) et en dernière analyse à une personne bien précise: l’internaute “X”.

De plus il est bon de savoir qu’un site web même supprimé laisse encore des traces (dont les vôtres possiblement) car Internet ne perd pas la mémoire: le Wayback Machine est là pour en témoigner. (http://www.archive.org/web/web.php).

Même votre PC a la mémoire longue. La plupart des Internautes savent qu’il est possible de supprimer l’historique web du navigateur, les témoins (cookies) et autre “Most Recent Used“.
Ce qu’ils savent moins c’est que des traces difficilement supprimables restent présentes notamment dans les fichiers Index.dat par exemple. De plus la suppression simple, l’effacement de fichiers ne fait que les supprimer logiquement au niveau des index du système d’exploitation: physiquement, ces fichiers restent présents ET récupérables pour longtemps sur le disque du PC. Les secteurs occupés par ces fichiers effacés redeviennent disponible à l’écriture lors de leur suppression logique mais la réécriture de ces secteurs n’est ni garantie ni complète et certains fichiers  “effacés” restent présents, longtemps et sont récupérables et lisibles.

Il y a quelques années la BBC avait enquêtée sur des disques usagés vendus sur eBay et avait trouvé sur plus de 50% d’entre eux des informations de nature confidentielles se rapportant à leur ancien propriétaire…

Ceci étant dit, il est préférable que les internautes soient avertis de ces caractéristiques d’Internet et prennent les mesures nécessaires pour protéger leur identité et leur vie privée.

S’il existe des gadgets techno permettant de prévenir ou de supprimer certaines des traces laissées derrières eux par les internautes, il est bon  de rappeler qu’il n’y a aucun gadget qui remplace une conduite prudente et préventive de leur part. Le “Safe-Hex” ne concerne pas seulement la “sécurité” mais aussi la confidentialité…

La citation célèbre de Bruce Schneier: “Security is not a product, it’s a process” s’applique ici aussi.

Les questions de confidentialité, d’identité et d’authentification sont sans doute en voie de devenir aussi importants dans les années à venir que les questions de “sécurité” l’étaient jusqu’à présent. à ce propos je voudrait souligner que le problème de vol d’identité n’est pas une exclusivité d’Internet mais se produit dans la majorité des cas hors d’Internet. Je mentionne ce dernier point car il est à la mode d’accuser Internet de tous les maux alors que ces maux relèvent de comportements non-exclusifs à Internet.

Si l’internaute à tête de linotte, l’interNUT existe, on trouve aussi son opposé symétrique: l’internaute parano ou “paranaute” et aucun d’entre eux n’a le moindre commencement de l’idée de ce qu’est la pratique du “Safe-Hex“.

Source: Le blogue de l’édito
Address : <http://blogues.cyberpresse.ca/edito/?p=982#respond>
Le Mercredi 24 Décembre 2008 | Mise en ligne à 10h54
Votre empreinte gênante sur le Web

Ce commentaire a été soumis au Blogue de l’Édito et reproduit ici pour le bénéfice de mes lecteurs. Ces questions seront abordées avec plus de détails ultérieurement. Merci.