Ubuntu-fr

bebnet

[METHODE] - Echange de mails chiffrés/signés Thunderbird<->Outlook

Echange de mails chiffrés/signés S/MIME entre Thunderbird/Ubuntu et Outlook/MS-Windows

J’ai été confronté à la problématique suivante : échanger des mails chiffrés/signés S/MIME depuis mon PC personnel (Ubuntu 12.04 Thunderbird 24) avec des correspondants utilisant MS-Outlook en environnement Exchange. Si cela peut aider, je sais pas trop où poster ça, je pense qu'ici c'est pas mal...

Le problème :
• Depuis chez moi, j’envoie des mails signés et chiffrés au destinataire en question qui est sous MS/Outlook/Exchange => tout est OK, cela fonctionne parfaitement, il voit bien ma signature valide, peut déchiffrer, etc, tout roule.
• Par contre, quand lui m’envoie des mails chiffrés depuis son Outlook, depuis sa société sous MS-Exchange, signés, je reçois un mail inexploitable avec une pièce jointe « winmail.dat », plus une alerte de signature invalide pour mail corrompu. Par contre, dans sa boite d’envoi, le mail apparaît bien signé et chiffré.

Après moultes pérégrinations, j’ai fini par comprendre, et vous livre ci-dessous le résultat du pourquoi du comment, plus un mode d’emploi pour contourner ce p*** de truc dû à Exchange

L’envoi de mails signés/chiffrés avec Outlook (et exchange) pose en effet quelques soucis :
• Le format RTF utilisé par Outlook par défaut entraîne l’utilisation d’un format propriétaire d’encapsulation des pièces jointes par Outlook : l’horrible TNEF.
• Le résultat est que le destinataire reçoit le mail, avec une pièce jointe nommée « winmail.dat », inutilisable en l’état.
• Il est possible de momentanément désactiver l’utilisation de TNEF en spécifiant explicitement que les mails doivent être formatés en HTML ou en texte brut. Mais cela ne marche pas toujours (ce serait trop beau)
• Il est également possible, au niveau du PC Windows lui-même, de désactiver cette fonctionnalité à l’aide de la clé de registre ci-dessous (marche pour Outlook 2007 à 2013) :3

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences]
"DisableTNEF"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Preferences]
"DisableTNEF"=dword:00000001
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Preferences]
"DisableTNEF"=dword:00000001

Faites un copier-coller de ces lignes dans un fichier texte, nommez-le TRUC.REG, par exemple, et double-cliquez dessus pour importer les valeurs.
Mais là encore, cela ne fonctionnera que si on n’utilise pas Exchange derrière.

Car même si cette fonctionnalité est désactivée au niveau du poste client, l’utilisation d’Exchange va poser problème, TNEF ou pas :
• L’ajout d’un Disclaimer par Exchange est susceptible d’altérer le mail, invalidant alors la signature du mail original (puisque modifié par l’ajout du Disclaimer, après l’envoi).
• Exchange va ‘encapsuler’ le mail avant le disclaimer, en utilisant… TNEF
• Les clés publiques incorporées dans le mail pendant la signature/le chiffrement seront encapsulées par Exchange par TNEF.
• L’utilisation de certaines fonctions spécifiques à Outlook (boutons de vote, …) va déclencher l’utilisation de TNEF par exchange.

Le destinataire (qui n’utilise pas Outlook) recevra donc un mail, avec le Disclaimer, et une pièce jointe ‘winmail.dat’.

Idéalement, il faut donc désactiver l’utilisation de TNEF AUSSI au niveau de Exchange. Trois scénarios :
1) Le Sysadmin qui s’occupe du serveur Exchange est un pote, conscient du problème, et procèdera avec un plaisir et un entrain certain à la désactivation de ce format de daube.
2) C’est vous le Sysadmin, et vous ne savez pas comment faire. C’est simple :
Il est possible, sous exchange, de créer des domaines de destination sur lesquels TNEF sera désactivé.
    A) Via l’utilisation de powershell
        Pour obtenir la liste ou de tous les domains où TNEF est désactivé :
            Get-RemoteDomain | Where {$_.TNEFEnabled -eq $false}
        Pour créer un nouveau domaine distant :
            New-RemoteDomain -DomainName nom_de_domaine.com -Name Nom_Domaine
        Pour activer TNEF pour les destinataires dans Nom_Domaine :
            Set-RemoteDomain -Identity Nom_Domaine -TNEFEnabled $true
        Pour désactiver TNEF:
            Set-RemoteDomain -Identity Nom_Domaine -TNEFEnabled $false

    B) Ou en utilisant la console de Exchange. (Organization Configuration > Hub Transport > Remote Domains)

