Hello Gabriel Iovino,

http://referer.us/1/UdBiS3
created by our free redirection service (http://referer.us/) and it redirects to http://planetchiltern.com/phpformgenerator/use/striker/form1.html
I checked this page and it looks NOT like a phishing webpage, it’s a sign UP page, not a sign in. Then I checked “planetchiltern.com” on McAfee SiteAdvisor, it says fine.

“vn27.9hz.com” seems a phishing site according to “phishtank.com“, however, I cannot open it.

Therefor, I will not remove the url or block the site, thank you for your email and understanding.

Best regards,

======= At 2009-11-22, 05:48:49 you wrote: =======

>—–BEGIN PGP SIGNED MESSAGE—–
>Hash: SHA1
>
>Greetings,
>
>The following URL on your network has been identified as redirecting to
>a Phishing webpage:
>
>!!Warning these URL(s) may contain live malware!!
>
>[url]hxxp://referer.us/1/UdBiS3
>
>Path to this URL was seen via these links:
>
>1. hxxp://vn27.9hz.com/
>2. hxxp://referer.us/1/UdBiS3
>3. hxxp://planetchiltern.com/phpformgenerator/use/striker/form1.html
>
>Here is the Phishing email with full mail headers:
>

>> Return-Path: <bintsann@staff.pccu.edu.tw>
>> Received: from relays.pccu.edu.tw (relays.pccu.edu.tw [140.137.16.12])
>> by smtp.xxx.edu (8.14.3/8.14.3) with ESMTP id nAKNEtMW017993
>> for <xxx@xxx.xxx.edu>; Fri, 20 Nov 2009 15:14:56 -0800
>> Received: from faculty.pccu.edu.tw (faculty.pccu.edu.tw [140.137.16.1])
>> by relays.pccu.edu.tw (Postfix) with ESMTP id 915E81CAD80;
>> Sat, 21 Nov 2009 07:14:50 +0800 (CST)
>> From: “bintsann” <bintsann@staff.pccu.edu.tw>
>> Reply-To: webmaster.team0@live.com
>> Subject: System Administrator
>> Date: Sat, 21 Nov 2009 07:14:50 +0800
>> Message-Id: <20091120231450.M94072@staff.pccu.edu.tw>
>> X-Mailer: OpenWebMail 2.53
>> X-OriginatingIP: 213.255.218.244 (bintsann)
>> MIME-Version: 1.0
>> Content-Type: text/plain;
>> charset=big5
>> To: undisclosed-recipients:;
>> Content-Transfer-Encoding: quoted-printable
>> X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.xxx.edu id nAKNEuee018002
>>
>> Your mailbox has exceeded the storage limit which is 20GB as set by your=20
>> administrator; you are currently running on 20.9GB,
>>
>> You may not be able to send or receive new mail until you re-validate you=
>> r=20
>> mailbox.
>>
>> To re-validate your mailbox please click the link below:
>>
>> hxxp://vn27.9hz.com/
>>
>> If the link above doesn=A1=A6t work please copy and paste the link below =
>> to your=20
>> browser window
>>
>> hxxp://vn27.9hz.com/
>>
>> Thanks Bintsann Staff, =20
>> System Administrator

>
>Should you feel you’ve received this report in error, please let us know.
>
>On behalf of the REN-ISAC Team,
>
>Gabriel Iovino
>Principal Security Engineer, REN-ISAC
>http://www.ren-isac.net
>24×7 Watch Desk +1(317)278-6630
>—–BEGIN PGP SIGNATURE—–
>Version: GnuPG v1.4.9 (MingW32)
>Comment: Using GnuPG with Mozilla – http://enigmail.mozdev.org/
>
>iEYEARECAAYFAksItKEACgkQwqygxIz+pTvlggCgsu4RXH6LfyMbZzGqpDxMX3xl
>CqAAn0WytQ9D5×4477RMHUmyOjhnDXxJ
>=i9YP
>—–END PGP SIGNATURE—–

= = = = = = = = = = = = = = = = = = = =

@referer.us
2009-11-22

Am 20.11. findet parallel zum Münchner Piratenstammtisch eine Keysigning Party statt. Es werden GnuPG/PGP und CAcert Assurances abgearbeitet.

Wer also Lust hat kommt einfach mal vorbei. Der öffentliche Schlüssel sollte aber schon ein paar Tage vorher losgeschickt werden, damit alles gut funktioniert. Näheres auf der entsprechenden Webseite.

Link

Estos días estamos descubriendo con los compañeros de la asignatura Fonaments tecnològics del Máster de la Sociedad de la Información y el Conocimiento de la UOC cómo enviar mensajes seguros a través de un programa de encriptación. En concreto, estamos usando el GnuPG, un programa de software libre (en este post, Marta nos da más información).

Es curioso, porque me estoy leyendo la trilogía de Millenium, y en estos libros, la protagonista, Lisbeth Salander, envía sus mensajes encriptados, para mayor seguridad y con el objetivo de evitar que otras personas puedan acceder al contenido. Cuando me leí el primer libro, me preguntaba cómo funcionaría este sistema. Ahora, cuando leo que Lisbeth envía un e-mail encriptado junto con su clave pública, entiendo a qué se refiere

Creo que los correos electrónicos que envío en mi día a día no necesitan de tantas medidas de seguridad, pero nunca está de más conocer este tipo de programas. ¡Quién sabe si en el futuro tendremos que trabajar con información confidencial! En cualquier caso, es necesario que existan programas de este tipo, porque la Red no se creó pensando que fuera a ser algo multitudinario y público, y el número actual de internautas y el nivel de ciberdelincuencia existente hacen que cualquier intento de aumentar la seguridad sea más que bienvenido. ¿No os parece?

Nueva versión (rama estable) de GnuPG que se une a la 1.4.* que anunciábamos hace unos días.  Los cambios son básicamente los mismos añadiendo algunas mejoras en el manejo de tarjetas OpenPGP v2.  La versión 2 tiene una arquitectura distinta de la 1 estando dividida en pequeños módulos y es la que tiene un desarrollo más activo, las versiones 1.* se seguirán manteniendo por su utilidad en sistemas modestos.

Werner Koch ha anunciado la liberación de la versión 1.4.10 de GnuPG el programa para almacenar datos y comunicarse de forma segura. Las principales novedades son:

• Se generan claves RSA de 2048 bits por defecto. El algoritmo de resumen (hash) por defecto es ahora SHA-256 en lugar de SHA-1. Las claves DSA de 2048 bits se generan con un algoritmo de resumen de 256 bits.
• Permite usar tarjetas OpenPGP v2.
• Permite usar el algoritmo de cifrado Camellia (RFC-5581)

Instrucciones para descargar el programa en:

http://www.gnupg.org/download/

Suite au récent changement général de clés opéré au sein de Debian, j’en avais profité pour également changer ma clé et m’intéresser d’un peu plus près à Gnupg.

C’est en fouillant un peu que j’étais tombé sur le menu suivant :

Command> showpref

[ultimate] (1). Carl Chenet <chaica@ohmytux.com>

Cipher: AES256, AES192, AES, CAST5, 3DES

Digest: SHA1, SHA256, RIPEMD160

Compression: ZLIB, BZIP2, ZIP, Uncompressed

Features: MDC, Keyserver no-modify

Hmm, AES, mais c’est un algorithme de chiffrement symétrique ça.

En fait après lecture de la documentation de Gnupg, il s’avère que pour chaque chiffrement, Gnupg chiffre les données avec un algorithme de chiffrement symétrique, ici l’AES256, à l’aide d’une clé partagée entre l’émetteur et le receveur. Cette clé ne sera utilisée que pour cet échange (on l’appelle aussi clé de session). Et c’est cette clé de session qui sera chiffrée avec un algorithme de chiffrement asymétrique avant d’être communiquée au receveur, ledit chiffrement asymétrique réalisé à l’aide de la clé publique du receveur. Le mode de chiffrement adopté par Gnupg est donc hybride, mélange chiffrement symétrique et asymétrique.

Ce qui nous est assuré ainsi, c’est qu’au pire l’algorithme de chiffrement asymétrique (le plus faible des deux selon la documentation Gnupg) compromis, seul le message actuel serait compromis, l’attaquant étant obligé de redéchiffrer une nouvelle clé de session pour accéder à un nouveau message. On est bien sûr déjà dans un cas extrême.

Documentation de Gnupg sur le sujet

It’s a good thing that the NSA, like so many government agencies, is so incompetent, or there’d be nothing left of our freedom.

For more detailed info on the NSA after 9/11, see James Bamford’s book, The Shadow Factory.

Here’s how to protect yourself:

• E-mail: PGP or GnuPG
• Files / Disks / Partitions: PGP or TrueCrypt
• Voice (VoIP): Zfone

The NSA is still listening to you.

This summer, on a remote stretch of desert in central Utah, the National Security Agency will begin work on a massive, 1 million-square-foot data warehouse. Costing more than $1.5 billion, the highly secret facility is designed to house upward of trillions of intercepted phone calls, e-mail messages, Internet searches and other communications intercepted by the agency as part of its expansive eavesdropping operations. The NSA is also completing work on another data warehouse, this one in San Antonio, Texas, which will be nearly the size of the Alamodome.

The need for such extraordinary data storage capacity stems in part from the Bush administration’s decision to open the NSA’s surveillance floodgates following the 9/11 attacks. According to a recently released Inspectors General report, some of the NSA’s operations — such as spying on American citizens without warrants — were so questionable, if not illegal, that they nearly caused the resignations of the most senior officials of both the FBI and the Justice Department.

Last July, many of those surveillance techniques were codified into law as part of the Foreign Intelligence Surveillance Amendments Act (FAA). In fact, according to the Inspectors General report, “this legislation gave the government even broader authority to intercept international communications” than the warrantless surveillance operations had. Yet despite this increased power, congressional oversight committees have recently discovered that the agency has been over-collecting on the domestic communications of Americans, thus even exceeding the excessive reach granted them by the FAA.

Email-Kontent können gehackt werden – wenn nicht bei einem selbst, dann eventuell bei Kommunikationspartnern. Die beste Methode um sich davor zu schützen ist es Emails zu verschlüsseln. Der neueste Twitter-Hack zeigt das sehr deutlich. Selbst in großen Unternehmen,(=Organisationen) und Behörden ist es offenbar noch unüblich, Emails zu verschlüsseln. Gerade dort aber wäre es sehr einfach.

Gerade in Organisationen kann man da vieles organisieren, wie z.B.:

1. Für jeden Mitarbeiter schon bei Eintritt in der Organisation eine Verschlüsselung organisieren, z.B. mit GnuPrivacyGuard oder S/MIME.
2. Evt. wichtige internen Emails im Unternehmen zusätzlich zum Empfänger auch für eine zentrale Instanz  verschlüsseln, so dass im Zweifelsfall interne Emails des Unternehmens wieder gelesen werden können. Klassischer weise also Emails an mehrere Empfänger. Ansonsten besteht die Gefahr, das wichtige Informationen für immer verloren gehen.
3. Grundsätzlich natürlich dazu ermuntern oder durch Schulungen und Installationshilfe die Verwendung der Verschlüsselung sicherstellen. Bei Thunderbird+Enigmail kann man z.B. pro Empfänger festlegen, das dieser IMMER verschlüsselte Emails bekommt.

Diese Vorgehensweise bedeutet dann, das bei einem geknackten Email-Konto viele wichtige Informationen nicht lesbar sind. Ein Angreifer kann zwar ohne weiteres die verschlüsselten Emails im Quellcode lesen – aber nicht im Klartext, dazu fehlen im zwei Komponenten:

1. Der private Schlüssel des Kontoinhabers
2. Das Schlüsselpasswort

Nur wer beides kennt, bzw hat kann die Emails auch entschlüsseln. Dies ist keine 100%ige Sicherheit – kann aber viele gängige Attacken verhindern.

Und denkt daran, das selbst wenn euer Konto sicher ist: Das von euren Kontakten eventuell nicht. Daher: Versucht in euren Organisationen Verschlüsselung zentral zu etablieren – und auch in lockeren Zusammenhängen und im privaten Kreis macht das Sinn. Zum einen zeigt der Fall Twitter, dass auch im Privaten viele Details versteckt sind, die nicht veröffentlicht gehören. Und übrigens deckt sich die Verwendung von Verschlüsselung nicht mit der Verwendung von Webmail. Denn den privaten Schlüssel legt man natürlich nicht auf einem Server ab. Man kann den privaten Schlüssel auch auf einem USB-Stick am eigenen Schlüsselbund mit sich führen um ggf. von unterwegs auch mal von fremden Rechnern aus Emails zu entschlüsseln. Dieser USB-Stick sollte aber nicht für andere Daten benutzt werden. Auch hier ist Vorsicht angesagt.

Zum Schluss noch: Man kann Sicherheit beliebig weit fassen. Ich vertrete die Auffassung, das es bei Email-Verschlüsselung vor allem wichtig ist, das Leute überhaupt damit anfangen. D.h. man sollte nicht zu viele wenn schon, denn schon-Regeln aufstellen. Weil dann die Leute es weiterhin gar nicht benutzen. Leute sind vermehrt bereit ihre  Emails zu verschlüsseln, wenn der Aufwand absehbar ist. Man kann dann gerne einige Tips geben – und je mehr sie wissen, desto besser gehen sie mit der Technologie um. Aber bitte baut keine Mauern um die Verschlüsselung auf! Was im Moment das wichtigste ist, ist das möglichst viele Leute Verschlüsselung nutzen.

Emails signieren, ist noch mal ein eigenes Thema, das ich nichzt so wesentlich finde. Es hat seinen Nutzen, erfordert aber ein anderes Vorgehen und andere Begründungen. Daher nicht an dieser Stelle.

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. 

The NSA is hoovering your e-mail and they ain’t gonna stop, law or no law. That’s what they do, that’s all they do, and Congress can suck it up. Congress makes a lot of noise, but in the end, they want your e-mail, too.

If you care about your e-mail privacy, download and use PGP or GnuPG. Fuck the spies.

E-Mail Surveillance Renews Concerns in Congress.

The National Security Agency is facing renewed scrutiny over the extent of its domestic surveillance program, with critics in Congress saying its recent intercepts of the private telephone calls and e-mail messages of Americans are broader than previously acknowledged, current and former officials said.

The agency’s monitoring of domestic e-mail messages, in particular, has posed longstanding legal and logistical difficulties, the officials said.

Since April, when it was disclosed that the intercepts of some private communications of Americans went beyond legal limits in late 2008 and early 2009, several Congressional committees have been investigating. Those inquiries have led to concerns in Congress about the agency’s ability to collect and read domestic e-mail messages of Americans on a widespread basis, officials said. Supporting that conclusion is the account of a former N.S.A. analyst who, in a series of interviews, described being trained in 2005 for a program in which the agency routinely examined large volumes of Americans’ e-mail messages without court warrants. Two intelligence officials confirmed that the program was still in operation.

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)

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. 

