Paramétrage du fichier de log du serveur DNS Bind

Official Ubuntu circle with wordmark. Replace ...
Image via Wikipedia

Bind est le plus utilisé des serveurs DNS du monde. Bind est bien entendu disponible sous Ubuntu et son installation se fait sans problème. Par contre si on veut paramétrer Bind pour écrire dans un fichier de log pour par exemple monitorer les accès au serveur DNS, il faut savoir que Ubuntu 10.10 intègre le logiciel AppArmor qui est une barrière de sécurité qui empêche les applications d’accéder aux ressources dont elle n’a pas besoin. c’est comme un “firewall” pour les processus afin de bloquer les accés aux ressources.
Ainsi la configuration de AppArmor pour Bind se trouve dans /etc/apparmor.d/usr.sbin.named et on y voit que AppArmor donne accès au répertoire /var/log/named donc il faut utiliser ce répertoire pour les log.
Dans bind le paramétrage des log se fait dans /etc/bind/named.conf.local:
logging {
channel "querylog" { file "/var/log/named/query.log"; print-time yes; };
category queries { querylog; };
category lame-servers { null; };
};

Cette configuration est suffissante pour que le plugin Bind9 de Munin trace de jolis graphiques sur l’usage de Bind.

La parade au filtrage d’internet

L’actualité récente avec les événements des les pays du Maghreb nous montre que les dictatures peuvent recourir au filtrage d’internet afin d’éviter que des informations ne sortent des frontières. Généralement en entend par filtrage le fait de ne pas avoir accès à certains sites comme en Chine où les contenus jugés non appropriés par le régime sont bloqués et donc rendus inaccessibles aux chinois. Avec l’avènement des réseaux sociaux, l’accès à un site extérieur sert également à diffuser de l’information. Ce mode de fonctionnement en multi-paire brouille la donne.

Ainsi en Tunisie ou en Égypte les blocage des sites de réseaux sociaux sont un moyen pour juguler l’expression populaire et l’information qui parvient de ces pays. Cela montre la faiblesse des réseaux sociaux centralisé car il suffit alors de bloquer un seul site pour réussir le blocage. Regardons les différentes options pour contrer ce filtrage qui rappelons le s’il le faut est en toute rigueur contraire au principe d’internet.

La mise en place d’un filtrage la plus simple est basée sur l’adresse DNS de tel ou tel service de réseau social. Ainsi en rentrant l’url du site, l’internaute ne peut accéder au site recherché. La parade est tout aussi simple que la mesure de filtrage. Soit on utilise un serveur DNS hors de la zone d’influence du pays liberticide, soit en utilise l’adresse IP du site et non pas son nom de domaine (exemples). La première solution est toutefois limité par le fait que le serveur DNS lui même peut être bloqué ce qui fera préférer la deuxième solution.

Une étape supplémentaire dans le filtrage est de bloquer l’adresse IP . Dans ce cas le salut passe par l’utilisation d’un proxy hors de la zone d’influence du pays liberticide. Néanmoins le proxy lui-même pourra être bloqué tout comme l’usage  du serveur DNS étranger vue au paragraphe précédent.

L’étape suivante pour réussir à contrer le filtrage quand à la fois les serveurs DNS locaux applique un filtre et que les serveur DNS étrangers sont bloqués, ainsi que les proxy étrangers, est de passer inaperçu. C’est alors que la force des réseaux sociaux ouverts et décentralisés prend toute sa valeur. En effet bloquer Twitter est simple et radical alors que bloquer Status.Net est tout simplement impossible car il faudrait recenser tous les serveur status.net du monde et comme tout le monde peut héberger un serveur Status.Net, cela reviendrait à appliquer non plus un filtre basé sur un liste noire mais sur un liste blanche.

Or peu de pays peuvent se permettre un internet filtré sur liste blanche car ce ne serait plus internet. Or l’usage d’internet est devenu “vital” pour l’économie et combien de régime peuvent recréer un internet local en restant isolé du reste de l’internet mondial ? A part la Chine sans doute aucun, il sera intéressant de voir combien de temps pourra durer le blocus d’internet en Égypte.

