Journal Que penses-tu du service mail Mailden ?

Posté par OK.Computer le 20 octobre 2014 à 00:01. Licence CC By‑SA.

Étiquettes :

oct.

2014

Bonjour Nal,

La semaine dernière, l'émission Service Public sur France Inter avait pour thématique « Un autre internet est- il possible ? Naviguer sans Google, g-mails, Microsoft et consorts » et parmi les invités, pouvait-on entendre Adrienne Charmet- Alix de la Quadrature du Net, Lionel Allorge de l'APRIL, Eric Léandri fondateur de Qwant (le moteur de recherche français qui se cherche une place) ou encore Stanislas Sabatier fondateur de Mailden (non, non pas comme ce groupe de heavy metal).

Si tu fréquentes souvent ces colonnes, les noms d'APRIL et de la Quadrature du Net font partie de ton vocabulaire. Et si tu as déjà cherché des alternatives à Google, Qwant (prononcé kouante), malgré sa popularité mesurée, ne t'est pas inconnu non plus.

Ce qui a retenu mon attention ici est Mailden un service de messagerie électronique sécurisé jusqu'ici inconnu au bataillon. Stanislas Sabatier parle de Mailden dans l'émission mais le site Web est plus explicite : « Mailden est un service de boîtes email sécurisées qui chiffre tous vos emails pour vous garantir le plus haut niveau de confidentialité. »

Derrière le discours marketeux qui sied parfaitement à une page d'accueil, Mailden propose :

une boîte mail de 30 Go (+ 50 alias) en @mailden (avec aussi la possibilité d'utiliser son nom de domaine)
les fonctionnalités usuelles (protection contre le spam, webmail Roundcube)

Mais ce qui distingue Mailden des services plus traditionnels c'est :

les données sont chiffrées intégralement coté serveur (AES 256)
la clé de chiffrement personnelle est entre les mains de l'utilisateur uniquement (Mailden n'en possède pas de copie, seul l'utilisateur peut déchiffrer et exploiter ses données).

Le tout pour 30€/ans, soit 2,5€/mois ; pour 30 Go cela me semble plutôt correct.
Et en prime ils utilisent des logiciels ~~libres~~ open-source.

Personnellement, je trouve l'offre pertinente : à l'heure où les prestataires mail les plus populaires se fourvoient en offrant la vie privée de leur utilisateurs à leur bots publicitaires et où les scandales des services de renseignements étatiques sont monnaie courante. Apparemment Mailden offre une parade technique fiable. Le chiffrement intégral coté serveur est un plus sur les solution type hébergeur (ex : OVH), où les données ne sont pas chiffrées si je ne m'abuse, voire même les solutions autohébergée si les données ne sont pas chiffrées localement.

Maintenant, cher Journal, j'aimerais ton avis :

Que penses-tu d'un tel service ?
Quelle(s) faiblesse(s) technique(s) (autre(s) qu'une clé personnelle faible) ton œil avisé entrevoit-il ?
Ce service est-il une bonne solution pour les utilisateurs ne pouvant s'autohéberger ?
Est-il préférable à un service mail type hébergeur ?

# ProtonMail

Posté par ianux (site web personnel, Mastodon) le 20 octobre 2014 à 00:27. Évalué à 10.
Je ne connaissais pas Mailden, mais dans le même genre, il y a ProtonMail qui propose le même service (chiffrement du courrier côté serveur), avec un triple avantage :
- C'est gratuit ;
- C'est développé par des gens du CERN, autant dire pas les derniers des branleurs (des gus qui bossent dans un grand garage circulaire de 27 km de long) ;
- C'est hébergé en Suisse, pays très à cheval sur le respect de la vie privée.
Après, Ces 2 services ne semblent proposer que du webmail, ce qui peut être un choix, by design. Me trompe-je ?
- [^] # Re: ProtonMail
  
  Posté par Zatalyz (site web personnel) le 20 octobre 2014 à 11:32. Évalué à 1.
  
  Ça semble intéressant, à première vue. Après, c'est tout en english, et comme je suis la parfaite incarnation du chauvinisme, j'ai pas eu le courage de lire en détail tout leur site. Pfff pour un truc suisse en plus, on devrait avoir français/roman/italien !
  
  J'ai pas le niveau pour comprendre si le cryptage en question est réellement bien fichu, j'attends l'avis argumenté des experts mais… même mal fichu, ce sera toujours mieux que les fournisseurs classiques qui précisent dans leur contrat qu'ils lisent nos mails (❤Google❤).
  
  Je me demande comment ils se financent, si c'est gratuit et qu'ils ne vendent pas nos infos. L'argent étant souvent le motif du crime, autant savoir d'où il vient.
  
  J'ai pas vu combien de Go on pouvait avoir avec ProtonMail. Mais bon, je ne sais pas si c'est un argument vraiment pertinent (en tout cas pour des utilisateurs lambda dans mon genre), la plupart des webmails proposent plus d'1 Go et en regardant sur ma boite-pourriels (pour tous ces sites qui vous demandent de vous inscrire… et revende ensuite l'adresse à des listes de spammeurs) qui tourne depuis des années et que je ne vide pas souvent, je reste en dessous des 2Go… Et c'est fort probablement celle qui reçoit le plus de mail et les plus "lourds". La limite des pièces jointes dans les mails étant assez basse, de façon logique ça monte pas si vite que ça et il s'agit vraiment de pub pour les fournisseurs de mail de dire qu'on a "500Go" disponibles : dans la pratique, peu de gens les utiliseront.
  
  Merci pour le lien :)
  - [^] # Re: ProtonMail
    
    Posté par pamputt le 20 octobre 2014 à 12:11. Évalué à 2.
    
    Pour le financement, ils avaient lancé une campagne de financement participatif cet été qui a rapporté 550 k$
    Le seul problème avec ProtonMail pour le moment, c'est que malgré l'intention des développeurs de publier le code sous licence MIT mais rien n'a encore été fait dans ce sens pour le moment.