Continuando con la serie de entradas dedicadas a extensiones de Firefox, hoy vamos a hablar de FireGPG. Soy consciente de que en este caso se trata de una opinión muy parcial pero, para mí, esta extensión está también entre las más importantes de Firefox. De hecho, es uno de los principales motivos para que use Firefox en cualquier sistema operativo.

¿Y para qué sirve FireGPG? Bien, simplemente -que no es poco- permite integrar el software de cifrado GnuPG en Firefox, mediante la implementación de una serie de interfaces gráficas en el navegador.

La primera interfaz, y más genérica, integra las funcionalidades básicas de GnuPG en un menú del navegador.

FireGPG integra GnuPG en Firefox

Entre sus opciones encontramos: firma y verificación, cifrado y descifrado, editor de texto para realizar las operaciones básicas anteriores, importación y exportación de claves, así como un administrador de claves gráfico bastante completo.

Además, la extensión integra detección automática de bloques PGP en cualquier página web; así como la capacidad de trabajar con cualquier bloque de texto seleccionado en el navegador.

Pero, quizá, la más interesante de sus funcionalidades sea la integración automática con el gestor de correo web de Gmail.

Integración de FireGPG en Gmail

Esta integración nos permite llevar a cabo todas las operaciones básicas de GnuPG, de forma automática, y desde la propia interfaz de Gmail. Adicionalmente, también integra la automatización de las tareas de descifrado y verificación de correos entrantes, ofreciendo la información de forma gráfica y amigable.

