Tout d’abord, je vais ré-préciser quelque chose de fondamental. Une communication aussi sécurisée et chiffrée qu’elle soit est in fine déchiffrée sur l’OS de l’utilisateur pour être affichée à l’écran et stockée dans un historique de conversation. Donc quelque soit le système de protection de communication que vous utilisez, si votre OS est troué ou à la solde de votre espion, vos protections risquent d’être inutiles.

Donc chiffrer ses messages sur un téléphone Android où l’on a installé les GoogleApps et où Google peut lire l’intégralité de la mémoire de votre smartphone sans vous avertir, ça ne sert à rien pour se prémunir de la NSA. Même chose pour les appareils Apple.
Sous Windows, si vous croyez que votre OS n’a pas de porte dérobée, c’est bien. J’aurai des doutes à votre place. Quand aux failles de sécurité, il suffit de regarder l’histoire pour voir que les failles réseau du système sont courantes.

Bref, les prérequis me semblent un smartphone sous Android (sans logiciels propriétaires en root  == sans GoogleApps) et une distribution Gnu (Debian, etc…) sans logiciels propriétaires.

Le postulat est donc que seul votre terminal est sûr, le reste du réseau (serveurs tiers, FAI, internet et même réseau local) pouvant être mis sur écoute. Détrompez vous, il n’y a pas forcément besoin d’une faille technique pour mettre le réseau sur écoute, la contrainte légale sur les sociétés par les états de livrer les informations personnelles de leurs utilisateurs fonctionne généralement assez bien.

E-mails

Les e-mails sont par défaut envoyés en clair. Ils passent par votre réseau local, internet et les serveurs de courrier de chaque correspondant. Autant dire que l’on part de loin.

On peut communiquer en SSL avec son serveur mais si ca protège une partie de la communication, le serveur peut encore lire vos messages et vous n’avez aucune garantie sur la suite du chemin (votre correspondant n’a pas l’obligation d’utiliser une communication chiffrée avec son serveur et tous vos messages passeront alors en clair sur le réseau). Mais SSL protège le mot de passe de votre compte, c’est déjà ça !

La solution souvent conseillée est d’utiliser GnuPG pour chiffrer le contenu des messages. Le problème de cette solution c’est que le champ « sujet » des mails reste toujours en clair. On pourrait mettre des sujets bidons mais je n’imagine pas la galère pour classer ses emails !Donc pour un usage courant, c’est horrible à utiliser. Pour échanger un document confidentiel de temps en temps, ça devrait bien fonctionner.

Messagerie instantanée

XMPP semble être devenu le standard de la messagerie instantanée. Il utilise un modèle client/serveur décentralisé comme les e-mails. C’est vrai que c’est le meilleur modèle que l’on ait actuellement pour fonctionner avec les samrtphones (restrictions de volume de données, consommation énergétique à préserver, pas d’adresse IP publique).

Même constant qu’avec les serveurs e-mails, On peut communiquer en SSL avec son serveur mais si ca protège une partie de la communication, le serveur peut encore lire vos messages et vous n’avez aucune garantie sur la suite du chemin (votre correspondant n’a pas l’obligation d’utiliser une communication chiffrée avec son serveur et tous vos messages passeront alors en clair sur le réseau). Mais SSL protège le mot de passe de votre compte, c’est déjà ça !

GnuPG serait ici plus pratique car il n’y a pas le problème du « sujet » en clair. Mais je n’ai pas trouvé de client XMPP pour Android qui le gère.

OTR est un nouvel modèle de chiffrement pour les échanges de messages synchrones. L’idée est d’utiliser des clés de chiffrement temporaires à conversation. Avantage par rapport à GnuPG : Si un espion a enregistré au préalable vos conversations chiffrées et qu’il tombe un jour sur votre clé privée, il ne pourra pas déchiffrer vos conversations du passé (vu que des clés temporaires qui ont été utilisées pour les chiffrer ont été jetées). C’est une belle idée mais dans la réalité :

• votre historique est conservé en clair sur le même terminal qui contient votre clé privée. Donc un espion trouverait les deux ensemble.
• si l’espion récupère votre clé privée et celle de votre correspondant, il peut alors déchiffrer vos conversations du passé.
• mais surtout  : il est impossible d’envoyer des messages à un correspondant hors ligne (car il faut négocier une clé partagée temporaire avant toute nouvelle conversation). Ce qui rend ce modèle inutilisable en pratique à mon avis si on n’est pas connecté 24/24 à sa messagerie instantanée.

Conclusion

Rien de marche pour l’utilisateur lambda qui n’a rien à cacher. Les emails chiffrés sont impossibles à classer. Les messages instantanés hors ligne sont illisibles.

Original post of Tuxicoman.Votez pour ce billet sur Planet Libre.