- [^] # Tutanota
  
  Posté par pamputt le 20 octobre 2014 à 12:13. Évalué à 2.
  
  À noter qu'un service allemand, tutanota propose le même genre de service.
  - [^] # Re: Tutanota
    
    Posté par Sidonie_Tardieu le 20 octobre 2014 à 12:29. Évalué à 10.
    
    from : https://tutanota.de/#!faq
    
    Why can't I save my private key locally (similar to PGP)?
    Originally we planned to save the private keys only locally with the user. However we consciously opted against that: Each user has to secure his/her (encrypted) key independently. If the user loses the key by accidentally deleting it or because the hard disk breaks down without having a back-up, all data are lost irretrievably. If you want to access your emails from a different browser or from a mobile device, you have to take the key with you and import it.
    
    Due to these reasons we decided to save the private key on our highly secure server. We do everything for saving the key securely. (read also: How is the private key secured?) In addition we will soon offer the possibility to save the private key locally as well.
    
    Pour toutes ces raisons (je ne les traduis pas, ce sont des mauvaises raisons ^_^), nous avons décidé de sauvegarder votre clé privée sur nos serveurs haute-sécurité. Nous faisons tout notre possible pour que cette sauvegarde soit sécurisée. En outre, nous offrirons très bientôt la possibilité de sauvegarder votre clé localement.
    
    → Le reste est à l'avenant, marketteux et imprécis au possible.
    
    Fly, you fools!
    
    Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !
# Il faut leur faire confiance les yeux fermés...

Posté par RB le 20 octobre 2014 à 00:55. Évalué à 10. Dernière modification le 20 octobre 2014 à 00:56.
Ils disent que dès qu'ils reçoivent les emails ils les chiffrent avec la clé publique (sans en garder une copie en clair, on ne peut pas en être certain).

Ensuite:
1. Lorsque vous vous connectez au serveur Mailden pour récupérer vos emails, vous transmettez de façon sécurisée votre mot de passe. Ce mot de passe est placé temporairement dans une zone sécurisée de la mémoire du serveur Mailden. Il va être utilisé pour ouvrir votre clé privée et permettre ainsi le déchiffrement de vos emails et leur envoi sur votre ordinateur personnel, via une connexion sécurisée.
2. Lorsque vous vous déconnectez du serveur Mailden, votre mot de passe est effacé de la mémoire du serveur Mailden. Vos emails redeviennent inaccessibles à quiconque, car ils sont toujours stockés dans leur version chiffrée.
Ça je n'aime pas du tout, au moins j'aimerais déchiffrer les emails sur MON pc, pas leur donner temporairement ma clé privée et son mot de passe !!! Ils font ça pour qu'ensuite les emails puissent être rapatriés en POP3/IMAP normal mais ça ne me plaît pas du tout. Donc si un gouvernement leur force la main, il suffira d'une seule connexion et il aura tout en sa possession pour déchiffrer les emails stockés et à venir.
- [^] # Re: Il faut leur faire confiance les yeux fermés...
  
  Posté par Maclag le 20 octobre 2014 à 01:53. Évalué à 7.
  
  Ça je n'aime pas du tout, au moins j'aimerais déchiffrer les emails sur MON pc, pas leur donner temporairement ma clé privée et son mot de passe !!! Ils font ça pour qu'ensuite les emails puissent être rapatriés en POP3/IMAP normal mais ça ne me plaît pas du tout. Donc si un gouvernement leur force la main, il suffira d'une seule connexion et il aura tout en sa possession pour déchiffrer les emails stockés et à venir.
  
  Pire: s'ils sont compromis, l'attaquant aura accès à toutes les boites mails de tous les clients le temps d'un cycle de synchro automatique!
  
  Je ne suis pas expert en sécu, mais pour moi, une des "armes", c'est un peu comme les distros Linux: si tu écris un exploit pour "Linux", tu ne sais jamais s'il marchera sur 1, 2, ou toutes les distros. Du coup ça en fait une cible moins tentante. Avec la clé stockée en local, l'attaquant devrait se coltiner chaque appareil client pour avoir le même résultat.
# Ben non