La única pega que tiene esta integración con Gmail es que, dado que obviamente no se trata de un desarrollo oficial de Google, a veces deja de funcionar sin previo aviso, cuando cambian algún aspecto de la implementación de la interfaz de Gmail. En dicho caso, hay que esperar a que los desarrolladores de FireGPG modifiquen su código para adaptarse a dichos cambios, y publiquen una nueva release de la extensión. Por suerte, las actualizaciones automáticas de Firefox se encargan de evitarnos la molestia de estar continuamente comprobando si se ha liberado una nueva versión.

Thunderbird is a mail user agent developed by Mozilla. GnuPG is an encryption program (free software) that uses the standard OpenPGP. This standard is based on encryption using a private and public key. The private key is used to decrypt the data while the public key is used to encrypt the data.

The Thunderbird add-on Enigmail, provides an “back-end” interface to GnuPG so the user can use Thunderbird to encrypt/decrypt mail. After installing Enigmail, generate a keypair. This will create a public and private key for the current account. The public key is meant to be distributed so other people can send mail encrypted to you. The private key however, is important NOT to distribute. Since it is used to encrypt the messages sent to you with your public key. The public key is usually uploaded to a keyserver.

It’s possible to search for public keys on the keyservers and add public keys into a local list and configure Thunderbird to encrypt all messages by default (supposing the public key to the person in question is added into your key list). Both Thunderbird, GnuPG and Enigmail, are very useful indeed : )