L’usage de solution décentralisée pour propager l’information est une moyen d’en permettre la libre circulation.

Réception de mail crypté S/MIME avec Javamail-crypto

Crypto stub
Image via Wikipedia

Dans le billet précédent je montrais comment envoyer un mail S/MIME, ce billet traite de l’opération inverse. Comment réceptionner un mail crypté et signé en S/MIME ?

L’idée est de reprendre la méthode de lecture du certificat publique du signataire pour vérifier la signature du mail mais il faut auparavant décrypter le mail reçu. En effet l’expéditeur signe le message puis le crypte donc on doit décrypter puis vérifier la signature une fois que le mail est devenu lisible.
Voici le pseudo-code

MimeMessage m = retrieveMessageFromMailBox();
m = decryptMessage(m);
checkSignature(m);

La lecture du message dans la boite mail ne pose pas de grande difficulté mais le résultat est un mail avec comme content-type la valeur application/pkcs7-mime. Malheureusement le code utilitaire SMIMEEncryptionUtils de javamail-crypto (qui décrypte un message contient un oubli qui l’empêche de gérer les mails cryptés contenant des PJ comme c’est le cas dans un mail signé. En effet le résultat du décryptage doit être un mail avec le content-type valant multipart/signed ou application/pkcs7-mime ou bien application/x-pkcs7-mime, sinon le mail n’est pas détecté comme un mail signé. Or le méthode qui décrypter decryptMessage.decryptMessage()oublie malheureusement d’invoquer saveChange()sur le message. Aussi le le content-type n’est pas mis à jour. So do it yourself !

Ensuite il suffit d’appeler la méthode utilitaire de vérification de signature SMIMEEncryptionUtils.checkSignature() pour finir la partie réception d’un S/MIME. Il est a noté que le mail signé par SMIMEEncryptionUtils.signeMessage() est de type multipart/signed ce qui signifie que le mail est constitué de 2 partie :

  1. le contenu message original avant signature
  2. la signature portant sur le message original précédent

Il faut en tenir compte pour extraire les informations du message original. C’est-à-dire que le contenu du mail décrypté que l’on obtient par MimeMessage.getContent() pourra être itéré mais on ne s’intéressera qu’à sa première partie. Cette première partie obtenue par Multipart.getBodyPart() sera soit considéré comme  le contenu du corps du message original avant signature si son content-type est text/plain mais si le message original avait déjà des pièces-jointes le content-type sera multipart/mixed et il faudra alors itérer sur la première partie. La forme du message original dépend du client mail utilisé pour créer le message original avant signature et cryptage.

Encrytage de mail avec JavaMail-Crypto et BouncyCastle

Icon from Nuvola icon theme for KDE 3.x.
Image via Wikipedia

Javamail-crypto est une API peu récente puisque le jar est estampillé juin 2006. Cepedant l’usage de cette API simplifie grandemant la vie du programmeur puisque pourvu que le message en clair, la session mail, ainsi que la clé soient fournis, il suffit de faire

EncryptionUtils smimeUtils = null;
String type = EncryptionManager.SMIME;
smimeUtils = EncryptionManager.getEncryptionUtils(type);
smimeSignedMsg = smimeUtils.encryptMessage(session, mmessage,
smimeKey);

Lorsque l’on doit envoyer un mail crypté à la norme S/MIME, on utilise la clé publique du destinataire. On ne peut pas utiliser Javamail-crypto et Bouncycastle comme on le ferait dans le cas de la signature comme dans l’exemple suivant:

char[] smimePw = new String("mot de passe")
.toCharArray();
EncryptionKeyManager smimeKeyMgr = smimeUtils.createKeyManager();
InputStream privKeyIS = null:
smimeKeyMgr.loadPrivateKeystore(privKeyIS, smimePw);
smimeKey = smimeKeyMgr.getPrivateKey("cle privee signature",
smimePw);

En effet bien que l’on puisse charger les clé publiques, l’API s’attend à lire en entrée un fichier PKCS12. Or ce fichier doit aussi contenir la clé privée ce que le destinataire du mail ne va jamais nous fournir. Il se bornera à nous fournir un certificat contenant sa clé publique.

Heureusement que l’API de cryptage prend une clé java.security.Key , il nous suffit de créer un tel objet. Pour cela il ne suffit par de créer un objet implémentant l’interface Key car le code de SMIMEEncryptionUtils.encryptMessage() fait un transtypage:

BouncySMIMEEncryptionKey bKey = (BouncySMIMEEncryptionKey) key;

Nous devons donc créer de toute pièce une instance de BouncySMIMEEncryptionKey.Cela est assez facile car en regardant le code on voit qu’il nous suffit, pour encryptage de mail, de fixer le certificat dans un objet BouncySMIMEEncryptionKey.

Voici le code complet pour lire la clé publique dans un fichier PEM et encrypter un mail:

EncryptionUtils smimeUtils = null;
BouncySMIMEEncryptionKey smimeKey = null;
String type = EncryptionManager.SMIME;
smimeUtils = EncryptionManager.getEncryptionUtils(type);
PEMReader reader = new PEMReader(new InputStreamReader(inputStremoOnThePEM));
X509CertificateObject cert = (X509CertificateObject) reader.readObject();
smimeKey = new BouncySMIMEEncryptionKey();
smimeKey.setCertificate(cert);
MimeMessage smimeSignedMsg = smimeUtils.encryptMessage(session, mmessage,smimeKey);

Sécuriser ses courriels en S/MIME avec Gnome Evolution

Category:WikiProject Cryptography participants
Image via Wikipedia

On entend par sécurisation de courriel le fait de garantir l’intégrité et la confidentialité du contenu. L’intégrité du contenu est assurée quand le message reçu est authentique c’est-à-dire qu’il est bien celui que l’expéditeur a envoyé. La confidentialité est assurée quand seul le destinataire peut lire le contenu du message.

La sécurisation des mails se fait par signature du contenu puis cryptage de l’ensemble (contenu original + signature). La signature et le cryptage se font avec un algorithme cryptographique dont la sécurité est basée sur le secret de la clé et la difficulté à deviner la clé. L’algorithme que nous allons utiliser est RSA qui utilise en fait une paire de 2 clés liées entre elles, l’une privée et l’autre publique. La difficulté à deviner la clé publique se base sur l’impossibilité (à ce jour) de trouver un algorithme indépendant de la taille de la clé privée pour calculer le logarithme discret. En réalité il n’y a pas d’algorithme de calcul du logarithme discret si bien qu’il faut tester toutes les solutions (clés privées hypotètiques) et voir si ça marche. A l’heure d’aujourd’hui une clé RSA de 2048 bits est jugées sûre. En effet cela correspond à un ensemble de plus de 3*10^500 clés hypothètiques.

La norme S/MIME spécifie comment former le mail pour y inclure la signature electronique et comment encapsuler la forme cryptée dans un mail (qui n’est qu’un texte). S/MIME indique également comment utiliser les certificats x509. X509 est une norme pour authentifier des clés publiques. Le certificat garantit donc qu’une clé publique donnée correspond bien à une clé privée appartenant à une personne donnée. Cette garantie est donnée par la caution d’une autorité dite de confiance qui se charge contre rémunération de vérifier l’authenticité de la clé publique.

Pour générer la paire de clés RSA on utilise openssl disponible sous toutes les distributions linux. A ce jour Ubuntu 10.10 propose la version 0.9.8o. Ce n’est pas la version la plus à jour que l’ont peut trouver sur www.openssl.org.

~$ openssl version
OpenSSL 0.9.8o 01 Jun 2010

Pour information le N900 dispose aussi d’openssl en version 0.9.8n
~ $ openssl version
OpenSSL 0.9.8n 24 Mar 2010

Commençons par générer une clé privée RSA en entrant la commande suivante dans un terminal:

sudo  openssl genrsa -des3 -out privkey.pem 2048

Cela va créer le fichier privkey.pem contenant une clé RSA cryptée en triple DES avec le mot de passe renseigné.

Attention: le mot de passe demandé permet de crypter la clé afin de la protéger si un intrus accède au fichier. NE PAS OUBLIER CE MOT DE PASSE.

Changez les droits d’accès à la clé privée pour être le seul à pouvoir y accéder. Remplacer le user et le groupe par votre user.

sudo chmod 400 privkey.pem
sudo chown thierry:thierry privkey.pem

Nous disposons à ce stade d’une clé privée RSA avec laquelle nous pouvons signer des mail pour authentifier nos envois et décrypter des mails pour s’assurer que personne n’espionne les mails que l’on reçoit.

Pour ce faire il nous faut générer la clé publique associée à notre clé privée. La clé publique est stockée dans un certificat x509 qui devrait être signé par une authorité de confiance qui atteste que c’est bien notre clé publique RSA. Cependant Pour pouvons faire un certificat signé avec notre propre clé privée. Dans un terminal rentrons la commande suivante:

sudo openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Cela va créer un certificat x509 valide pendant 3 ans, contenant des informations pour nous identifier (pays, ville, organisagtion, nom, email) ainsi que la clé publique RSA. Ce certificat prétend que la personne identifiée possède la clé privée associée à la clé publique presente dans le certificat. Comme ce certificat est signé par nous même, la preuve de l’identité n’est pas garantie puisque l’on peut faire un certificat au nom d’une autre personne. Par contre on a la garantie cryhptographique que celui qui a fait le certificat possède la clé privée associée à la clé publique à cause de la signature RSA du certificat. Cette garantie est suffisante dans un cadre privé et nous pouvons toujours publier le certificat sur un site web à notre nom afin de lui donner un cachet officiel.

Le fichier cacert.pem est public mais ne doit pas être altéré sinon au mieux le certificat sera faux à cause de sa signature RSA devenue non valide et au pire non authentique dans la cas d’un certificat remplacé par un autre dont on ne possède pas la clé privé (dans ce cas on est victime d’usurpation d’identité).

Modifions les droits du fichier de certificat pour le rendre accessible à tous en lecture seule. Remplacez le user par votre user.

sudo chown thierry:thierry cacert.perm
sudo chmod 444 cacert.pem

Ce certificat doit être importé dans Evolution en temps que certificat d’autorité de sorte les mails signés avec notre clé privée soit considéré valide d’une part parce que la signature correspond au message et d’autre par parce que le certificat est signé par une autorité de certification reconnu dans Evolution. La manipulation suivante doit être faite chez tous les destinataires de nos mail signé.

Utilisons la commande suivante pour nous envoyé un mail signé. Rentrer le mot de passe de la clé privée puis le contenu du mail puis finir par CTRL-D
thierry@jesus:~/crypto$ sudo openssl smime -sign -signer cacert.pem -inkey privkey.pem -text -from xxxxx@xxxxx.xxx -to xxxxx@xxxxx.xxx -subject "Signed message" | sendmail xxxxxx@xxxxxxx.xxx
Enter pass phrase for privkey.pem:
ce message est trés important
thierry@jesus:~/crypto$

En ouvrant le mail dans Evolution on doit voir le contenu du mail mais une alerte nous prévient que la signature n’est pas valide.

En effet bien que la signature soit correcte car le certificat est envoyé dans le mail et Evolution constate que la signature correspond bien au contenu,  le certificat n’est pas authentifié. Cliquez sur l’icône  et une fenêtre indique que le certificat n’est pas sûr:

Pour y remédier il faut ajouter le certificat dans la liste des certificat de confiance (Certificate Authority). Pour cela dans Evolution aller dans le menu Edition > Préférences > Certficats > Autorités pour importer le fichier cacert.pem. Cette manipulation doit être faite chez tous les destinataires de nos mails signé (si on avait fait signé notre certificat par une autorité reconnue cela n’aurait pas été nécessaire mais payant).

Attention: un certificat est public et aucun mot de passe n’est demandé mais le coffre fort contenu les certificats de Gnome Evolution est protégé par mot de passe. Si un message suivant apparait Enter the password for `NSS User Private Key and Certificate Services` il s’agit d’un autre mot de passe que celui de notre clé privée.

Cocher toutes les cases pour simplement dire que nous faisons confiance à ce certificat pour tout même si seule la case courrier électronique est nécessaire.

En revenant sur le mail on s’aperçoit que maintenant Evolution nous indique que la signature est correcte et valide.

Pour que nos destinataires vérifient notre signature il faut leur fournir notre certificat et qu’ils l’importent comme autorité de confiance.

Notre clé RSA nous a permi de signer un mail et maintenant nous allons tester la réception de mail crypté. Pour cela on va s’envoyé un mail crypté avec notre clé publique contenue dans le certificat (accessible à tous ceux qui veulent crypter un message à notre intention)

Nous reprenons la commande précédente (signature de message) et y ajoutons le cryptage. Le mot de passe de la clé privée est demandé à cause de la partie signature (optionnelle dans cette exemple) mais remarquons que la partie cryptage ne fait intervenir que le certificat public. Terminez par CTRL-D.

thierry@jesus:~/crypto$ sudo openssl smime -sign -signer cacert.pem -inkey privkey.pem -text | sudo openssl smime -encrypt -from xxxxx@xxxxx.xxx -to xxxxx@xxxxxxx.xxx -subject "Signed and encrypted message" cacert.pem | sendmail xxxxxxx@xxxxxxx.xxx
Enter pass phrase for privkey.pem:
Attention ce message est crypté à destination de Thierry Bressure. Le contenu est signé par Thierry Bressure.

Le message réceptionné par Gnome Evolution est bien crypté comme le montre la capture suivante :

C’est ce qui ce passe quand une personne qui n’a pas la clé de décryptage ouvre le mail.

Pour que nous puissions ouvrir le mail crypté à notre intention, nous devons ajouter notre certificat privé dans Evolution. Le certificat privé est la concaténation du certificat public (cacert.pem) et de la clé privée, le tout dans un format spécial dit PKCS12 (.p12).

Pour créer le fichier pkcs12 rentrer dans un terminal:

thierry@jesus:~/crypto$ sudo openssl pkcs12 -export -in cacert.pem -out cacert.p12 -inkey privkey.pem -name "Thierry Bressure"

Le mot de passe de la clé privée est demandé pour décrypter la clé privée et un second mot de passe est demandé pour protéger la clé privée dans le fichier pkcs12.

Ce certificat ne doit pas être divulgué. Modifions les droit sur ce fichier cacert.p12 en faisant

sudo chown thierry:thierry cacert.p12
chmod 400 cacert.p12

Nous allons maintenant importer ce certificat privé dans Evolution. Dans Edition > Préférences> Certificats > Vos certificats cliquer sur importer.

Le mot de passe du coffre fort des certificats de Gnome est requis ainsi que le mot de passe du fichier pkcs12.

En retournant sur le mail on s’aperçoit que Evolution arrive maintenant à le décrypter grâce à notre certificat privé.

A ce stade nous avons montré que nos destinataires sont capable de vérifier notre signature et que nous somme capable de décrypter les mails qui nous sont destinés. Pour signer nos mails et crypter nos mails avec Evolution il suffit de choisir notre certificat privé dans Edition> Préférences > Compte de messageries > “sélectionner un compte” > Sécurité > Secure MIME à la fois pour la signature et le cryptage.

Attention pour crypter un message pour un destinataire il faut au préalable avoir reçu un mail signé (contenant son certificat public) de la part de cette personne.

Sécuriser ses courriels en S/MIME avec Gnome Evolution

Category:WikiProject Cryptography participants
Image via Wikipedia

On entend par sécurisation de courriel le fait de garantir l’intégrité et la confidentialité du contenu. L’intégrité du contenu est assurée quand le message reçu est authentique c’est-à-dire qu’il est bien celui que l’expéditeur a envoyé. La confidentialité est assurée quand seul le destinataire peut lire le contenu du message.

La sécurisation des mails se fait par signature du contenu puis cryptage de l’ensemble (contenu original + signature). La signature et le cryptage se font avec un algorithme cryptographique dont la sécurité est basée sur le secret de la clé et la difficulté à deviner la clé. L’algorithme que nous allons utiliser est RSA qui utilise en fait une paire de 2 clés liées entre elles, l’une privée et l’autre publique. La difficulté à deviner la clé publique se base sur l’impossibilité (à ce jour) de trouver un algorithme indépendant de la taille de la clé privée pour calculer le logarithme discret. En réalité il n’y a pas d’algorithme de calcul du logarithme discret si bien qu’il faut tester toutes les solutions (clés privées hypotètiques) et voir si ça marche. A l’heure d’aujourd’hui une clé RSA de 2048 bits est jugées sûre. En effet cela correspond à un ensemble de plus de 3*10^500 clés hypothètiques.

La norme S/MIME spécifie comment former le mail pour y inclure la signature electronique et comment encapsuler la forme cryptée dans un mail (qui n’est qu’un texte). S/MIME indique également comment utiliser les certificats x509. X509 est une norme pour authentifier des clés publiques. Le certificat garantit donc qu’une clé publique donnée correspond bien à une clé privée appartenant à une personne donnée. Cette garantie est donnée par la caution d’une autorité dite de confiance qui se charge contre rémunération de vérifier l’authenticité de la clé publique.

Pour générer la paire de clés RSA on utilise openssl disponible sous toutes les distributions linux. A ce jour Ubuntu 10.10 propose la version 0.9.8o. Ce n’est pas la version la plus à jour que l’ont peut trouver sur www.openssl.org.

~$ openssl version
OpenSSL 0.9.8o 01 Jun 2010

Pour information le N900 dispose aussi d’openssl en version 0.9.8n
~ $ openssl version
OpenSSL 0.9.8n 24 Mar 2010

Commençons par générer une clé privée RSA en entrant la commande suivante dans un terminal:


Cela va créer le fichier privkey.pem contenant une clé RSA cryptée en triple DES avec le mot de passe renseigné.

Attention: le mot de passe demandé permet de crypter la clé afin de la protéger si un intrus accède au fichier. NE PAS OUBLIER CE MOT DE PASSE.

Changez les droits d’accès à la clé privée pour être le seul à pouvoir y accéder. Remplacer le user et le groupe par votre user.

sudo chmod 400 privkey.pem
sudo chown thierry:thierry privkey.pem

Nous disposons à ce stade d’une clé privée RSA avec laquelle nous pouvons signer des mail pour authentifier nos envois et décrypter des mails pour s’assurer que personne n’espionne les mails que l’on reçoit.

Pour ce faire il nous faut générer la clé publique associée à notre clé privée. La clé publique est stockée dans un certificat x509 qui devrait être signé par une authorité de confiance qui atteste que c’est bien notre clé publique RSA. Cependant Pour pouvons faire un certificat signé avec notre propre clé privée. Dans un terminal rentrons la commande suivante:

sudo openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Cela va créer un certificat x509 valide pendant 3 ans, contenant des informations pour nous identifier (pays, ville, organisagtion, nom, email) ainsi que la clé publique RSA. Ce certificat prétend que la personne identifiée possède la clé privée associée à la clé publique presente dans le certificat. Comme ce certificat est signé par nous même, la preuve de l’identité n’est pas garantie puisque l’on peut faire un certificat au nom d’une autre personne. Par contre on a la garantie cryhptographique que celui qui a fait le certificat possède la clé privée associée à la clé publique à cause de la signature RSA du certificat. Cette garantie est suffisante dans un cadre privé et nous pouvons toujours publier le certificat sur un site web à notre nom afin de lui donner un cachet officiel.

Le fichier cacert.pem est public mais ne doit pas être altéré sinon au mieux le certificat sera faux à cause de sa signature RSA devenue non valide et au pire non authentique dans la cas d’un certificat remplacé par un autre dont on ne possède pas la clé privé (dans ce cas on est victime d’usurpation d’identité).

Modifions les droits du fichier de certificat pour le rendre accessible à tous en lecture seule. Remplacez le user par votre user.

sudo chown thierry:thierry cacert.perm
sudo chmod 444 cacert.pem

Ce certificat doit être importé dans Evolution en temps que certificat d’autorité de sorte les mails signés avec notre clé privée soit considéré valide d’une part parce que la signature correspond au message et d’autre par parce que le certificat est signé par une autorité de certification reconnu dans Evolution. La manipulation suivante doit être faite chez tous les destinataires de nos mail signé.

Utilisons la commande suivante pour nous envoyé un mail signé. Rentrer le mot de passe de la clé privée puis le contenu du mail puis finir par CTRL-D
thierry@jesus:~/crypto$ sudo openssl smime -sign -signer cacert.pem -inkey privkey.pem -text -from xxxxx@xxxxx.xxx -to xxxxx@xxxxx.xxx -subject "Signed message" | sendmail xxxxxx@xxxxxxx.xxx
Enter pass phrase for privkey.pem:
ce message est trés important
thierry@jesus:~/crypto$

En ouvrant le mail dans Evolution on doit voir le contenu du mail mais une alerte nous prévient que la signature n’est pas valide.

En effet bien que la signature soit correcte car le certificat est envoyé dans le mail et Evolution constate que la signature correspond bien au contenu,  le certificat n’est pas authentifié. Cliquez sur l’icône  et une fenêtre indique que le certificat n’est pas sûr:

Pour y remédier il faut ajouter le certificat dans la liste des certificat de confiance (Certificate Authority). Pour cela dans Evolution aller dans le menu Edition > Préférences > Certficats > Autorités pour importer le fichier cacert.pem. Cette manipulation doit être faite chez tous les destinataires de nos mails signé (si on avait fait signé notre certificat par une autorité reconnue cela n’aurait pas été nécessaire mais payant).

Attention: un certificat est public et aucun mot de passe n’est demandé mais le coffre fort contenu les certificats de Gnome Evolution est protégé par mot de passe. Si un message suivant apparait Enter the password for `NSS User Private Key and Certificate Services` il s’agit d’un autre mot de passe que celui de notre clé privée.

Cocher toutes les cases pour simplement dire que nous faisons confiance à ce certificat pour tout même si seule la case courrier électronique est nécessaire.

En revenant sur le mail on s’aperçoit que maintenant Evolution nous indique que la signature est correcte et valide.

Pour que nos destinataires vérifient notre signature il faut leur fournir notre certificat et qu’ils l’importent comme autorité de confiance.

Notre clé RSA nous a permi de signer un mail et maintenant nous allons tester la réception de mail crypté. Pour cela on va s’envoyé un mail crypté avec notre clé publique contenue dans le certificat (accessible à tous ceux qui veulent crypter un message à notre intention)

Nous reprenons la commande précédente (signature de message) et y ajoutons le cryptage. Le mot de passe de la clé privée est demandé à cause de la partie signature (optionnelle dans cette exemple) mais remarquons que la partie cryptage ne fait intervenir que le certificat public. Terminez par CTRL-D.

thierry@jesus:~/crypto$ sudo openssl smime -sign -signer cacert.pem -inkey privkey.pem -text | sudo openssl smime -encrypt -from xxxxx@xxxxx.xxx -to xxxxx@xxxxxxx.xxx -subject "Signed and encrypted message" cacert.pem | sendmail xxxxxxx@xxxxxxx.xxx
Enter pass phrase for privkey.pem:
Attention ce message est crypté à destination de Thierry Bressure. Le contenu est signé par Thierry Bressure.

Le message réceptionné par Gnome Evolution est bien crypté comme le montre la capture suivante :

C’est ce qui ce passe quand une personne qui n’a pas la clé de décryptage ouvre le mail.

Pour que nous puissions ouvrir le mail crypté à notre intention, nous devons ajouter notre certificat privé dans Evolution. Le certificat privé est la concaténation du certificat public (cacert.pem) et de la clé privée, le tout dans un format spécial dit PKCS12 (.p12).

Pour créer le fichier pkcs12 rentrer dans un terminal:

thierry@jesus:~/crypto$ sudo openssl pkcs12 -export -in cacert.pem -out cacert.p12 -inkey privkey.pem -name "Thierry Bressure"

Le mot de passe de la clé privée est demandé pour décrypter la clé privée et un second mot de passe est demandé pour protéger la clé privée dans le fichier pkcs12.

Ce certificat ne doit pas être divulgué. Modifions les droit sur ce fichier cacert.p12 en faisant

sudo chown thierry:thierry cacert.p12
chmod 400 cacert.p12

Nous allons maintenant importer ce certificat privé dans Evolution. Dans Edition > Préférences> Certificats > Vos certificats cliquer sur importer.

Le mot de passe du coffre fort des certificats de Gnome est requis ainsi que le mot de passe du fichier pkcs12.

En retournant sur le mail on s’aperçoit que Evolution arrive maintenant à le décrypter grâce à notre certificat privé.

A ce stade nous avons montré que nos destinataires sont capable de vérifier notre signature et que nous somme capable de décrypter les mails qui nous sont destinés. Pour signer nos mails et crypter nos mails avec Evolution il suffit de choisir notre certificat privé dans Edition> Préférences > Compte de messageries > “sélectionner un compte” > Sécurité > Secure MIME à la fois pour la signature et le cryptage.

Attention pour crypter un message pour un destinataire il faut au préalable avoir reçu un mail signé (contenant son certificat public) de la part de cette personne.

Envoi de mail sécurisé en Java

Category:WikiProject Cryptography participants

Nous sommes dans le cadre du standard S/MIME avec 2 clés: une pour la signature et l’autre pour le cryptage.

Principe général

L’expéditeur veut être sûr que son message ne sera pas modifié pendant le transfert (internet n’est pas sûr…) Et que seul le destinataire pourra lire le message.

On recherche donc l’authenticité et la confidentialité.

  1. Signature : l’expéditeur signe le message avec sa clé privée.
  2. Cryptage : après avoir signé le message, l’expéditeur le crypte avec la clé publique du destinataire.

Outils

Java SE contient désormais les extension cryptographique mais l’API optionnelle JavaMail ne prend pas en charge la sécurité. Le programmeur doit donc transformer le message en clair en le passant en “multipart” pour y insérer la signature puis crypter les différentes parties et gérer les entêtes du mail pour indiquer au destinataire qu’il s’agit d’un mail crypté et signé.

JavaMail

La version courante 1.4.3 permet d’envoyer un mail en se connectant à un serveur SMTP. Nous utilisons en également les capacités de JavaMail à gérer les pièces jointes ainsi que les entêtes du mail.

Javamail-crypto

Cette librairie permet d’ajouter à JavaMail la prise en charge du S/MIME. JavaMail-Crypto s’appuie sur 2 founisseurs d’implémentation: BouncyCastle pour SMIME et Cryptix pour PGP. Seul le premier sera utilisé dans notre cas.

OpenSSL

OpenSSL est une librairie et des outils pour créer des clés et certificats cryptographique et les manipuler dans un contexte pratique (chriffrage…). Disponible sur tous les Unix il est également utilisable avec Cygwin (pour ceux qui sont du côté obscure…)

Protection de Status.net contre le spam

The logo of reCAPTCHA
Image via Wikipedia

GNUsocial semble être limité aujourd’hui à la fonction de microblog offerte par status.net sur lequel il est basé. Par défaut la configuration est très permissive et le serveur sera rapidement victime de spam. Pour se prémunir de ces actions il faut:

  1. activer le captcha lors de la création de compte
  2. utiliser le plugin Blacklist

Captcha
D’abord il faut aller sur le site //www.google.com/recaptcha pour obtenir des clés gratuitement. Puis aller dans le fichier config.php pour activer le plugin recaptcha:

addPlugin('recaptcha', array('private_key' => 'xxxxxx',
'public_key' => 'yyyyyy',
'display_errors' => true));

Pour tester, aller sur la page de création de compte. Si en face du champ captcha il n’y a pas d’image, vérifier que dans le fichier config.php le paramètre suivant:

// cette valeur doit être celle renseignée lors de la
// création du compte recaptcha
$config['site']['server'] = 'www.monserveur.com';

Blacklist
Ce plugin permet à l’administrateur d’interdire des nom d’utilisateur et des url de site dans les profiles. Les robots utilisent souvent des comptes de type newsXXXXX et les spammeurs tentent de saturer le site avec la même url (néfaste…).
Dans il fichier config.php

addPlugin('Blacklist');