Posté par Zenitram (site web personnel) le 20 octobre 2014 à 08:38. Évalué à 5. Dernière modification le 20 octobre 2014 à 08:43.

la clé de chiffrement personnelle est entre les mains de l'utilisateur uniquement (Mailden n'en possède pas de copie, seul l'utilisateur peut déchiffrer et exploiter ses données).

La FAQ dit le contraire :

"Lorsque vous vous connectez au serveur Mailden pour récupérer vos emails, vous transmettez de façon sécurisée votre mot de passe."

Donc ils ont le mot de passe eux aussi (on leur transmet).

Apparemment Mailden offre une parade technique fiable

Même pas en apparence pour qui a un minimum de baguage technique (savoir qu'à partir du moment qu'on transmet un pass, ben l'autre l'a).
C'est que de la communication (un peu de chiffrage pour dire qu'on est différent, mais sinn on ne pense pas sécurité globale).

le jour où l'Etat veut voir ton compte, il prend le controle du serveur chez eux, et a ton pass à ta prochaine connexion.
Ca ne change vraiment pas grand chose (OK, ils ne stockent pas il parait, mais d'une on ne sait pas vraiment, confiance à avoir sur des nouveaux, et de deux on peut stocker les pass de manière sécurisée aussi, à coup de machine dédiée aux pass qui empèche un dump, avec PBKDF2 etc).

Ce service est-il une bonne solution pour les utilisateurs ne pouvant s'autohéberger ?

Son avantage est d'être hébergé en France. C'est tout.

Le chiffrement intégral coté serveur est un plus sur les solution type hébergeur (ex : OVH), où les données ne sont pas chiffrées si je ne m'abuse,

On ne sait pas, mais en fait on s'en fout : ils ont la clé, donc ils peuvent déchiffrer, ça ne change rien en pratique pour la NSA, uniquement en cas de vol physique de disque dur (vous en avez souvent entendu parlé de vol de disque dur? La NSA a plus l'habitude de se connecter à chaud, donc avec lectur de votre mot de passe quand vous le transmettez…)

Le tout pour 30€/ans,

Chez OVH, c'est 9€/an avec un nom de domaine, "que" 2 Go (faut déjà les remplir en mail) et pour 30€/an tu as nom de domaine, hébergement web, MySql, 10 (et non pas un seul compte) email (de 5 Go mais bon ça suffit, "30 Go" c'est pour faire qui a la plus grosse, je préfère 3 comptes de 5 Go que 1 compte de 1 To), avec le même avantage réel (c'est hébergé en France), donc bon, ça me parait bien cher pour ce que c'est.

Bref, le site surfe sur la peur du moment, sans apporter de solution mais en cherchant ton porte-monnaie. Bienvenue marketing.

Qwant (le moteur de recherche français qui se cherche une place)

Tu veux dire le meta-moteur qui n'est pas moteur?
- [^] # (F)rance
  
  Posté par Arthur Accroc le 20 octobre 2014 à 09:01. Évalué à 6.
  
  Son avantage est d'être hébergé en France.
  
  À mon sens, ce n’est plus un avantage.
  
  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Ben non
  
  Posté par Nicolas Boulay (site web personnel) le 20 octobre 2014 à 10:36. Évalué à 2.
  
  On ne sait pas, mais en fait on s'en fout : ils ont la clé, donc ils peuvent déchiffrer, ça ne change rien en pratique pour la NSA, uniquement en cas de vol physique de disque dur (vous en avez souvent entendu parlé de vol de disque dur? La NSA a plus l'habitude de se connecter à chaud, donc avec lectur de votre mot de passe quand vous le transmettez…)
  
  Même si ils ne stockent pas la clef, cela ne sert à rien, il suffit de snifer le réseau au prochain utilisation du compte pour l'avoir.
  
  Cela serait intéressant d'avoir un système basé sur HTTP et des blobs qui sont décrypté en live par un module du navigateur web. Ils peuvent gérer des clefs publiques/privé, mais même juste avec des clefs symétriques, cela pourrait être utile.
  
  "La première sécurité est la liberté"
# C'est le moment de revenir sur le projet caliop ?

Posté par chimrod (site web personnel) le 20 octobre 2014 à 09:44. Évalué à 2.

Après avoir fait grand bruit au début, le projet de Laurent Chemla et une période d'incubation assez longue (l'activité mailing-list contenant 10 demandes de besoins chacune plus de fonctionnalités que les précédentes, 100 messages demandant la date de sortie, 1000 personnes silencieuses, et 1 poisson d'avril qui a failli marcher), le projet est finalement passé en stade de béta-test.