For more information about GnuPG and Enigmail:
http://www.gnupg.org/
http://enigmail.mozdev.org/home/index.php

E-Mails werden im Internet als Klartext versandt. Für jeden mit fortgeschrittenen technischen Kenntnissen ist es also relativ einfach möglich, fremde E-Mails zu lesen oder zu manipulieren (spoofen). Dass auch der Staat gerne mitlesen möchte, darf auch nicht aus den Augen verloren werden und ist meiner Meinung nach ebenfalls ein Misstrauensgrund gegenüber E-Mail. Zwar werden mittlerweile manchmal verschlüsselte Verbindungen (z.B. über SSL) genutzt, doch bleiben die Daten weiterhin unsicher, da sie selbst unverschlüsselt bleiben.
Hier setzt GPG an. Dies ist eine Abkürzung für GNU Privacy Guard und beschreibt eine Methode zur Verschlüsselung der E-Mails bereits auf dem Rechner, die erst wieder beim Empfänger entschlüsselt werden. Dadurch kann die Integrität (= Echtheit) garantiert werden, ebenso ist dies natürlich ein Leseschutz. Doch wie funktioniert dies? Zuerst ein bisschen Theorie, um die Technik verstehen und richtig anwenden zu können:

Gegeben sind der Absender Alice und der Empfänger Bob. Jeder von ihnen hat einen privaten und einen öffentlichen Schlüssel. Den privaten kennt nur der Besitzer und er ist durch ein Passwort geschützt, den öffentlichen verteilt er unter seinen Freunden und bekommt von diesen die jeweiligen.
Alice möchte also Bob eine vertrauliche Nachricht zukommen lassen. Sie schreibt eine E-Mail und verschlüsselt sie mit ihrem privaten Schlüssel und dem öffentlichen Schlüssel von Bob. Dazu muss sie ihren privaten Schlüssel per Passwort freigeben, den öffentlichen von Bob hat sie ebenfalls abgespeichert. Der Computer erzeugt nun einen Text, der unsinnig erscheint. Erst wenn Bob diese E-Mail bekommt und mit seinem privaten Schlüssel öffnet, ist wieder Klartext zu lesen. Alice kann den Text nicht wiederherstellen, dies kann nur Bob, dessen privater Schlüssel als einziger E-Mails entschlüsseln kann, die mit seinem öffentlichen Schlüssel (und natürlich dem privaten des Senders) in Geheimtext umgewandelt wurde.

