[Q] Quels sont les standards de messagerie sécurisée ?

Chercher Google avec les mots: pop3s, imaps, starttls, https

GuS

Christian wrote:

Bonjour,

Voila mon problème.
Une entrerprise Entreprise A souhaite offrir à ses salariés un moyen
de communiquer de manière sécurisée par email, entre eux, mais
surtout avec des utilisateurs quelconques sur internet.
La solution de messagerie de l'Entreprise A est Lotus Domino V6, avec
le client Web iNotes v6 (le client lourd Notes n'est pas déployé sur
les postes)
Quels sont les standards de messagerie sécurisée ?
Les besoins sont la confidentialité, la signature, et la
non-répudiation . Ces standards peuvent t il être implémenté dans le
cas général d'une messagerie en mode Webmail ? et dasn le cas
particulier du client Web de Lotus : iNotes ?
Quid de l'utilisation de messagerie sécurisée entre deux client iNotes
connecté au serveur Domino de l'EntrepriseA ?
Peux-t il y avoir interopérabilité avec un client de messagerie tout
a fait standard, su internet ? Autrement dit un utilisateur de
l'Entreprise1 uttilisant iNotes peut-il communiquer de manière
sécurisée avec un utilisateur ayant un serveur de messagerie
SMTP/POP3 et un client quelconque en utilisant des standards ?

Merci par avance de vos répones,

Christian

GnuPG devrait répondre à vos besoins, voir ma page dédiée.

--
Michel Nallino aka WinTerMiNator
http://www.chez.com/winterminator
(Internet et sécurité: comment surfer en paix)
http://www.gnupgwin.fr.st
(GnuPG pour Windows)
Adresse e-mail: http://www.cerbermail.com/?vdU5HHs5WG

On Wed, 25 Feb 2004 21:48:39 +0100, "WinTerMiNator" <me@privacy.net>
wrote:

Christian wrote:

Bonjour,

Voila mon problème.
Une entrerprise Entreprise A souhaite offrir à ses salariés un moyen
de communiquer de manière sécurisée par email, entre eux, mais
surtout avec des utilisateurs quelconques sur internet.
...

Christian

GnuPG devrait répondre à vos besoins, voir ma page dédiée.

GnuPGP (successeur de PGP) est en effet LE standard d'echanges
sécurisés... testé depuis des années car connu depuis des années et code
source ouvert (contrairement aux produits comerciaux).
Avec interface graphique depuis des années maintenant aussi.

Et le site de Winterminator est en français et clair...

According to Christian <xtian_news@hotmail.com>:

Une entrerprise Entreprise A souhaite offrir à ses salariés un moyen de
communiquer de manière sécurisée par email, entre eux, mais surtout avec des
utilisateurs quelconques sur internet.
La solution de messagerie de l'Entreprise A est Lotus Domino V6, avec le
client Web iNotes v6 (le client lourd Notes n'est pas déployé sur les
postes)
Quels sont les standards de messagerie sécurisée ?

Il y a grosso-modo deux moyens de faire de la "messagerie sécurisée" :


1. Faire un système à base de pages web, avec consultation via HTTPS
(autrement dit : SSL). C'est sécurisé en ce sens que les courriers sont
transférés entre le serveur central et les machines des utilisateurs
à l'intérieur de tuyaux SSL, avec donc un chiffrement et des contrôle
d'intégrité décents.

Les avantages de cette méthode sont un déploiement simple (rien à
installer sur les postes clients, car on suppose que ces postes ont déjà
un browser web capable de faire du SSL [Internet Explorer, Netscape,
Mozilla...]) et la possibilité d'appliquer certains traitements de masse
(par exemple, appliquer un antivirus sur tous les mails).