Est-ce qu'il y a des moules qui s'intéressent au projet, quelqu'un à testé ?
- [^] # Re: C'est le moment de revenir sur le projet caliop ?
  
  Posté par Zenitram (site web personnel) le 20 octobre 2014 à 10:11. Évalué à 4. Dernière modification le 20 octobre 2014 à 10:12.
  
  le projet est finalement passé en stade de béta-test. (…) quelqu'un à testé ?
  
  Je viens de tester : j'ai ouvert la page principale, pas vraiment compris ce qu'il en était du concept, cliqué sur quelques pages, tombé sur "Try prototype", cliqué un peu partout, et ai fermé l'onglet.
  
  béta, vraiment?
  Concept, vraiment? (voir le premier commentaire de la dépèche LinuxFr)
  
  Je crois qu'il ne vaut mieux pas en faire trop la publicité pour le moment…
  - [^] # Re: C'est le moment de revenir sur le projet caliop ?
    
    Posté par jcfrog le 23 novembre 2014 à 10:52. Évalué à 0.
    
    bonjour tout le monde,
    
    si vous cherchez des news sur caliopen (ex caliop), je vous conseille très vivement une conférence récente avec Laurent Chemla qui donne une bonne vision de l'état où en est le projet. En gros ça déboite, et on cherche du monde :)
    
    https://air.mozilla.org/paris-meetup-pour-la-decentralisation-dinternet-3/
# Code

Posté par Thomas Sanchez le 20 octobre 2014 à 10:27. Évalué à 1.

https://github.com/Mailden/email-encryption-system-public/blob/master/chaines.c

Ça me suffit pour me dire que le sérieux n'est peut être pas si poussé que ça…
- [^] # Re: Code
  
  Posté par maboiteaspam le 20 octobre 2014 à 12:54. Évalué à 1.
  
  de ré inventer la roue ?
  
  Je ne connais pas grand chose au C, mais c'est tout ce que je trouve à en dire de but en blanc.
  - [^] # Re: Code
    
    Posté par CrEv (site web personnel) le 20 octobre 2014 à 21:58. Évalué à 4.
    
    En fait, rien que chaines.c et des trucs comme string_ajout ou string_p*g*_escape qui fait un PQEscapeString c'est moche.
    Le franglais dans les noms de fonction c'est juste toujours horrible.
    - [^] # Re: Code
      
      Posté par maboiteaspam le 21 octobre 2014 à 02:09. Évalué à 3.
      
      erf… Je doit être totalement immunisé à ces règles syntaxiques. Trop de chinglish autour de moi peut être ^{^}
- [^] # Re: Code
  
  Posté par gouttegd le 20 octobre 2014 à 13:06. Évalué à 6.
  Moi j’aime bien le fichier alea.c :
```
    srandom((unsigned int)(time(NULL) % 9061973)); // put a secret prime number to raise entropy
    u.seed_chunks.part1 = ((unsigned int)arc4random()%222)+32;
    srandom((unsigned int)(time(NULL) % 2039485230948572951)); // put a secret prime number to raise entropy
    u.seed_chunks.part3 = ((unsigned int)arc4random()%222)+32;
    read_random_device(8, u.seed_chunks.part5);
    srandom((unsigned int)(time(NULL) % 2039485267));  // put a secret prime number to raise entropy
    u.seed_chunks.part2 = ((unsigned int)arc4random()%222)+32;
    srandom((unsigned int)(time(NULL) % 98876033));  // put a secret prime number to raise entropy
    u.seed_chunks.part4 = ((unsigned int)arc4random()%222)+32;
    read_random_device(8, u.seed_chunks.part5 + 8);

    srand(clock()+(time(0)/3001));  //a secret prime number to raise entropy

    srand(clock()+(time(0)/3011));  // a secret prime number to raise entropy
```
  - [^] # Re: Code
    
    Posté par gouttegd le 21 octobre 2014 à 12:44. Évalué à 2. Dernière modification le 21 octobre 2014 à 12:45.
    
    Je me réponds à moi-même, pour dire que ces constantes « secrètes » sont en fait inoffensives a priori, vu que si j’ai bien compris elles ne servent complètement à rien.
    
    En effet arc4random(3), sur les systèmes où cette fonction existe, est semble-t-il directement « seedé » par le générateur de nombre aléatoires du système (soit par lecture de /dev/urandom, soit par getentropy(2)). srandom(3) sert à initialiser le générateur derrière random(3) et n’a pas d’effets sur arc4random(3).
    - [^] # Re: Code
      
      Posté par rakoo (site web personnel) le 21 octobre 2014 à 22:53. Évalué à 4.
      
      Je ne suis pas un expert, mais si c'est pas écrit par des cryptographes reconnus et audités, c'est plus une faille de sécurité qu'autre chose. Du coup je vais rediriger vers Daniel Bernstein (ici) où il explique bien que du code qu'on a écrit soi-même pour tenter de générer de l'aléatoire est plus que dangereux: ça permet à un attaqueur d'influer sur les paramètres "secrets", qui sont en fait tout à fait exploitables par cet attaqueur… sans être détectables par la victime (puisque de loin ça a toujours l'air aléatoire).
      
      Moralité: si vous devez générer de l'aléatoire, lisez /dev/urandom. Rien de plus, rien de moins.
      - [^] # Re: Code
        
        Posté par Sufflope (site web personnel) le 21 octobre 2014 à 23:11. Évalué à 7.
        
        du code qu'on a écrit soi-même pour tenter de générer de l'aléatoire est plus que dangereux
        
        Ca me rappelle le projet sur lequel j'ai bossé pour mon premier boulot. Le code de génération de mot de passe écrit par un geek parano chantre de la sécurité (c'est ce qu'on m'a rétorqué quand j'ai mis le nez dedans au bout d'un an de projet et que j'en ai conclu à voix haute que c'était de la merde) utilisait des techniques de sécurité de haut vol telles que piocher dans un tableau des caractères alphanumériques courants, mais pas triés par ordre lexicographique, et en piochant 8 fois à l'indice (random.nextInt() * 31) % taille_du_tableau (31 étant une constante première secrète qui permet de rendre vraiment aléatoire le choix).
        
        Le tout (déjà bien ridicule) pour stocker l'empreinte du mdp en SHA-1 sans sel (et pour l'envoyer à l'utilisateur par courriel en clair, mais bon ça c'est limite trop facile de taper dessus, et c'est un des premiers trucs qu'on a virés, pas attendu un an).
        
        Je pense avoir fait bien bien plus pour la sécurité du projet en passant à bcrypt que le dev précédent et sa danse de Saint-Guy.
        
        [^] # Re: Code
        
        Posté par Lebas Sébastien le 23 octobre 2014 à 17:40. Évalué à 2.
        
        31 étant une constante première secrète qui permet de rendre vraiment aléatoire le choix
        
        C'est dommage, il manque la nimage associée: http://xkcd.com/221/ :)
        
        [^] # Re: Code
        
        Posté par Marotte ⛧ le 24 octobre 2014 à 12:05. Évalué à 4.
        
        J'aime bien celle là moi :
        
        :)