Jeder benötigt also diese zwei Schlüssel und diese müssen natürlich schwer bzw. in einem nicht zu vertretenden Zeitaufwand (entspricht ein paar Millionen Jahren) zu knacken sein. Mithilfe der freien Software GPG kann nun jeder diese Schlüssel erstellen, verwalten und verteilen.
Als Frontend zur Schlüsselverwaltung unter KDE verwende ich KGpg, das unter anderem auch noch Dateien verschlüsseln kann. Für GMail-Nutzer gibt es das Firefox-Addon FireGPG, das über die Weboberfläche E-mails ver- und entschlüsselbar macht.

Nun habe ich hier noch ein kleines Tutorial für KGpg erstellt, bei anderen Clients sieht dies natürlich prinzipiell gleich aus. Nutzern von gpg direkt in der Konsole seien die manpages empfohlen, hierauf kann und will ich an dieser Stelle nicht weiter eingehen. Nutzern von Windows empfehle ich GPG4win.

Als erstes muss man sich ein neues Schlüsselpaar (privat + öffentlich) über “Schlüssel / Schlüsselpaar generieren” erstellen lassen. Darauf folgt ein Formular, bei dem man die geforderten Eingaben machen muss (Anfängern sei empfohlen, die Schlüsselgröße und den Algorithmus voreingestellt zu lassen):