En revanche, il y a pas mal de défauts :
-- tout le système est centralisé sur le serveur web, qui ne doit pas
tomber en panne ;
-- le serveur central contient tous les courriers en clair (donc l'admin
peut tout lire -- c'est d'ailleurs pour ça qu'on peut appliquer un
antivirus général) ;
-- le système n'est pas compatible avec le reste du monde, et si des
extérieurs veulent échanger des courriers selon ce système, ils doivent
obtenir un accès au serveur central, et s'y connecter.

On peut fournir un accès "IMAP sur SSL" pour que les clients puissent
utiliser un client mail classique (genre "Outlook Express").

Le fait que le serveur central ait accès à tout et soit seul maître de
la sécurité fait que pour la non-répudiation à valeur juridique, c'est
rapé.



2. Faire un système où la cryptographie (chiffrement, signature...) est
appliquée directement sur les postes clients. Ça suppose un logiciel
client capable de faire ce genre de choses. Il y a deux standards :

-- OpenPGP : dérivé du PGP originel, maintenant une vraie norme puisqu'il
existe une autre implémentation interopérable (GnuPG).

-- S/MIME : la norme de l'ISO, utilisant les certificats X.509. Les
logiciels de mail "standards du marché" (Outlook, Outlook Express,
Netscape Messenger, Lotus Notes 6...) le gèrent nativement.

Dans les deux cas, les courriers sont envoyés ensuite en tant que
courriers tout-à-fait classiques, et si on ne fait que de la signature,
les courriers seront lisibles par des logiciels ne connaissant pas
ces standards (mais, bien sûr, les signatures ne seront alors pas
vérifiées).

Dans le cas de Domino avec le client iNotes, il faudrait voir en détail
si la cryptographie est appliquée par le client, ou déléguée au
serveur.


S/MIME a sur OpenPGP les avantages suivants :

-- Le support est déjà intégré dans les outils de courrier les plus
courants (PGP s'installe facilement, mais rien ne s'installe aussi
facilement que ce qui est déjà installé).

-- Le système de PKI est celui des certificats X.509 : il est
hiérarchique et centralisé, ce qui a tendance à mieux correspondre aux
besoins des entreprises. Le système de PKI d'OpenPGP ne fonctionne bien
qu'avec des communautés restreintes ; chaque utilisateur y gère sa
propre politique de sécurité, indépendamment de la volonté hiérarchique ;
le système n'est vraiment "sûr" que si chaque utilisateur comprend ce
qui se passe du point de vue sécurité (condition complètement irréaliste).

D'un autre côté, X.509 c'est gros, les PKI sont des choses complexes
et OpenPGP semble souvent bien attrayant parce que beaucoup moins
cher. Mais c'est parce qu'il en fournit beaucoup moins : ce qui est
cher dans une PKI hiérarchique, c'est la mise en place des procédures
de certification (identification physique des gens, surtout). Comme
d'habitude, quand on ne paye rien, on en a exactement pour son argent.


--Thomas Pornin

Thomas Pornin wrote:

D'un autre côté, X.509 c'est gros, les PKI sont des choses complexes
et OpenPGP semble souvent bien attrayant parce que beaucoup moins
cher.

On peut faire du X.509 sans PKI et sans rien payer avec un résultat
équivalent à OpenPGP.

Les instructions pour utiliser openssl pour se tirer sa CA se trouvent
facilement, et si on veut faire simple et/ou sans avertissement à
l'utilisation, on peut aussi aller chercher un certificat email gratuit
reconnu par Outlook ici :
https://secure.comodo.net/products/frontpage?area=SecureEmailCertificate

Dans fr.misc.cryptologie, Thomas Pornin nous disait:

D'un autre côté, X.509 c'est gros, les PKI sont des choses complexes
et OpenPGP semble souvent bien attrayant parce que beaucoup moins
cher. Mais c'est parce qu'il en fournit beaucoup moins : ce qui est
cher dans une PKI hiérarchique, c'est la mise en place des procédures
de certification (identification physique des gens, surtout). Comme
d'habitude, quand on ne paye rien, on en a exactement pour son argent.