# GMail !

Posté par barmic le 20 octobre 2014 à 11:12. Évalué à 10.

Si vous cherchez à ne pas faire confiance au serveur de mail que vous utilisez (tout est chiffré coté serveur et le déchiffrement se fait uniquement coté client), pourquoi chercher un service particulier ? GMail, Outlook ou le service de yahoo le permettent très bien. C'est coté client qu'il faut utiliser une extension qui va bien.

Il ne restera plus que le vrai problème à résoudre : avoir des personnes à qui parler qui savent déchiffrer vos mails.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# L'esprit de Mailden

Posté par Mailden le 21 octobre 2014 à 09:29. Évalué à 7.

Bonjour à tous,
et merci de l’intérêt que vous portez à Mailden.
Merci aussi pour vos remarques.

Fondateur de Mailden, je voudrais apporter quelques précisions sur « l’esprit » de Mailden.
Premièrement, Mailden ne prétend aucunement être une solution imparable contre l’espionnage ciblé.
(D’ailleurs il n’existe probablement aucune solution imparable contre l’espionnage ciblé : si des gens qui ont des moyens humains et financiers veulent tout savoir de vous, ils le sauront !).
L’idée qui anime notre projet est de rehausser le niveau de sécurité des emails, POUR TOUS, c’est-à-dire pour le boulanger, l’employée du bureau, la dessinatrice de mode, mon grand-père, mes enfants, les profs… Nous pensons que tout le monde a le droit d’avoir une zone de confidentialité, en particulier sur Internet.
Nous avons donc développé une solution pratique, qui permet d’élever sensiblement la sécurité des emails, sans que cela implique à nos clients de passer du temps à comprendre comment la cryptographie fonctionne (car, que vous le vouliez ou non, 99 % de la population n’est pas intéressée par l’informatique ou la cryptographie… Chacun a aussi le droit d’avoir des centres d’intérêt différents !)
En plus d’avoir mis au point une solution technique qui sécurise grandement les emails stockés sur les serveurs – solution qui est vouée à évoluer au fur et à mesure que nous trouverons des techniques plus perfectionnées (toutes les contributions sont les bienvenues !) –, Mailden offre aussi un contrat de service clair à ses clients. C’est un autre point très important de notre proposition. Contrairement à tous nos concurrents, nous disons clairement à nos clients qu’ils nous paient pour que nous protégions leurs emails. Et nous prenons des engagements. C’est une alternative fondamentale aux propositions de services existantes, gratuites ou payantes. Ce type d’offre manquait cruellement en France… Et, en toute humilité, nous pensons que notre service améliore sensiblement la confidentialité des correspondances sur Internet.

Notre solution est perfectible. C’est d’ailleurs pour cela que nous avons publié nos sources. Pour montrer précisément comment les emails sont traités chez Mailden (ce qu’aucun concurrent ne fait), mais aussi pour susciter des contributions ou collaborations extérieures, dans l’esprit du logiciel collaboratif. Nous nous ferons un plaisir d’accueillir des contributeurs – et de leur offrir des comptes Mailden –, à condition toutefois que leur contribution aille au-delà du sarcasme (du français dans le code ! quelle horreur… du français ! ;-)

Nous sommes à votre disposition pour en discuter : contact (arobase) mailden (point) net