Neuen Schlüssel erstellen

Als nächstes muss man ein Passwort für den privaten Schlüssel festlegen (welches natürlich sicher sein sollte), dann muss man eine Weile warten bis die Schlüssel errechnet werden. Es wird ein weiteres Fenster angezeigt, in dem Details des erzeugten Schlüssels ersichtlich werden und wo man die Möglichkeit hat, einen Schlüssel später für ungültig zu erklären. Dies geschieht dann mittels eines Sperrzertifikats, welches nun erstellt werden kann.

Schlüsselerstellung abgeschlossen

Die Schlüssel sind jetzt soweit fertig und können benutzt werden. Um sie zu verteilen, muss man den öffentlichen Schlüssel über “Schlüssel / Öffentliche Schlüssel exportieren” natürlich exportieren. Das kann entweder in eine Datei, die Zwischenablage, in eine E-Mail oder einen Schlüsselserver geschehen. Ein Schlüsselserver ist eine zentrale Verwaltungsstelle für öffentliche Schlüssel, wo man diese bekommt, wenn der Kommunikationspartner diesen nicht persönlich überbringen kann. Hier sollte man aber vorsichtig sein (Spamgefahr!) und Schlüsselserver nur begrenzt benutzen. Eine Datei hingegen kann jederzeit persönlich versandt werden und ist daher auch mein persönlicher Favorit.

Export der öffentlichen Schlüssels