3) Vous n’êtes pas Sysadmin, ce dernier, en plus, ne veut rien savoir. Ou vous n’avez pas la main sur le serveur Exchange. Ou vous êtes un utilisateur normal, tout simplement. Il faut donc une autre astuce : voir plus bas

• A NOTER que la désactivation de TNEF empêchera les destinataires externes de recevoir des assignements de tâches/boutons de votes, ou autres choses propres à Outlook. Mais comme personne n’utilise ces truc là… non ?
• Certains vont me faire remarquer qu’il existe pour notre environnement favori des plug-ins / softs qui permettent de lire les fichiers winmail.dat. J’en ai essayé avec Thunderbird, et ça fonctionne pas, et comme je n’avais pas envie de me creuser pour modifier MON environnement à cause des daubes de la firme de Redmond, j’ai trouvé autre chose :

-*- Méthode pour les utilisateurs ‘classiques’ ; qui sont obligés d’utiliser Outlook et Exchange, et qui n’ont la main sur rien.
On va supposer que fonctionnellement, votre Outlook est prêt à envoyer des mails signés/chiffrés. Vous disposez d’un certificat S/MIME (X509), Outlook est configuré pour l’utiliser, et dans votre liste de contacts, votre destinataire est renseigné, et sont certificat public est renseigné (parce que vous avez reçu un mail signé numériquement de sa part, par exemple. Dans ce cas, en ajoutant l’expéditeur aux contacts [Clic-droit sur le nom de l’expéditeur après avoir ouvert le mail, puis ‘ajouter aux contacts’] provoquera l’importation automatique du certificat contenu dans sa signature numérique.)
Il va falloir procéder en deux temps, en envoyant le mail DEUX FOIS. (exemple avec Outlook 2010)

• Rédigez votre mail, en HTML ou en Texte Brut (Menu ‘Format du Texte’), joignez-y les pièces éventuelles. Cliquez sur Options, et cliquez sur Signer et/ou Chiffrer. Envoyez le mail. Celui-ci va  bien sûr être altéré par le disclaimer ajouté par exchange, sans compter l’utilisation de TNET. MAIS, dans le dossier Eléments envoyés, nous auront notre mail signé et chiffré, et surtout intègre.
• Ce premier mail pourra être détruit par le destinataire, car inutilisable (winmail.dat, altération, etc.)
• Composez un second mail (en HTML ou texte brut, toujours), là aussi à destination de votre correspondant. Glissez-y le premier mail récupéré dans votre dossier ‘Eléments envoyés’.  Vous avez donc un mail avec comme pièce jointe le premier mail précédemment envoyé. Envoyez-le NON SIGNE et NON CHIFFRE (le mail joint lui est déjà signé/chiffré).
• La destinataire recevra un second mail, avec en pièce jointe le ‘vrai’ mail non altéré qu’il pourra ouvrir, et qui sera bien reconnu comme un mail signé/chiffré/intègre. Le second mail sert en fait d’enveloppe au premier.

Le premier envoi est nécessaire car le chiffrement du mail se fait avec le certificat du destinataire. La copie récupérée dans Eléments envoyés est donc bonne.

Pseudo supprimé

Re : [METHODE] - Echange de mails chiffrés/signés Thunderbird<->Outlook

Désactiver TNEF au niveau serveur, devrait suffire
et utiliser au niveau client le format Text Brut, HTML

De mémoire, le chiffrement fort, et signature forte, s'effectuent par le MUA, qui soumet la requête en DATA au MTA,
contrairement à la connexion forte, dont tu ne parles pas, mais où l'accès au MTA est conditionné par ( contexte équivalent Postfix /permit_tls_clients valide /x509 client ).

Dernière modification par Titouan (Le 25/03/2014, à 16:32)