Lire ses mails en toute sécurité
Bon, après le coupe de gueule,voici un super super article sur la sécurité
L'origine de ce post : mon stage d'été sur la sécurisation d'un service de mails et le fait que
- la plupart des gens ne comprennent pas vraiment la sécurité mise en oeure et ses enjeux
- et que cela concerne aussi des informaticiens <-- cela, ça commence vraiment à m'inquiéter
Lire ses mails en toute sécurité
Note : ce post va également faire le sujet d'un article (dans quelques jours) plus complet sur mon site perso.
Présentation générale
Le chiffrement
Les techniques de chiffrement permettent de protéger les données en les modifiant lors du transfert. Il est donc nécessaire que les deux cotés (ie le client et le serveur) se mettent d’accord sur la technique de chiffrement mais aussi les clés de sécurités permettant de chiffrer (texte en clair -> texte protégé) et déchiffrer (texte protégé -> texte en clair). Ces informations (du moins les clés) doivent être bien sûr échangées de manière sécurisées. Cela peut se faire par exemple via SSL et TLS.
SSL et TLS
SSL (Secure Sockets Layer) et TLS (Transport Layer Security) sont deux méthodes de chiffrements qui se basent sur des techniques de chiffrement pour assurer la confidentialité des données, SSL version 2 et TLS version 1 étant fortement similaire. Une description de chaque protocole est disponible sur http://en.wikipedia.org/wiki/Secure_Sockets_Layer.
Le principe est le suivant : lors de la connexion, le client demande au serveur le certificat permettant au client de s’assurer de l’identité du serveur. A partir de ce certificat, il est possible d’échanger des clés de communication de manière sécurisée et de débuter ensuite une communication protégée. La vérification du certificat se base sur une liste de confiance disponible sur chaque navigateur. Cette liste est constituée des certificats l’ensemble des organismes étant définis comme apte à délivrer des certificats. Ces certificats sont automatiquement comme sûr et peuvent également servir de source à une chaîne de certification. Ainsi un service ayant un certificat signé par un organisme ayant un certificat …. signé par une autorité de confiance est reconnue.
Une introduction à ces protocoles est également disponible sur l’une de mes présentations (« Conférence sur la cryptographie », http://aispirit.over-blog.com/article-6748564.html).
Informations sur les certificats
Dans le cas d’un certificat 100% bien définit, aucun message ne doit apparaître à l’écran.
Sinon, il est possible d’avoir des alertes du type « certificat non reconnu ». Dans ce cas, cela peut signifier deux choses :
- le certificat provient d’un chaîne non certifié (ie un certificat intermédiaire n’est pas signé par une autorité de confiance). C’est souvent le cas pour les webmails développé par des universités ou autres, vue qu’il faut acheter un certificat ou du moins sa signature. Toutefois, cela est en cours de changement au niveau des universités (cf. CRU).
- Le certificat est un faux, signé par une autorité malveillante (ou non signé)
Avec ces alertes, les navigateurs (ou autres outils) affichent l’option « toujours accepter », ce qui signifie ajouter le certificat à la liste des certificats de confiance.
SASL
SASL (Simple Authentication and Security Layer, http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer), est une technique permettant d’assurer l’authentification des personnes sur un réseau public. Elle consiste à envoyer les données (les identifiants) au serveur en les chiffrant. Toutefois, cette méthode a pour but d’assurer la sécurité de l’authentification, mais pas des futures communications durant la session.
Exemple de sécurisation
Sécurisation : webmail
Comme indiqué dans l’un de mes précédents posts (« Gmail : quand le comportement par défaut est dangereux », http://aispirit.over-blog.com/article-7022509-6.html), l’aspect sécurité lors de la connexion au webmail est très importante. La première étape consiste à se connecter en https (ie utilisation de SSL) sur le serveur.
Cela offre une sécurité de base, notamment pour l’échange des identifiants, mais cela n’assure pas une confidentialité maximale, si par exemple il y a ensuite une redirection automatique sur http.
Il est important de voir que cette redirection n’a pas d’impact sur l’authentification proprement dite, mais plus sur deux aspects
- la confidentialité (aucune donnée échange n’est désormais protégée)
- la sécurité de la session (un sidejacking est possible)
Pour éviter ces problèmes, il existe plusieurs solutions :
- configurer le webmail, lorsque c’est possible, pour n’utiliser que la connexion https et sans redirection vers http
- utiliser des plugins effectuant une redirection http -> https. Cette deuxième solution peut être effectué avec par exemple le plugin GMailSecure pour firefox, comme indiqué dans le post « Google --> GMailSecure » http://aispirit.over-blog.com/article-7025691.html
Sécurisation des clients de messagerie
Si on reprend le cas de gmail, il est possible de consulter ses mails sans utiliser le webmail, mais via un client classique (bien que cela passe par l’activation du support pop3, au niveau des préférences du compte, dans le webmail).
Je ne vais pas détailler la configuration du webmail et je vais directement passer à la configuration du client et de sa sécurisation (pour la configuration via webmail, c’est très simple et il existe des aides sur gmail :D).
Réception des mails
Il existe là encore plusieurs possibilités, notamment en fonction des méthodes supportées par le serveur de mails à configurer (ou encore par le client). Gmail supporte SSL donc comme indiqué par 1 sur la figure 1, c’est la configuration que j’ai choisie. Cependant, Gmail ne supporte pas SASL, 2 doit donc être désactivée (Authentification sécurisée = SASL, voilà une chose que j’ai appris avec mon stage de cet été ?).
Figure 1 – configuration du client pour la réception de mails. Exemple avec Thunderbird
Avec ces deux options, vous pouvez lire vos mails tranquillement !
Envois de mails
Après la réception des mails, attaquons l’envoi. Le serveur SMTP peut là encore supporter différente méthodes. Une limite à Thunderbird, à ce niveau, est que SASL n’est pas supportée (dans la version actuelle ?) et je n’ai donc pas pu le tester.
La configuration consiste donc à définir TLS / SSL. A noter que je déteste l’option Non (bien que là l’utilisateur dit « non ») mais que je déteste encore plus « TLS, si disponible » car là, on ne sait rien du tout sur la sécurité !
Figure 2 – configuration du client pour l’envoi de mails. Exemple avec Thunderbird
L'origine de ce post : mon stage d'été sur la sécurisation d'un service de mails et le fait que
- la plupart des gens ne comprennent pas vraiment la sécurité mise en oeure et ses enjeux
- et que cela concerne aussi des informaticiens <-- cela, ça commence vraiment à m'inquiéter
Lire ses mails en toute sécurité
Note : ce post va également faire le sujet d'un article (dans quelques jours) plus complet sur mon site perso.
Présentation générale
Le chiffrement
Les techniques de chiffrement permettent de protéger les données en les modifiant lors du transfert. Il est donc nécessaire que les deux cotés (ie le client et le serveur) se mettent d’accord sur la technique de chiffrement mais aussi les clés de sécurités permettant de chiffrer (texte en clair -> texte protégé) et déchiffrer (texte protégé -> texte en clair). Ces informations (du moins les clés) doivent être bien sûr échangées de manière sécurisées. Cela peut se faire par exemple via SSL et TLS.
SSL et TLS
SSL (Secure Sockets Layer) et TLS (Transport Layer Security) sont deux méthodes de chiffrements qui se basent sur des techniques de chiffrement pour assurer la confidentialité des données, SSL version 2 et TLS version 1 étant fortement similaire. Une description de chaque protocole est disponible sur http://en.wikipedia.org/wiki/Secure_Sockets_Layer.
Le principe est le suivant : lors de la connexion, le client demande au serveur le certificat permettant au client de s’assurer de l’identité du serveur. A partir de ce certificat, il est possible d’échanger des clés de communication de manière sécurisée et de débuter ensuite une communication protégée. La vérification du certificat se base sur une liste de confiance disponible sur chaque navigateur. Cette liste est constituée des certificats l’ensemble des organismes étant définis comme apte à délivrer des certificats. Ces certificats sont automatiquement comme sûr et peuvent également servir de source à une chaîne de certification. Ainsi un service ayant un certificat signé par un organisme ayant un certificat …. signé par une autorité de confiance est reconnue.
Une introduction à ces protocoles est également disponible sur l’une de mes présentations (« Conférence sur la cryptographie », http://aispirit.over-blog.com/article-6748564.html).
Informations sur les certificats
Dans le cas d’un certificat 100% bien définit, aucun message ne doit apparaître à l’écran.
Sinon, il est possible d’avoir des alertes du type « certificat non reconnu ». Dans ce cas, cela peut signifier deux choses :
- le certificat provient d’un chaîne non certifié (ie un certificat intermédiaire n’est pas signé par une autorité de confiance). C’est souvent le cas pour les webmails développé par des universités ou autres, vue qu’il faut acheter un certificat ou du moins sa signature. Toutefois, cela est en cours de changement au niveau des universités (cf. CRU).
- Le certificat est un faux, signé par une autorité malveillante (ou non signé)
Avec ces alertes, les navigateurs (ou autres outils) affichent l’option « toujours accepter », ce qui signifie ajouter le certificat à la liste des certificats de confiance.
SASL
SASL (Simple Authentication and Security Layer, http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer), est une technique permettant d’assurer l’authentification des personnes sur un réseau public. Elle consiste à envoyer les données (les identifiants) au serveur en les chiffrant. Toutefois, cette méthode a pour but d’assurer la sécurité de l’authentification, mais pas des futures communications durant la session.
Exemple de sécurisation
Sécurisation : webmail
Comme indiqué dans l’un de mes précédents posts (« Gmail : quand le comportement par défaut est dangereux », http://aispirit.over-blog.com/article-7022509-6.html), l’aspect sécurité lors de la connexion au webmail est très importante. La première étape consiste à se connecter en https (ie utilisation de SSL) sur le serveur.
Cela offre une sécurité de base, notamment pour l’échange des identifiants, mais cela n’assure pas une confidentialité maximale, si par exemple il y a ensuite une redirection automatique sur http.
Il est important de voir que cette redirection n’a pas d’impact sur l’authentification proprement dite, mais plus sur deux aspects
- la confidentialité (aucune donnée échange n’est désormais protégée)
- la sécurité de la session (un sidejacking est possible)
Pour éviter ces problèmes, il existe plusieurs solutions :
- configurer le webmail, lorsque c’est possible, pour n’utiliser que la connexion https et sans redirection vers http
- utiliser des plugins effectuant une redirection http -> https. Cette deuxième solution peut être effectué avec par exemple le plugin GMailSecure pour firefox, comme indiqué dans le post « Google --> GMailSecure » http://aispirit.over-blog.com/article-7025691.html
Sécurisation des clients de messagerie
Si on reprend le cas de gmail, il est possible de consulter ses mails sans utiliser le webmail, mais via un client classique (bien que cela passe par l’activation du support pop3, au niveau des préférences du compte, dans le webmail).
Je ne vais pas détailler la configuration du webmail et je vais directement passer à la configuration du client et de sa sécurisation (pour la configuration via webmail, c’est très simple et il existe des aides sur gmail :D).
Réception des mails
Il existe là encore plusieurs possibilités, notamment en fonction des méthodes supportées par le serveur de mails à configurer (ou encore par le client). Gmail supporte SSL donc comme indiqué par 1 sur la figure 1, c’est la configuration que j’ai choisie. Cependant, Gmail ne supporte pas SASL, 2 doit donc être désactivée (Authentification sécurisée = SASL, voilà une chose que j’ai appris avec mon stage de cet été ?).
Figure 1 – configuration du client pour la réception de mails. Exemple avec Thunderbird
Avec ces deux options, vous pouvez lire vos mails tranquillement !
Envois de mails
Après la réception des mails, attaquons l’envoi. Le serveur SMTP peut là encore supporter différente méthodes. Une limite à Thunderbird, à ce niveau, est que SASL n’est pas supportée (dans la version actuelle ?) et je n’ai donc pas pu le tester.
EDIT : et là, je me trompais : bien sûr que TB supporte SASL. Sinon, cela ne marcherait pas à mon stage :D
Lorsque vous cochez "Utiliser un nom d'utilsateur et un mot de passe", cela revient à dire utiliser SASL (comme quoi, des choses parfois évidentes nous passent par dessus la tête !"
Lorsque vous cochez "Utiliser un nom d'utilsateur et un mot de passe", cela revient à dire utiliser SASL (comme quoi, des choses parfois évidentes nous passent par dessus la tête !"
La configuration consiste donc à définir TLS / SSL. A noter que je déteste l’option Non (bien que là l’utilisateur dit « non ») mais que je déteste encore plus « TLS, si disponible » car là, on ne sait rien du tout sur la sécurité !
Figure 2 – configuration du client pour l’envoi de mails. Exemple avec Thunderbird
Publicité