Der Import funktioniert über “Schlüssel / Schlüssel importieren”. Importierte Schlüssel werden erst einmal als nicht vertrauenswürdig eingestuft. Dies kann man ändern, indem man sich über einen sicheren (sicher im Sinne von fälschungssicher) Kanal, z.B. eine Telefonverbindung, vom Inhaber des importierten Schlüssels den Fingerprint vorlesen lässt. Dies ist eine Prüfsumme und wenn die vorgetragene mit der angezeigten übereinstimmt, ist der Schlüssel tatsächlich echt und kann als vertrauenswürdig eingestuft werden. Diesen Fingerprint kann man sich auch über die Schlüsseleigenschaften ansehen, welche über einen Rechtsklick auf den betreffenden Schlüssel erreicht werden.

Signieren des fremden Schlüssels

Noch ein paar Hinweise zu FireGPG. Wer das Plugin im Firefox installiert und für GMail aktiviert hat, kann man Mails über neue Links im Fenster nun auch verschlüsseln, signieren etc. Dies nutze ich meist, wenn ich Mails verschlüssele und kann es empfehlen, so sieht dies dann aus:

neue Links zum Versenden vom Mails

Nun kann man also sicher kommunizieren. Für weitere Tutorials etc. bitte die weiterführenden Links lesen bzw. Google befragen. Mit GnuPG kann man Mails sowohl verschlüsseln als auch signieren, also beweisen, dass die Mail nicht verändert wurde und vom Absender stammt, doch die Beschreibung hierzu würde den Rahmen sprengen. Mit ein bisschen Übung kann man aber relativ einfach selbst herausfinden wie dies funktioniert

Meinen persönlichen public-Key kann man über eine Mail an samuel[dot]brack[plus]getgpgkey[at]gmail[dot]com bekommen. Die Kennung des Schlüssels lautet C8E07A0E

Weiterführende Links:
Deutsche GnuPG-Anleitung (Kai Raven)
Wikibooks GnuPG: GnuPG benutzen
Enigmail – Plugin für Thunderbird und Dokumentation

1. GnuPG

2. SheldonShirts

3. Threadless

Über die letzten Jahre hab ich aktiv Thunderbird eingesetzt. Die Gründe waren die recht gute IMAP Kompatibilität und die Verfügbarkeit auf den verschieden Betriebssystemen die ich im Einsatz hatte.

Da ich momentan fast ausschließlich Mac OS einsetze war die Versuchung groß mal nach Jahren wieder Apple Mail zu benutzen. Und siehe da: es gefällt auf Anhieb. Die Integration in die anderen Anwendungen wie z.B. das Adressbuch ist einfach großartig und es sind viele angenehme Kleinigkeiten die einem das Ganze schmackhaft machen.

Zwei Dinge allerdings fehlten mir von Anfang an: Das fehlen einer PGP-Unterstützung und (es mag eine wie eine Kleinigkeit wirken) farbige Labels zum markieren von Mails.

Für die PGP Geschichte war schnell eine Lösung gefunden. GPG Mail nennt sich das ganze und ist ein schickes Frontend für gnupg. http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html

Die Label Sache war etwas schwieriger. Man kann zwar als Option bei Regeln bestimmen das gewisse Mails farbig Markiert werden sollen, man kann dies aber nicht nach Gutdünken durch anklicken der Mails machen.

Aber auch hier gibts Abhilfe und diesmal in Form eines AppleScripts. Und so gehts:

• Apple Scripts hier runterladen: http://www.macupdate.com/info.php/id/18372

• Den Ordner mit den Skripten nach /Library/Scripts/Mail Scripts kopieren
• Wenn nicht schon vorhanden das AppleScript Icon oben rechts in der Leiste aktivieren. (AppleScript Utility.app starten und das Häkchen bei “Skriptmenü in der Menüleiste anzeigen” setzen
• Eine Mail markieren -> Auf die Schriftrolle klicken -> Mail Scripts -> Labels -> Farbe auswählen