J'ai plus confiance dans mes procédures de vérifications des
identités PGP que dans une certification hiérarchique venue de je ne
sais quelle entreprise. Je ne comprends pas la dernière phrase: la
confiance s'achète ?

Laurent Fousse wrote:

J'ai plus confiance dans mes procédures de vérifications des
identités PGP que dans une certification hiérarchique venue de je ne
sais quelle entreprise.

Surtout venant d'entreprises comme Verisign. Confiance. Humm..

According to Laurent Fousse <nobbs@fousse.info>:

J'ai plus confiance dans mes procédures de vérifications des identités
PGP que dans une certification hiérarchique venue de je ne sais quelle
entreprise.

X.509 est conçu pour un système hiérarchique qui permet un modèle de
confiance plus adapté à un environnement organisationnel ; ça ne veut
pas dire que toute façon de gérer X.509 est bonne.

Supposons un instant que l'entreprise "Acme Ltd." possède une division
commerciale et une division production. Le modèle hiérarchique de PKI,
c'est que la direction générale contrôle la CA, qui signe des sous-CA
pour les directions commerciales et de production, et ses sous-CA
émettent des certificats pour leurs employés respectifs. C'est la
structure naturelle de PKI pour une entreprise parce que :

-- Les communications sont réalisées par des employés, pas des
personnes. Quand le commercial Jules Dupont envoie un courrier à Pierre
Martin de la R&D, leurs noms et prénoms n'ont pas d'importance : ce qui
compte, c'est leurs fonctions respectives au sein de l'entreprise. Ce
n'est pas spécifiquement à Pierre Martin que Jules Dupont veut causer,
mais au "chef du service R&D". Si Pierre Martin a la grippe ce jour-là,
c'est son second qui doit recevoir le courrier.

-- Les procédures d'identification que peut appliquer Jules Dupont
sont sur les personnes. Il peut vérifier la carte d'identité de Pierre
Martin, mais ça ne lui prouve pas que Pierre Martin est bien chef de
la R&D, ni par ailleurs que la clé publique que lui présente Pierre
Martin appartient bien à la R&D (ça pourrait être une clé personnelle,
inutilisable par le remplaçant de Pierre Martin le jour où Pierre Martin
oublie de bien regarder à gauche et à droite avant de traverser la rue).
Ultimement, c'est la direction de la division production qui définit qui
est chef du service R&D. C'est donc cette direction qui doit "signer"
la clé publique du chef de service R&D. De même, c'est la direction
générale qui définit précisément qui est le directeur de la division
production, et qui doit donc signer le certificat correspondant.

-- Que Jules Dupont ait des doutes sur la procédure, globalement, on
s'en balance. Dans la société "Acme", ce qui compte, ce ne sont pas
les états d'âmes de Jules mais la confiance que _la société_ peut
avoir dans une clé publique. Si Jules Dupont se fait refiler une clé
publique truandée et que son courrier arrive au final entre les mains
des concurrents d'Acme, ce n'est pas Jules Dupont qui va en souffrir
le plus, mais Acme. Ceci va de pair avec le fait que les courriers
professionnels de Jules Dupont ne sont pas envoyés par le _citoyen_
Jules Dupont mais par le _directeur des ventes_ Jules Dupont.

-- Un concept majeur pour les organisations multi-personnelles, c'est
la prise de risque et son estimation. Comme il y a des humains dans la
boucle, il y a forcément un moyen de contourner les systèmes de sécurité
(ne serait-ce qu'en kidnappant Jules Dupont et en le faisant parler
au Penthotal). Si les procédures de sécurité sont bien planifiées et
analysées, ces risques peuvent être chiffrés et l'organisation peut
prendre des assurances adéquates. Mais si on laisse une partie de la
procédure entre les mains des utilisateurs eux-mêmes, à charge pour
eux de faire de bonnes authentifications, alors l'estimation du risque
part dans le décor. Et le montant des polices d'assurance atteint la
stratosphère.