SeaMonkey 2.24 n’aura passé que trois jours en version bêta. SeaMonkey 2.24 bêta 1 n’est sorti que le 3 février. Cette version 2.24 de SeaMonkey est parue deux jours après le lancement du train de sorties des logiciels de Mozilla auquel elle se rattache. Basé sur le même moteur de rendu de Mozilla, Gecko 27, que Firefox 27.0, SeaMonkey 2.24 est disponible en 26 langues dont le français pour Windows, Mac OS X et Linux. Cette nouvelle version majeure (style développement rapide) comprend, pour la première fois, les nouveautés majeures suivantes (liens ajoutés par le traducteur) :

• Les préférences du Do Not Track (Ne pas me pister) et l’invite avant de supprimer les traces sont maintenant synchronisées.
• Une préférence (mailnews.p7m_external) a été ajoutée pour permettre aux utilisateurs de choisir un autre traitement d’application/pkcs7-mime.
• Le support des extensions Atom pour les fils de discussion (RFC 4685) a été ajouté.
• La migration des profils de Thunderbird supporte désormais le nouveau format de fichier signons (identifiants de connexion). Le support de l’ancien format est abandonné.
• Les listes déroulantes avec saisie semi-automatique (par exemple utilisée dans la barre d’adresse et dans la boîte de dialogue d’ouverture d’une adresse) affichent désormais des favicons pour leurs entrées.
• Le nom du compte est maintenant affiché dans la barre d’état pour tous les messages lors de la vérification de courrier.
• Les messages d’alerte IMAP montrent maintenant le serveur du compte de messagerie correspondant.
• Les noms des groupes de discussion sont désormais recherchés pour toutes les chaînes de recherche combinées (recherche-AND) dans la boîte de dialogue d’abonnement.
• Retrait du support de l’importation des identifiants de connexion au format signons.txt hérité, y compris la conversion en Base64.
• Activation du support de TLS 1.2 (RFC 5246) par défaut.
• Ajout du support du protocole SPDY 3.1.
• Ajout de la possibilité de réinitialiser les feuilles de styles à l’aide de 'all:unset'.
• Ajout du support des fieldset avec défilement (prise en charge de la propriété overflow).
• Implémentation de la directive allow-popups pour sandbox d’iframe, permettant une sécurité accrue.
• Suppression des préfixes des mots-clés de curseur en CSS - moz-grab et -moz-grabbing (saisir).
• Ajout du support des générateurs ES6 dans SpiderMonkey.
• Implémentation du support pour la fonction mathématique Math.hypot() dans ES6.
• Ajout du support de la ligne pointillée sur Canvas (HTML5).
• Correction du rendu du contenu Azure/Skia sur Linux.
• Correction de plusieurs problèmes de stabilité.

SeaMonkey 2.24 corrige également onze failles de sécurité dont quatre critiques.

La page des nouveautés dans SeaMonkey 2.24 des notes de diffusion mentionne d’autres corrections de bogues pendant la phase de développement et de tests de ce SeaMonkey. Pour davantage de renseignements sur les bogues corrigés et les nouveautés de ce train de sorties, voir les notes de diffusion de Firefox 27.0.

Si vous disposez déjà de SeaMonkey, vous avez dû recevoir une notification de mise à jour automatique dans les 24 à 48 heures. Vous pouvez aussi l’obtenir manuellement en choisissant « Rechercher des mises à jour… » dans le menu « ? ».

Original post of mozillaZine-fr.Votez pour ce billet sur Planet Libre.

J’aurais du m’y coller plus tôt, mais faute de temps, me voila maintenant :

La beta 3 de la SME Server 9 is out avec un lot immense de nouveautés mais c’est à vous de juger bien sur :)

Maintenant je tenais à vous montrer la SME en chiffre car les commits sont étudiés par des sites qui permettent de voir l’activité et la viabilité d’un projet open source. Vous trouverez sur le site Ohloh une analyse  du développement depuis 2005.

Le verdict est : Hight activity 

In a Nutshell, SME Server…

• …
  has had 13,414 commits made by 30 contributors
  representing 75,341 lines of code
• …
  is mostly written in shell script
  with an average number of source code comments
• …
  has a well established, mature codebase
  maintained by a large development team
  with increasing Y-O-Y commits
• …
  took an estimated 19 years of effort (COCOMO model)
  starting with its first commit in June, 2005
  ending with its most recent commit 7 days ago

Vous y verrez quelques graphes intéressants, je vous laisse le plaisir de les découvrir.

Vous pourrez convenir que votre futur serveur qui vous accompagnera dans votre vie numérique (web, mail, vpn, samba, contrôleur de domaine,….) n’est pas un projet mort, mais un projet qui vous attend.

• la liste des addons ou contribs installables d’un coup de « yum install »
• la documentation
• le forum Français (une très grosse partie de la communauté est Française)

Bon quoi de neuf en fait, et bien tout :  Koozali SME Server arrive.

Original post of Stéphane de Labrusse.Votez pour ce billet sur Planet Libre.

Voici un petit tuto très succint pour mettre en place rapidement une authentification LDAP. Je ne m’attarderai pas sur la sécurité, la réplication etc…

On part d’un serveur vierge, avec le réseau configuré. Si votre domaine DNS c’est toto.local, le DIT LDAP sera dc=toto,dc=local. Pour moi ce sera dc=morot,dc=fr C’est parti :