Merci,
Stanislas.
- [^] # Re: L'esprit de Mailden
  
  Posté par Sidonie_Tardieu le 21 octobre 2014 à 12:09. Évalué à 7.
  Bonjour !
  
  Mailden ne stocke pas votre mot de passe. Il nous est impossible de vous le restituer. C'est un choix que nous avons fait pour vous garantir la sécurité de vos emails.
  Comment faites-vous pour valider mon mot de passe alors qu'il n'est pas conservé sur votre serveur ?
  
  Pouvez-vous me citer un prestataire de service en courrier électronique "standard" qui conserve les mots de passe ?
  En quoi procédez-vous de manière différente ?
  
  Des index des emails présents dans chaque dossier : ces index accélèrent la récupération de vos emails ainsi que les recherches dans vos dossiers. Ils contiennent : les en-têtes des messages et des informations techniques (n° de message, statut lu/non lu…)
  NB : vous avez la possibilité de désactiver l'indexation de vos emails pour augmenter votre niveau de confidentialité.
  
  Quels sont les différents niveaux de confidentialité accessibles grâce à votre offre et a quoi correspondent-ils exactement ? Je n'ai pas trouvé cette information.
  Est-ce :
  - un peu de confidentialité ?
  - un peu plus ?
  - un peu plus qu'un peu plus ?
  - un peu plus beaucoup mais moins que beaucoup beaucoup ?
  - beaucoup beaucoup ?
  - pas absolue mais c'est pas loin ?
  Voici la liste exhaustive des informations que nous conservons pour chaque client […] La clé privée correspondante : elle est elle-même chiffrée (avec AES-RIJNDAEL 256) grâce à votre mot de passe et une passphrase. NB : Votre mot de passe n'est pas conservé par Mailden, ce qui rend votre clé privée inaccessible si vous n'êtes pas connecté.
  
  Pour utiliser votre service, on doit s'identifier avec un couple id/pass, et ensuite déchiffrer sa clé privée avec une passphrase ? Pourtant, il n'est fait mention nulle part de cette passphrase ailleurs que dans cet item de la faq.
  De plus, vous ne proposez pas d'option pour ne pas stocker chez vous la clé privée ? Comment justifiez-vous sérieusement cette position ?
  1. Si la société Mailden fait faillite, que deviendront mes emails ? Cas n° 1 : si vous avez l'habitude d'accéder à votre compte email avec un logiciel de courrier électronique (Outlook, Thunderbird, Apple Mail, etc.), alors vous possédez déjà une copie de tous vos emails sur votre ordinateur personnel. Vous n'avez pas de souci à se faire, si Mailden disparait, vos emails seront toujours sur votre ordinateur.
  Donc l'accès avec un client lourd s'effectue nécessairement en pop, puisque vous ne pouvez pas garantir (aux 99% de la population) que la configuration imap des clients lourds va conserver les mails localement.
  Ce n'est pourtant pas ce que dit https://www.mailden.net/#!/help.
  
  Nous avons donc développé une solution pratique, qui permet d’élever sensiblement la sécurité des emails, sans que cela implique à nos clients de passer du temps à comprendre comment la cryptographie fonctionne (car, que vous le vouliez ou non, 99 % de la population n’est pas intéressée par l’informatique ou la cryptographie… Chacun a aussi le droit d’avoir des centres d’intérêt différents !)
  
  Pourriez-vous m'expliquer la différence entre « élever sensiblement la sécurité » et « Mailden vous garantit le plus haut degré de protection de vos emails (lu sur votre page d'accueil) » ?
  
  Mailden offre aussi un contrat de service clair
  
  Mais où est ce contrat ??? Je vois une faq, de l'aide, des cgu, mais aucun contrat.
  
  Etc, etc.
  
  Vous ne revendez pas les informations des clients. Ok. Pour l'instant, c'est une histoire de confiance, rien ne me le prouve. Mais ok.
  Vous faites auditer votre infra. Ok. Pour l'instant, c'est une histoire de confiance, rien ne me le prouve. Mais ok.
  
  Pour le reste, c'est un peu du bullshiting, et j'en suis désolée.
  Je vous cite encore : « Nos boîtes email sont devenues trop importantes pour laisser n’importe qui y accéder. »
  
  → Si c'est important, soyez précis !
  
  Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !
- [^] # Re: L'esprit de Mailden
  
  Posté par freem le 21 octobre 2014 à 13:07. Évalué à 5.
  Bon, ça va résumer un peu certains commentaires précédents, et je vais ajouter un peu de mon côté au passage:
  
  L’idée qui anime notre projet est de rehausser le niveau de sécurité des emails, POUR TOUS, c’est-à-dire pour le boulanger, l’employée du bureau, la dessinatrice de mode, mon grand-père, mes enfants, les profs…
  
  C'est une vraie raison pour ne pas imposer de technique impliquant aux utilisateurs d'utiliser un système de clé privée/publique (l'utilisateur moyen ne comprendra pas qu'il faut se trimballer une clé et se souvenir d'une passphrase). En revanche, ce n'est pas une bonne raison pour bloquer cette possibilité.
  Par rapport à l'envoi de mot de passe (je n'ai pas regardé les sources, je me base sur les commentaires précédents) via le net, l'alternative serait de déporter la mécanique de protection côté client, via du JS (je dis ça, alors qu'en général j'ai tendance à bloquer le JS… allez comprendre!).
  Bon, je suis vraiment pas très bon en sécurité, alors je me plante peut-être, ce n'est peut-être pas faisable proprement.
  
  Ce type d’offre manquait cruellement en France…
  
  C'est vrai, l'existant est délicat à trouver, en général ce sont de petites associations. Mais il en existe. Ceci étant dit, une plus grosse structure, qui ait pour objectif de grossir et non de faire des boutures n'est pas une mauvaise chose.
  
  à condition toutefois que leur contribution aille au-delà du sarcasme (du français dans le code ! quelle horreur… du français ! ;-)
  
  Ce n'est pas uniquement sarcastique (mais il faut être habitué à linuxfr il est vrai, pour comprendre entre les lignes), c'est surtout que le code source pointé (chaine.c) révèle plusieurs problèmes:
  - le fait de réinventer la roue (string_ajout, au nom, je dirait que ça réimplémente strcat… p'tet strncat éventuellement, voire pire… std::string::operator+= ).
  - Et, oui, le fait que le code soit en français EST un problème dans le monde du libre. Du code franchouillard, c'est illisible pour un non-francophone, et difficile à lire pour un dev rôdé à coder en anglais… qui sont, amha, majoritaires dans le libre.
  - Enfin, pour en finir au sujet de ce fichier que j'ai lu très vite, et revenir à ma remarque sur std::string::operator+=, pourquoi utiliser le C si c'est pour réimplémenter CFront, limite? Autant utiliser C++ en interdisant les features qui vous gênent (ça se fait très bien à la compil, de virer les exceptions et la RTTI, et quand aux méthodes virtuelles et autres héritages, des règles de codages claires ainsi qu'un ou deux scripts hookés dans le .git peuvent empêcher l'introduction accidentelle. Le C++ n'est pas un langage objet, mais juste orienté objet… c'est un choix du dev qui l'utilise, et si on utilise pas, on paye pas.)
  Enfin, je dirais que roundcube est… spartiate, dans le meilleur des cas. Peut-être avez-vous activé un module qui permets de gérer des règles de filtrage, car il semble que dans la version que j'utilise habituellement, ça n'existe pas, et c'est un manque des plus pénibles, quand on est abonné à une ou deux mailing lists.
  
  En tout cas, bonne chance et bonne continuation.
- [^] # Re: L'esprit de Mailden
  
  Posté par CrEv (site web personnel) le 21 octobre 2014 à 13:53. Évalué à 5.
  
  à condition toutefois que leur contribution aille au-delà du sarcasme (du français dans le code ! quelle horreur… du français ! ;-)
  
  Ce n'est pas une histoire de français (enfin si, je pense qu'un code — plutôt en langue anglaise — doit être commenté en anglais uniquement, cela évite beaucoup de redite inutile en général) mais surtout de constance et de cohérence.
  Un code non cohérent (qui réinvente la roue) ne donne pas vraiment envie de contribuer.
  
  (c'est pas sarcastique, direct peut-être)
- [^] # Re: L'esprit de Mailden
  
  Posté par Zenitram (site web personnel) le 22 octobre 2014 à 15:04. Évalué à 5. Dernière modification le 22 octobre 2014 à 15:07.
  
  L’idée qui anime notre projet est de rehausser le niveau de sécurité des emails, POUR TOUS, c’est-à-dire pour le boulanger, l’employée du bureau, la dessinatrice de mode, mon grand-père, mes enfants, les profs… Nous pensons que tout le monde a le droit d’avoir une zone de confidentialité, en particulier sur Internet.
  
  Le problème est de savoir faire la différence entre une zone de confidentialité, et une fausse zone de confidentialité.
  Si la technique pose problème, il vaut mieux dire "on peux pas" que de faire croire qu'on peut.
  
  En plus d’avoir mis au point une solution technique qui sécurise grandement les emails stockés sur les serveurs
  
  J'attends toujours une démonstration que c'est plus sécurisé que chez OVH (par exemple) : par exemple si OVH met mon mot de passé en PBKDF2 sur un serveur bien à part, c'est plus sécurisé qu'un serveur qui ne stocke pas (il traite) mais qui permet à n'importe quel pirate en herbe de mettre un hook dans le code pour récupérer le mot de passe en clair.
  
  La question est de savoir en quoi vous permettez plus de confidentialité (contre qui?) que les concurrents. Vous ne stockez pas le pass? OK, mais ça ne change pas que vous pouvez l'avoir quand vous en avez envie (le seul délai est jusqu'à ma prochaine connexion)! Donc ça me protège contre qui? (pas de vous, pas de l'Etat puisqu'il peut vous obliger à dumper mon pass… Donc de qui?)
  
  Bref, j'ai du mal à voir autre chose que la vente d'un faux sentiment de sécurité, en surfant sur la vague de la peur mais en n'ayant pas de solution technique pour remplir ce qui est dit.
  
  Ce type d’offre manquait cruellement en France…
  
  Le problème n'est pas franco-français (ça vaut aussi pour le code en français, si j'embauche une personne pour auditer, elle ne sera pas forcément francophone), ce qui fait donc penser à une opération marketing de se limiter à un pays.