Bien évidemment, dans la pratique de X.509 de tous les jours, les CA
sont des entreprises indépendantes (genre Verisign ou Thawte) qui
appliquent une procédure d'authentification qui leur est propre et qui
ne correspond pas au modèle ci-dessus : essentiellement, ils vérifient
l'identité physique, ce qui d'ailleurs n'est pas fondamentalement
leur boulot, puisque l'état-civil est défini, in fine, par l'État, et
transmis via les "certificats" que l'État délivre depuis des décennies,
et qu'on appelle habituellement "cartes d'identité".

Par ailleurs, les procédures appliquées par ces CA indépendantes sont
consignées et encadrées juridiquement dans des "Certification Policy
Statements", documents indigestes de quelques centaines de pages qui
expliquent, en gros et en résumé, que quoi qu'il advienne, la CA n'est
responsable de rien et inattaquable. Les assureurs font la gueule.



Le _format_ OpenPGP permet de faire, techniquement, tout ce que fait
X.509 (il s'agit juste de signer des messages et des clés, au fond).
Mais les implémentations d'OpenPGP suivent le modèle OpenPGP, où
tout est conçu pour que chaque utilisateur fabrique et maintienne sa
propre politique de sécurité et sa propre confiance. C'est pourquoi
les entreprises qui utilisent PGP (il y en a) commencent par définir
leurs propres procédures internes d'utilisation de PGP, procédures
qui consistent en gros à refabriquer une PKI comme décrit ci-dessus.
Évidemment, ça suppose une solide formation des employés, et ça coûte
cher. Les logiciels faisant du X.509 (par exemple Outlook Express ou
Netscape Messenger) appliquent en standard des vérifications adaptées au
modèle hiérarchique, nécessitant ainsi beaucoup moins de formation pour
les employés, donc coûtant moins cher.



Il est vrai que les implémentations existantes de X.509 ont tendance à
être d'une qualité douteuse. La faute en incombe en partie au standard
lui-même, qui est d'une complexité qui confine à l'absurde. Mais c'est
un autre débat et ça s'améliore (de ce point de vue, l'implémentation de
Microsoft dans les tous derniers "Service Packs" est nettement meilleure
que celle d'il y a trois ans).

Je ne comprends pas la dernière phrase: la confiance s'achète ?

La confiance est le fruit d'une procédure. Une procédure ça a un coût
(en temps, en argent, en polices d'assurance). Une procédure cheap a
tendance à fournir une confiance cheap.


--Thomas Pornin

pornin@nerim.net (Thomas Pornin) écrivait :

Il est vrai que les implémentations existantes de X.509 ont tendance à
être d'une qualité douteuse. La faute en incombe en partie au standard
lui-même, qui est d'une complexité qui confine à l'absurde. Mais c'est
un autre débat et ça s'améliore (de ce point de vue, l'implémentation de
Microsoft dans les tous derniers "Service Packs" est nettement meilleure
que celle d'il y a trois ans).

Mouais, en toute rigueur windows update ne devrait plus marcher depuis
janvier (expiration d'un certificat) et y'a pas même un warning...

Donc X509 dans windows c'est *encore* bancal.

--
Real programs don't eat cache

Erwan David wrote:

Mouais, en toute rigueur windows update ne devrait plus marcher depuis
janvier (expiration d'un certificat) et y'a pas même un warning...

Donc X509 dans windows c'est *encore* bancal.

Soit plus précis dans ce dont tu parle, j'ai en tout cas déjà pu tester
que Windows Update ne marche plus une fois qu'on a retiré certains
certificats du magasin.

S'il s'agit de code signé, il y a un horodatage optionnel, il suffit que
celui-ci indique que le code a été signé avant janvier 2004, pour que le
code continue à être considéré valide par rapport au certificat.