apt-get install slapd ldap-utils>


On met en place nos OU qui contiendront les utilisateurs et les groupes (faire un control+D à la fin de la saisie) :

ldapadd -x -W -D cn=admin,dc=morot,dc=fr

dn: ou=People,dc=morot,dc=fr
objectClass: top
objectClass: organizationalUnit
ou: People

dn: ou=Groups,dc=morot,dc=fr
objectClass: top
objectClass: organizationalUnit
ou: Groups

On ajoute une première entrée :

ldapadd -x -W -D cn=admin,dc=morot,dc=fr
Enter LDAP Password:

dn: cn=Julien Morot,ou=People,dc=morot,dc=fr
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
userPassword: {SSHA}SECRET
givenName: Julien
sn: Morot
cn: Julien Morot
displayName: Julien Morot
uidNumber: 1026
gidNumber: 100
uid: julien
mail: julien@morot.fr
gecos: Julien Morot
loginShell: /bin/bash
homeDirectory: /home/julien

adding new entry "cn=Julien Morot,ou=People,dc=morot,dc=fr"

Le mot de passe SSHA est généré par la commande slappasswd.

On passe au client :


root# apt-get install libnss-ldap libpam-ldap nscd


Debconf pose un certain nombre de questions à adapter par rapport à votre DIT :

• URI : ldapi:/// ldap:///localhost:389 ldap:///nom.domaine:389
• Base de recherche : dc=morot,dc=fr
• LDAP Version : 3
• Make local root Database admin : yes
• Does the LDAP database require login : No
• LDAP account for root : cn=admin,dc=morot,dc=fr
• LDAP root account password : celui indiqué à l’installation du package slapd

Maintenant que les packages sont configurés, il faut indiquer à NSS et PAM de les utiliser :
/etc/nsswitch.conf :

passwd: ldap compat
group: ldap compat
shadow: ldap compat


Vérification :

root# getent passwd |grep julien
julien:x:1026:100:Julien Morot:/home/julien:/bin/bash


Dans le fichier /etc/pam.d/common-session, on ajoute un module PAM qui se charge de créer le répertoire personnel de l’utilisateur s’il n’est pas présent :

root# grep -v '^#' /etc/pam.d/common-session

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session required pam_unix.so
session optional pam_ldap.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022

C’est terminé!

Original post of Morot.Votez pour ce billet sur Planet Libre.

Une bonne vidéo de Jeremy Zimmermann.

Je résume ici quelques arguments qui m’ont frappé:

- Parler d’Universalité du Net plutôt que de Neutralité du Net. Cela veut dire un accès égal à tous.

- La surveillance de masse jusqu’aux moindre recoins de ce qui vous entoure (enregistrement des déplacements, des mails privés, des coups de téléphones, de vos notes persos, bientôt votre santé, etc…) viole votre intimité. Même si vous n’avez rien à cacher, vous savez que tout ce que vous pensez tout bas sur vos notes, les gens que vous voyez, ce que vous évoquez tout bas à vos amis, le sport que vous ne faites pas est enregistré et pourra être retourné un jour contre vous. C’est la liberté de conscience qui est atteinte. Il n’y a plus d’intimité personnelle avec la surveillance de masse.

- Le coût de la surveillance de masse est grand, le coût du secret de masse est grand également (protéger un crime d’état par exemple). Si on élève ces coûts en chiffrant nos données et en révélant les secrets les moins bien gardés, ils deviendront intolérable pour l’économie de nos gouvernements qui feront machine arrière. Quelle société voudrait et pourrait payer un flic dans le dos de chaque citoyen?

- Si vous ne voulez pas asservir un tant soi peu la technologie à votre volonté (logiciels libre) ce sont les maîtres de ces technologies qui vous asserviront (Apple)

- La surveillance de masse n’a aucun impact avéré sur le terrorisme (pourtant le crédo utilisé dans 100% des cas pour la justifier). Cependant il est utilisé pour l’espionnage politique (téléphone de la chancelière allemande, ordinateur personnel de la présidente du Brésil) et économique (employés de Petrobras, lignes Alcatel/Wanadoo/Belgacom sur écoute), ce qui est intolérable et crée une asymétrie de pouvoir des surveillants sur les surveillés.

- Les données privées seront utilisées pour faire pression contre vous. Google sait quelque chose sur votre privée que vous ne voudriez pas que votre patron, copine,etc.. sache. Quelqu’un ayant ces infos peut donc faire pression sur vous un jour ou l’autre si vous ne voulez pas que ce soit révélé.

- Lorsque l’on livre ses données personnelles à un cloud espionné par la NSA (Google, Facebook, Microsoft) cela engage notre vie mais aussi celles de nos amis (nos photos contiennent aussi le visage de nos amis, les mails contiennent aussi les messages de nos amis, notre carnet de contact contient aussi les coordonnées de nos amis) et ces amis n’ont pas forcément envie de se voir ficher. Pensez-y.

Original post of Tuxicoman.Votez pour ce billet sur Planet Libre.