# Mailden est une alternative unique en France

Posté par Mailden le 07 novembre 2014 à 09:42. Évalué à 2.

Nous avons lu avec attention les réactions des lecteurs de linux.org à la sortie en France du nouveau service de email protégé. Nous avions déjà fait une première réponse sur ce forum, en voici une deuxième :

Tout d’abord, pour répondre aux critiques sur la manière dont nous générons des nombres aléatoires pour les clés de chiffrement, sachez que nous n’avons pas voulu « réinventer la roue ». Simplement, nous avons voulu éviter de trop solliciter /dev/urandom car nous avons besoin de plusieurs centaines de bytes aléatoires par minute, pour chiffrer chaque email qui arrive avec une clé différente. Nous faisons appel à /dev/urandom et nous mixons avec d’autres sources d’aléatoire. La présence de « nombres premiers secrets » comme seed est uniquement là pour augmenter l’entropie, c’est-à-dire une information qu’un attaquant n’a pas, ce qui rend son attaque plus difficile.
L’avantage d’avoir publié nos sources est précisément d’avoir des retours d’ingénieurs pour nous aider à améliorer notre code. Nous avons pris en compte vos remarques. Nous avons même reçu des propositions d’amélioration de notre code. Cela va nous permettre de publier et de mettre en prod. des versions améliorées de notre logiciel très prochainement.

La critique qui revient le plus concerne la « confiance les yeux fermés » qu’il faudrait faire à Mailden.
Cette « confiance » dont vous parlez, vous êtes – en tant qu’utilisateur d’un service de email – toujours obligé de l’avoir. À moins de mettre en place votre propre serveur ou de chiffrer vos emails de bout en bout. Ce qui n’est pas à la portée de tout le monde !
En mettant en place un système de protection des emails et en expliquant ouvertement comment il fonctionne, nous pensons pouvoir susciter plus de confiance que les opérateurs qui ne vous disent rien de ce qu’ils font de vos emails, ou, – pire –, qui vous disent qu’ils lisent tous vos emails pour faire du profilage ! (gmail, yahoo…)

Nous lisons aussi dans ce forum que « Mailden a le mot de passe en clair à chaque connexion » et que donc « l’État peut compromettre le serveur pour lire tous les emails ».
Premièrement : compromettre un serveur, ça n’est pas simple. Nos serveurs tournent sous freeBSD, derrière des firewalls, en mode secure, avec uniquement les ports des services email ouverts sur Internet. De plus, nos logiciels sont compilés en C. Ce n’est pas demain qu’un attaquant pourra pénétrer les serveurs pour y substituer secrètement un programme et en recréer un autre !
Idem pour les mots de passe, c’est plus compliqué que ce qui est suggéré dans ce forum : les mots de passe arrivent via une connexion TLS forte et ils sont placés dans une zone sécurisée de la mémoire, grâce à la librairie GNU libgcrypt. Cette zone n’est pas dumpable. Ensuite, le mot de passe est libéré de la mémoire dès que l’utilisateur se déconnecte.
Récupérer un mot de passe en « sniffant » la connexion TLS ou la zone mémoire protégée n’est pas impossible, mais c’est une opération très difficile et longue !
D’une manière générale, les lecteurs qui écrivent que « si la NSA veut lire les emails d’un utilisateur, ils finiront par y arriver » ont raison ! D’ailleurs, la NSA arrive probablement à lire les emails de n’importe qui, avec n’importe quelle solution de chiffrement, même du chiffrement de bout en bout. Du moment qu’ils y mettent les moyens. Le plus simple pour eux étant de compromettre l’ordinateur de l’utilisateur, pas les serveurs de stockage.

L’important est de comprendre que, grâce à la multiplication des solutions comme celle de Mailden, l’espionnage de masse est rendu très coûteux pour les agences de renseignement ou pour les entreprises de marketing. Donc il diminuera fortement si le public bascule sur ce type de services. C’est précisément ce que nous recherchons à faire : recréer des espaces protégés sur Internet.
Mailden a mis en place de nombreux dispositifs pour protéger les données de ses utilisateurs, qu’aucun autre acteur du marché ne propose : chiffrement lourd et systématique des connexions (note « A » sur ssllabs), chiffrement lourd et systématique des emails avant stockage, biclé RSA 4096 pour chaque client, mot de passe non stocké chez Mailden (nous avons uniquement un hash blowfish), aucun scan publicitaire ou marketing, engagement contractuel fort de protection des données : lisez nos conditions générales qui inclues les garanties que nous offrons à nos clients.

Pour résumer, la technologie de protection des emails de Mailden est incontestablement plus sécurisée que les solutions gratuites des GAFA ou des opérateurs. Notre service ne prétend pas être imparable – quiconque a cette prétention est un menteur –, mais il offre des garanties que nul autre ne propose en France pour le email. C’est déjà mieux que rien ! Non ?

Mailden.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.