Tag "software"

Blackphone - Pure US product

Par SwissTengu @SwissTengu @SwissTengu — 2014-03-25T06:59:23
"The Blackphone is out", "The Blackphone will save your privacy".

Yeah, right. We can see this on every web page. Of course, nowadays, with the NSA and other "nice" people caring about our security and integrity, this Blackphone seems promising. Data servers are in Switzerland and Canada, which seems cool and fancy.

More over, fact it involves Silent Circle, created by Phil Zimmermann, seems to make it legit. Well… Really?

Let's have a closer look at this Miracle of Privacy.

Hardware

Here, nothing to say: the hardware description doesn't provide any information regarding its openness. Nevertheless, two thing will still be closed: the baseband OS and SIM OS. Imagine an OS embedded in your phone you can't access at all nor monitor. How great, right?

More over, this blackbox is managing all you mobile communication. Meaning it can send and receive data without your knowledge.

This means just one thing: the Blackphone won't do anything in order to correct this bad point (or back door).

Software

Here, it's a bit more funny: the Blackphone embedded a lot of things from Silent Circle. After a quick scan on their web site, we can just see one thing: nothing is free (though 2 years are offered for free when you buy the Blackphone), nothing is opened. So we should just trust them? OK, Mr ZImmermann is "someone", but hey… If we had to learn ONE thing from all the Snowden stuff: never trust anyone.

Operating system

On this side : nothing. No source. No information regarding its openness. Once again, "trust us". Guys, seriously… This won't do it. This is not the way to go.

Alternatives

Of course, we have some ways to get a smarter phone: custom roms like AOKP, Slimroms, Pac-rom or Cyanogenmod are widely available. They are opened, meaning community can get a hand on them, dig inside the code in order to ensure nothing bad is hidden in there. They are free, meaning you won't need to pay anything (but donation are welcomed).

More over, most of them come without any bulky application installed: you get a vanilla android, with some customisation like a better control centre, or the ability to blacklist number or even the ability to override application permissions in order to get a quiet phone.

If you want to go fully open source, you may as well go away from Play and gapps services, and use some alternate market like f-droid.org, which provides only open sources applications.

Just to show you the possibilities:

Silent Text, using some monthly or annually subscription, using US servers and so on, may be replaced by the following applications:
- TextSecure, from Whispersystems
- Kontalk, an open alternative under heavy development
- Threema, closed source application developed by Kasper Systems GmbH, a 100% Swiss company

Silent Phone may be replaced by RedPhone, also developed by Whispersystems. There is also the OSTel service available, which provide encrypted SIP service for free. This one is backed up by the GuardianProject.

All of those (except Threema) are free and opened. And, for what we can tell, the security of most of them is controllable.

So, ready to pay more than 600USD for some closed phone when you may install some opened ROM on your current mobile and install fully opened application ensuring your own privacy?

More »»

Catégories en relation

Watch out Permissions

Par SwissTengu @SwissTengu @SwissTengu — 2014-03-25T06:59:30
The permissions. You know, the stuff nobody really reads. The stuff you just accept, like the EULA and other boring contracts.

But, in fact, you really should read them. They should make you think twice when you're installing some stuff. For example, why should a game get access to your phone identity? Or your contacts?

Fact is, developers and editors will convince you they really need those accesses: "it will help us to debug the app if you get problems", "easy support", "help you comparing your score with your contacts" and so on.
How nice. How innocent. But, really, do you believe them? Do you really think the phone IMEI is really needed in order to improve the application?

This becomes even more interesting when you deal with public services app. In Switzerland at least, they are all closed. Unavailable outside official app stores, and requiring a lot of weird access, as this one for example.

Hopefully, some Android alternative ROMs offer the possibility to set up permission after the app installation. For example, Slimroms allows you to set either system or user apps permission. Problem is: this may be set up only after the app installation, meaning it may send out information without your consent before you lock them down.

Permissions is the only (easy) way you may prevent unauthorized access to your data — current systems don't allow you to chose what you really want to allow at the installation. This is why you really should consider reading and understand them before you click "install".
Of course, all devs and editors aren't bad guys. But in the current situation, WHO do you want to trust? WHO deserve to be trusted? Not so many people I think. You may as well sign some pact with the Devil instead of accepting without a glance the permissions we want to force.

The only acceptable solution would be:
- at least allow to disallow permissions at the installation time (with some warning letting you know/understand this may break some part of the app)
- at least, explain WHY the app needs those rights.

Some already do explain the rights they need. This should be the case for all of the existing app.

Maybe, if everybody reads the permissions, and just act with intelligence, asking "why the hell do they need this?!" to the right person, this will change. It has to change. Nobody can be trusted, and they still try to get more and more information on you.

Raise up people, spread the word, don't accept the current situation! Because it is unacceptable.

More »»

Catégories en relation

Digital self defense cookbook - Part I

Par cta @christiantanner @christiantanner — 2014-03-27T14:18:50
By now it should be clear to everyone that any information - voice, text, image, video, any combination of the above, basically anything - sent over the vast expanse of the public internet will be copied and stored by various interest groups. Be they telecom operators (for quality assurance purposes or due to regulatory demands), private companies (with whom you explicitly or implicitly share the information or who buy the data) all flavours and colours of national and international security agencies, as well as criminals of all walks of life.

This sucks. Particularly the bit about our government agencies who have turned the principle of trust upside down. Be that as it may: what can we do? Can we even do something? Anything? Yes, we can! The magic word is encryption. Preferably encryption which is not based on the principle of security by obscurity, but rather based on tried and tested, free, public, open source solutions. So here's a little primer of selected programs and apps that can help you keep your private data - and conversations - private.

Email: Gnu Privacy Guard (GPG), free opens source version of PGP (pretty good privacy). Comes with good command line support and integrates well into Thunderbird using the Enigmail Plug-In. Also works on Mac (via GPGTools) and Windows (via GPG4Win). Also works on Android (via K9 Mail and APG).

Caveat: Choose a strong password (more on those at a later point in time). Keep your password safe (for the love of all that is good and true: KEEP YOUR PASSWORD SAFE). And keep your private key safe, too!

Data: Truecrypt. While the software is free and open source, the development process is not entirely so, however it is currently undergoing a very thorough review. Truecrypt can encrypt entire volumes, or generate so called Truecrypt containers which for all intents and purposes function like normal storage devices. Except obviously for the fact that data is encrypted. Also works on Windows and Mac (which is one of the main selling points). It gives you the possibility to create so called hidden volumes within a Truecrypt file, which brings us into the slightly worrying territory of plausible deniability, a concept more relevant in totalitarian countries (in short, you use two passwords: one unlocks the normal volume, the other the hidden one. So should you ever be forced to give up your password [in the UK, for example, you can be imprisoned without trial for not giving up your password], you give the one for the normal volume. There is no way to prove that a hidden volume exists within the same file).

Again: Choose good, strong, unique passwords and keep the suckers SAFE!

Chat: XMPP OTR (yeah, we do love our acronyms, don't we!) Extensible Messaging and Presence Protocol Off The Record. XMPP was originally called Jabber. Popular clients are Jitsi (GNU/Linux, Mac and Windows), Adium (Mac), Gajim (BSD; GNU/Linux, Windows) as well as ChatSecure (formerly known as Gibberbot) on Android (and iOS). ChatSecure is part of The Guardian Project which will be mentioned a few more times in this and upcoming articles.

Voice: OSTEL (again, part of The Guardian Project) uses ZRTP (an upgrade to SRTP [Secure Real-time Transport Protocol]) for voice communication. Popular Client software is (again) Jitsi on GNU/Linux, Mac and Windows and CSipSimple on Android (paid solutions exist for iOS devices and Blackberry).

That's it for a start. More on encryption, passwords, obfuscation and other things at a later time.

More »»

Catégories en relation

De l'ouverture des applications issues des services publics

Par SwissTengu @SwissTengu @SwissTengu — 2014-03-28T10:19:19
En Suisse, il y a beaucoup de services publics.

Une grande majorité est accessible en ligne, et des applications pour mobiles (smartphones et/ou tablettes) commencent à devenir courante. Une preuve d'ouverture aux nouvelles technologies, permettant d'atteindre plus de citoyens à travers le Réseau.

Seulement, il y a un problème : ces applications ne sont accessibles que via les "stores" dédiés à votre OS (GooglePlay, iTunes/AppStore etc). Et, en fait, aucune de ces applications n'est opensource à l'heure actuelle.

Pourtant, pour des applications issues des services publics, accessibles publiquement, payées par les deniers publics (aka les impôts), il semblerait normal que les applications mobiles soient ouvertes et librement accessibles par tous les moyens possibles.

Nous nous sommes permis de contacter certains des services fournissant une application de qualité : Meteosuisse, et les CFF.

Les premiers nous ont laissé entendre qu'il était impossible de sortir l'application des "markets" officiels, du fait qu'elle utilise certaines fonctionnalités propres aux plate-formes des fabriquants, telle que le GCM, permettant de pousser les alertes sur les appareils.

Une solution élégantes serait de permettre à l'application de passer dans un autre mode, à l'image de Threema, qui permet de se passer complètement des services des plate-formes de distribution.

Il semblerait aussi que l'application utilise une API fermée, à laquelle le public ne peut pas accéder. Pour un service public, payé par nos impôts, c'est un peu fort de tabac, non ?

Les CFF, de leur côté, on plutôt fait valoir les problèmes qu'une distribution en-dehors des "markets" poseraient au niveau du support utilisateur. Ils ont aussi insisté sur le fait qu'ils ne proposent pas de support quand on utilise une ROM alternative (ils ont cité CyanogenMod uniquement — il serait drôle de les contacter pour un problème et de leur parler de, au hasard, Slimroms, ou Paranoidandroid…).

On peut aussi parler des applications de la RTS, dont certaines utilisent aussi les outils fournis par les plate-formes officielles et ne permettant pas de s'en passer.

Quels sont les problèmes que cela pose aux utilisateurs ?

Oui, quels sont les problèmes ? Après tout, on n'a pas à se plaindre, les applications sont gratuites, accessibles par une majorité des utilisateurs… Mais aussi, elles forcent les utilisateurs à rentrer dans le moule : avec cette politique, un utilisateur ne pourra pas satisfaire son besoin de maîtriser l'OS de son smartphone (en installant une ROM alternative) et continuer d'accéder à des services publics, pour lesquels il continuera néanmoins à payer au travers de ses impôts, taxes etc.

Certains signaleront qu'on paie pour le chômage sans forcément en bénéficier. Certes. Mais comparer les deux (un service public disponible de toutes façons gratuitement) et les assurances sociales, c'est un peu capilotracté.

De manière à remettre les citoyens au centre, leur permettre de reprendre en main les technologies, il serait temps que les services publics fassent deux choses :
- ouvrent le code source de leurs applications
- fournissent les binaires directement sur leurs sites

L'ouverture du code source permettra différentes choses, comme par exemple une participation des citoyens au développement de l'application, que ce soit au niveau de la correction des bugs ou l'ajout de capacités. Elle permettra en outre aux utilisateurs avancés de pouvoir la compiler pour leurs appareils, même s'ils ne sont pas officiellement supportés. En outre, un contrôle citoyen de ce que fait l'application n'est jamais inutile.

Fournir les binaires directement depuis les sites permettra aux personnes désirant sortir des petites cages dorées que sont les appareils mobiles, tout en continuant de bénéficier des applications. Ce point est important : actuellement, pas mal de personnes rechignent à faire le pas vers la liberté justement parce que certaines applications ne leur seront plus accessibles. Certes, pas mal sont issues du secteur privé, mais cela ne doit pas empêcher les services publics de faire le bon choix, et de laisser la liberté aux citoyens.

On peut féliciter les quelques applications (web) dont le code source se trouve sur github. Il faudrait que toutes les applications de nos administrations publiques se retrouvent ainsi en ligne.

More »»

Catégories en relation

Swiss Android phone users! Get your phone back

Par rachyandco — 2014-03-29T18:13:59
You want to be able to use your phone in Switzerland without using Google?

Possible but still difficult:

This article is for educational purposes only. There is no guarantee that this will work! You might loose all your data!!! please do backups!!! You might burn your phone!!! Use this page at your own risk. This might not be 100% legal...

1. Backup all your existing data


if you don't care or your phone is new, go to step 2.

- list all your apps.
- save your contacts and calendar in your google account
- save all extra data you have (pics, vids, music)

Install a new Android


cyangenmod install

Calendar and Contacts



Download some apps that should be free



RTS Radio
[url=http://apkleecher.com/apps/201...]RTS En ligne Directe[/url
[url=URL]…[/url
[url=URL]…[/url
[url=URL]…[/url
[url=URL]…[/url
[url=URL]…[/url


More »»

Catégories en relation

SmartTV vs SmartUsers

Par SwissTengu @SwissTengu @SwissTengu — 2014-04-14T04:55:03
C'est pratique, hein, une TV connectée. Une app à installer, et on a accès à un catalogue de vidéos. Sans parler du contrôle de la TV depuis son smartphone, ou que sais-je encore.

Mais, comme d'habitude, on perd de vue 1-2 choses, devant le côté pratique de ces appareils… Chaque fois qu'on nous simplifie la vie, il faut se demander "pourquoi". Qu'est-ce que les constructeurs ont à gagner, réellement, en offrant telle ou telle fonction ?
Et, plus particulièrement, "comment la financent-ils ?"

On l'a déjà vu passer sur le Net : certains constructeurs ne sont pas très au fait de la sécurité, permettant ainsi des fuites de données depuis leurs TV1.

"Mais… une TV ne possède aucune donnée ?!"
Oui, mais, en fait… Si : vos goûts, vos horaires voire, si votre TV possède une caméra2, votre image3, votre logement. Autant d'informations pouvant intéresser du monde et, comme vous le verrez, pas forcément que les constructeurs…
Sans parler même du fait que ce genre d'appareil va se mettre à l'écoute de votre réseau pour :
    découvrir les différents services (DLNA4, ça vous parle ?)
    découvrir vos partages windows (protocole SMB5)
    … sans doute d'autres choses du genre, pour vous simplifier la vie, évidement
De même, il accédera à Internet pour effectuer ses mises à jour. Entre autres.

"Oui mais, enfin, ça leur rapporte quoi ?"
Savoir que tel ou tel film/série/documentaire a été vu par telle catégorie de personnes (le modèle de votre TV fixe le prix donc, potentiellement, votre classe sociale) peut représenter un intérêt certain. Une interaction "future" serait, pourquoi pas, trouver le meilleur moment pour vous balancer une publicité susceptible de vous intéresser (la caméra peut remonter votre niveau d'attention en fonction de vos yeux, de ce que vous faites etc).

":( … et qui d'autre pourrait être intéressé ?"
Si la TV remonte votre activité (i.e. si vous êtes là ou non), vu le niveau de sécurité de la majorité des réseaux domestiques (et d'entreprise…), un simple sniffing permettrait de savoir de façon précise si vous êtes chez vous, si vous êtes là à certaines heures uniquement (et lesquelles) etc. Le genre de personne intéressé par ça : démarcheurs, cambrioleurs etc6
Oh, et, bien entendu, l'organisme chargé de percevoir la redevance TV, tant qu'on y est : imaginez la simplicité de savoir si vous avez un écran juste en voyant passer ce que ce dernier leak comme informations… (Bon, en vrai, la modification de la LRTV fera que tout le monde paiera la redevance7 — on reviendra d'ailleurs sur 2-3 points).

"Mais pourquoi on ne nous avertit pas à l'achat ??"
Simple : qui s'en soucie, réellement ? Pourquoi se tirer une balle dans le pied en avouant que la sécurité a été mise de côté pour réduire les coûts de développement, pourquoi laisser entendre que des contrats pouvant potentiellement mener à l'exploitation de données collectées à votre insu ont été passés ?

De toutes façons, vous n'avez rien à cacher, si ? ;)

Moralité : avoir un appareil intelligent, c'est bien. Mais à condition que nous, utilisateur final de l'appareil en question, soyons plus intelligent que lui.

More »»

Ressources en français

Par kl4v @subtruth @subtruth — 2014-05-01T21:27:56

Lors de la dernière CryptoParty à Fribourg, un manque de ressources en français a été déploré. En voici quelques unes:

Si vous connaissez d'autres bonnes ressources en français, ajoutez-les dans les commentaires!

Au contraire, il serait intéressant de répertorier aussi les mauvaises ressources - comme par exemple bon nombre d'articles de la presse mainstream.

More »»

myEnigma — quelques précisions

Par SwissTengu @SwissTengu @SwissTengu — 2014-05-22T05:57:35
/static/images/myEnigma.png

myEnigma1 est une application suisse permettant, un peu comme Whatsapp, d'échanger des messages, images et documents avec ses contacts. L'avantage par rapport à Whatsapp est qu'elle est suisse, à priori chiffrée, et que les serveurs sont localisés en Suisse.

J'ai pu obtenir une interview de l'entreprise Qnective AG2, société basée à Zürich.

Les questions posées couvraient les points suivants :
  • Sécurité : quelles sont les mesures prises face aux failles type Heartbleed, s'ils s'étaient fait attaquer, etc
  • Statistiques : comment est employée l'application, où, combien, etc
  • Plans futurs
  • Légal : si le gouvernement a émi des demandes d'accès, logs, etc
  • Divers questions d'ordre plus générale
  • Utilisation (j'ai pu faire quelques tests)

Sécurité
Malheureusement, ils ne sont pas très communicatifs, principalement au niveau de la sécurité présente autour de leurs systèmes…
À chaque fois, j'ai reçu un « on ne partage pas d'information sur nos mesures de sécurité », ce qui, de nos jours, peut être mal vu. Les questions couvraient Heartbleed, TLS, les attaques qu'ils auraient subies — mais aucune communication n'est faite à ce niveau.
Un white paper3 est disponible et explique 2-3 choses, mais reste très vague quant aux algorithmes et librairies employées. Sur le papier, cela semble tout de même solide (modulo la partie en rapport à TLS qui, dernièrement, a montré quelques faiblesses4

La seule chose obtenue à ce niveau concernait l'ouverture du code source à des fins de « community review », mais je doute que cela se fasse. La réponse elle-même est ironique par rapport à la constatation précédente :
Trust is mainly related to the people behind an application. Our business model is based on providing secure mobile communication. We consider to open source as soon as patents are not impacted.
« La confiance dépend principalement des gens derrière l'application. Notre business model est de fournir des communications mobiles sécurisées. On pourrait ouvrir les sources dès que cela n'impactera pas des brevets »

La confiance… Tout est là.

Statistiques
Je n'ai pas pu obtenir de statistiques par rapport au nombre d'utilisateurs ou même le nombre de messages transitant sur leurs serveurs… Par contre, il semblerait que myEnigma soit principalement employé en Allemagne, Suisse, Italie et Espagne. Le Brésil et d'autres pays d'Amérique du Sud semblent intéressés, ce qui fait que l'application sera traduite prochainement en espagnol et portugais.
Mais pas en français, par contre…

Futur
Pas de dates annoncées, mais pas mal de nouvelles fonctionnalités devraient venir durant l'année : emoticon pour la version Android, ainsi qu'un nouveau design sont actuellement en cours de développement.
Aussi, l'application est actuellement gratuite, mais une notion de licence (« free » pour le moment) au sein de l'application, ainsi qu'une mention de coût et de modification à ce niveau dans la FAQ m'a fait poser la question pour avoir plus de précisions.
Ils considèrent plusieurs modèles économiques, le principal étant un abonnement annuel qui, je cite, « ne dépassera pas le coût d'une tasse de café (Starbucks exclu) ». Donc compter une thune par année environ.

Demandes légales
Pour le moment, ils n'ont reçu aucune demande légale au niveau des communications. De plus, le chiffrement se faisant au moment de l'émission du contenu, ils n'ont à priori aucun moyen de savoir ce qui transite sur leurs serveurs.
Au niveau des logs, ils ne semblent pas être soumis aux lois sur les télécommunications, parce qu'ils ne se considèrent pas comme étant un fournisseur de service de télécommunication… Sur ce point, je suis dubitatif, je l'avoue.

Divers
Pour les utilisateurs d'Android découplés de Google, l'application est disponible sur demande en-dehors de Play. Il suffit d'en faire la demande par email5 au support.
Bon point. Bien qu'un lien de téléchargement disponible directement sur le site serait nettement plus    pratique à mon sens…

Par contre, du fait qu'ils sont en train d'implémenter le support de GCM6, il faudra peut-être s'attendre à ce que l'APK ne soit plus disponible, à moins qu'ils ne laissent l'ancien mode disponible pour les « déconnectés ». Ce qui serait logique.

Aussi, les messages ne sont pas conservés sur les serveurs : du moment qu'ils sont délivrés, ils sont effacés. Ce qui, au passage, empêche d'avoir le même compte sur de multiples appareils.

Utilisation
J'ai un peu tester l'application. Le problème premier a été de trouver un contact possédant aussi cette application : parmi mes contacts, très peu (4) sont sur l'application. Et, de ce que j'ai pu remarquer, aucun de ces contacts ne semble encore employer myEnigma.
Ce premier problème résolu (merci François), l'utilisation est relativement simple. L'interface demande effectivement d'être revisitée et améliorée pour rendre les choses plus simples et plus compréhensibles.
L'application est assez fluide. On a moyen d'activer des logs pour voir un peu ce qu'il se passe. Cela permet de savoir à quoi on se connecte, mais pas vraiment plus à première vue.
M'enfin, ça m'a permis de déterminer qu'ils utilisent un certificat SSL signé par SwissSign, société suisse appartenant à la Poste Suisse — ce qui, en soit, est un détail, mais je trouve que c'est une bonne chose.

Pour ma part, je préfère une autre application (dont je parlerai dans un prochain article) — mais il faudra surveiller les améliorations, principalement au niveau interface.

En conclusion : myEnigma a du potentiel. Si tant est qu'on ait un accès un peu plus grand aux informations de sécurité. Et que l'interface soit revue et simplifiée.

More »»

Threema — détails et informations

Par SwissTengu @SwissTengu @SwissTengu — 2014-06-02T06:32:55
/static/images/threema.png
Threema est une application de communication sécurisée. Dans le même genre que myEnigma, elle permet d'échanger des messages, images et documents de manière sécurisée, les contenus étant à priori chiffrés.

J'ai pu obtenir quelques informations de plus de la part de l'éditeur, Threema GmbH1, société suisse, dont les serveurs applicatifs dédiés à Threema sont localisés en Suisse.

Les questions couvraient les points suivants :
  • Sécurité : quelles sont les mesures prises face aux failles type Heartbleed, s'ils s'étaient fait attaquer, etc
  • Statistiques : comment est employée l'application, où, combien, etc
  • Plans futurs
  • Légal : si le gouvernement a émi des demandes d'accès, logs, etc
  • Divers questions d'ordre plus générale

Sécurité
Bonne nouvelle, Threema n'utilise pas de version d'OpenSSL affectée par Heartbleed. De même, le mode de fonctionnement n'implique pas d'authentification par certificat SSL, ce qui exclu aussi la petite faille dans le protocol TLS2.
Aussi, ils ne semblent pas avoir encore subi d'attaques « concertées » dirigées spécialement sur leurs services. Selon Manuel Kasper, à part le « bruit habituel d'Internet » (scan, tentatives de connexion SSH et autres du genre), ils n'ont rien remarqué.

Aussi, ils ne considèrent pas encore ouvrir le code source à des fins d'audit communautaire, et ce principalement à cause du modèle économique de l'application.
Par contre, il semblerait que cela n'ai pas empêché une analyse approfondie du fonctionnement de Threema3, ainsi qu'une validation des processus de chiffrement.

Statistiques
Threema possède environ 2.8 millions d'utilisateurs, et environ 40 millions de messages transitent quotidiennement sur leurs serveurs.
La majorité des utilisateurs provient de l'Allemagne, suivi par la Suisse, l'Autriche et les USA.

Futur
Ils préfèrent ne pas annoncer les nouveautés avant de les sortie — mais ils travaillent sur des nouvelles fonctionnalités.

Demandes légales
Kasper System n'a pas eu de demandes d'accès. Ce qui, de toutes façons, ne ferait pas grand chose, vu que les messages et contenus sont, à priori, chiffrés.
Ils n'ont pas non plus modifié leur politique de logs4 (à savoir : rien n'est enregistré), ce qui est plutôt  bien.

Divers
À priori, Threema ne fait pas partie du « pack gouvernemental », ce qui est assez dommage vu la qualité de l'application.
Aussi, leur canal de communication est plus germanophone, ce qui explique qu'on n'en entend pas beaucoup en Suisse romande.

À noter aussi que Threema s'obtient, pour Android, en-dehors de Play5, ce qui permet en plus de payer en bitcoins !
De base, l'application utilise le GCM6, mais permet aussi de passer en mode « pull »: l'application va elle-même contrôler si des messages sont en attente à intervalle régulier (toutes les 15 minutes).

Conclusion
De manière générale, j'adore cette application : simple, efficace, elle permet de mettre à portée de tous une solution de chiffrement propre.
La validation de ses contacts permet en outre de s'habituer à contrôler soi-même « qui est qui ». À ce niveau, on est très proche de GPG/PGP, s'agissant de signer les clefs et de régler le niveau de contrôle effectué.

More »»

OnionShare — la fausse bonne idée

Par SwissTengu @SwissTengu @SwissTengu — 2014-06-04T08:22:21
On en parle dans certains milieux, comme "la" solution pour transmettre des documents confidentiels pouvant servir de base pour des leaks.

Mais une série de questions se posent :
  • Est-ce que cette solution est réellement bonne ?
  • Est-ce qu'elle répond réellement à un besoin ?
  • Est-ce qu'elle ne crée pas plus de problèmes qu'elle n'en règle ?
  • Quand, comment et dans quelles conditions employer cela ?
  • J'ai mon .onion, j'en fais quoi maintenant ?

Il y en a tout un tas d'autres, mais celles-ci sont sans doute les plus importantes, car elles souvlèvent 2-3 problèmes au niveau de la communication sur OnionShare1.

OnionShare, la bonne solution?
Oui et non : ça permet de simplifier la mise en place d'un service caché2 sur le réseau TOR, mais ne règle en tous cas pas l'extraction des données. Imaginez un Snowden en train de faire tourner TOR sur son ordinateur au boulot… Ou sur le laptop d'entreprise qu'on lui a fourni… Les réseaux contenant des données sensibles sont (normalement) surveillés de près, pour éviter des intrusions3 ou, justement, des fuites. Le cloisonnement des accès réseau est aussi de mise en général, tout cela mis bout à bout rend l'utilisation de TOR (ou tout autre service "bizarre") suspect aux yeux des administrateurs réseau, qui n'hésiteront pas à sonner la charge en cas de doute.

Employer TOR sur le réseau de son entreprise4, c'est le meilleur moyen de se faire déboulonner dans les 30 secondes qui suivent le lancement du service.Il convient donc de définir clairement le périmètre d'utilisation de cet outil.

Le besoin
Le besoin auquel est censé répondre OnionShare n'est pas clairement défini : "partagez des fichiers de manière sécurisée"… Cool. Mais dans quel contexte ? Comme expliqué plus haut, cette solution ne peut pas répondre au besoin d'extraire les documents. Elle ne peut répondre qu'à "envoyer les documents à des tiers", et ce uniquement une fois qu'on les a sorti de là où ils étaient avant.

À ce niveau, ne pas délimiter le besoin en présentant l'application peut avoir de graves conséquences pour l'utilisateur : s'il se dit juste "ah cool je serai anonyme via ça pour sortir des secrets de mon lieu de travail", il se foure le doigt dans l'œil. Le manque d'information concernant les risques pose un réel problème — problème qu'on retrouve dans la grande majorité des services et solutions techniques proposées ces derniers temps : quel besoin couvrent-elles réellement, et est-ce que ce besoin correspond bien au mien, dans quel contexte son utilisation ne m'expose pas plus que sans passer par elle… etc.

Les problèmes que cette solution pose
Comme précédemment dit, cette solution technique pose pas mal de problèmes : le contexte d'utilisation, le fait qu'on passe par de multiples couches logicielles qu'on ne comprend pas forcément, l'absence de guide et d'explications concrètes font qu'il serait mieux, à mon sens, de décourager l'utilsation d'OnionShare pour les néophytes. Le problème étant que, justement, OnionShare s'adresse aux néophytes…
Il est fort dommage de ne pas disposer d'une meilleure documentation de la part de l'auteur de ce script, qui se contente de balancer son projet sans aucun support réel.
C'est même criminel, en fait…

Contextes d'utilisation
Comme annoncé, cette solution ne s'utilise pas n'importe comment : de manière à éviter de se faire repérer, il conviendra de ne pas l'utiliser depuis son lieu de travail; à la rigueur depuis la maison, et encore. Aussi, on évitera de l'utiliser dans l'état sur une machine appartenant à son employeur… À moins de passer par Tails5, qui permet de s'isoler du système installé et de ne pas laisser de trace (du moins rien de flagrant).
Comme il s'agit tout de même de lancer un serveur web et de monter un nœud TOR, il faut faire les choses proprement : tenir compte des avertissements quant à l'utilisation de TOR (présents sur le site de TOR6) et de rester prudent.

Il faut garder en tête qu'OnionShare n'est pas un moyen de sortir les données. Vraiment. Sinon, on court droit à la catastrophe, avec en prime une décrédibilisation complète de TOR et des services associés… Certains diraient que c'est le but recherché, pour ma part je n'irai pas jusque là ;).

Bon, ok, j'ai pigé, j'ai un .onion sur un laptop chez un pote… et après ?
Après, il faut transmettre le lien. Pour ça, le mail est en général la manière la plus simple… Mais encore faut-il le faire correctement. Le README mentionne "Jabber7 et OTR8" — c'est une autre manière, permettant en outre de ne pas laisser de preuve flagrante.
Dans tous les cas, il faut chiffrer l'information avant de l'envoyer : que ce soit via GPG, S/MIME, OTR ou autres, balancer le lien de l'onion à travers le réseau sans capote, c'est tout aussi suicidaire que lancer OnionShare sur le réseau de l'employeur… Il vous faudra donc faire le nécessaire avant pour assurer la transmission de l'information. Et faire preuve de prudence…
Mais là encore, aucune information, pas le moindre indice quant aux possibilités, pas de lien vers des solutions logicielles permetant de se protéger la moindre.

En résumé
OnionShare est un outil. Comme tous les outils, il doit s'apprivoiser, se comprendre. En général, on lit le manuel d'utilisation, sauf qu'il n'y en a pas… Aussi, c'est un outil servant à se rendre plus discret sur la toile, son but premier étant de pouvoir mettre à disposition des fichiers de manière anonyme et sécurisée. Pas un simple presse-agrumes électrique. De cet outil peut dépendre la liberté si ce n'est la vie de personnes soucieuses de rétablir un peu de morale et d'éthique dans ce monde vérolé.
À ce niveau, OnionShare ne fournit PAS les garanties nécessaires, et ce pour plusieurs raisons :
  • il suffit d'aller voir les issues ouvertes9 pour se rendre compte qu'il n'est pas utilisable à l'heure actuelle
  • certaines issues sont critiques10, OnionShare partant du principe que TOR est ouvert à tous les vents
  • la documentation en rapport à l'installation de TOR est foireuse, torproject insistant lourdement sur le fait que les packages ubuntu/debian ne sont PAS à jour, et à éviter à tous prix
  • le fait de mentionner le simple fait d'installer TOR au lieu d'insister sur l'utilisation du Tor Browser Budle est un signe qui ne trompe pas : le public-cible n'est PAS les journalistes ou autres hacktivists débutants.

Le Tor Browser Bundle11 intègre tout, que ce soit un navigateur (Firefox), TOR et des configurations du tout pour assurer un minimum de sécurité. OnionShare aurait dû se mettre par-dessus ça. Et ne se baser que sur ça, en premier lieu. Et ne pas mentionner d'installer TOR sur le système. Et mettre les liens qui vont bien pour télécharger TBB, les liens vers la doc d'utilisation etc.

Même si OnionShare part d'une bonne idée et de bons sentiments, il ne faut surtout pas perdre de vue qu'actuellement, on ne peut pas se permettre de jouer les apprentis-sorciers. La surveillance généralisée est en place, et si on a des choses à sortir de quelque part, il faut s'attendre à ce que les issues soient sous surveillance, que ce soit au niveau du réseau ou les accès physiques.

Oh, et, en passant,  l'interface de gestion pour TOR Vidalia12) permet de créer des services cachés… OnionShare perd tout intérêt, à part pour la jolie page web qu'il crée (bon, et le proxy HTTP13 vers le service caché, ok).

Aussi, il vous faut garder ceci en tête : ce n'est pas parce que vous avez un joli marteau que vous saurez planter les clous droits. L'outil ne fait pas le boulot, il faut savoir l'utiliser. Les outils de cryptographie, d'anonimisation et assimilés sont exactement pareils.

Prêt à venir aux prochaines cryptoparties14 ? ;)

More »»

Catégories en relation

End-To-End : le pour, le contre et le truandage

Par SwissTengu @SwissTengu @SwissTengu — 2014-06-10T06:38:36
/static/images/EndToEnd-Icon.png
Google a créé le buzz ces derniers temps avec son plugin Chrome End-To-End1, permettant de chiffrer les mails dans leur interface webmail, en implémentant OpenPGP2 en javascript.
Rien que ça. Idée intéressante, "trendy" vu les révélations de Snowden et la poursuite de la collecte des données personnelles sous toutes ses formes.

Seulement, il convient de se poser quelques questions :
  • Quand on sait que la crypto dans javascript est pourrie, que penser de cette annonce ?
  • Quand on sait que la génération de nombres aléatoires en javascript est une plaie, que penser des clefs générées par ce biais ?
  • Quelle confiance peut-on avoir dans le navigateur conservant les clefs privées ?
  • Quand on sait que Google compte sur le contenu de vos emails pour « mieux vous connaître », « vous proposer les bonnes publicités », « améliorer votre expérience », que pouvons-nous penser de cette extension ?
  • Comment gérer l'utilisation de plusieurs appareils ? Après tout, la clef privée est dans votre instance Chrome sur votre laptop, comment faire pour employer ça sur votre desktop ?

On va tâcher de répondre à ces questions de manière précise. Ça risque de partir dans la technique, mais on va faire en sorte de rendre ces parties facultatives :).

/static/images/js-crypto.jpg
Javascript et la cryptographie : amour impossible ?
Le problème principal est le passif de Javascript : pas mal de personnes se sont cassées les dents en tentant de reproduire des algorithmes de chiffrement, qui se sont révélés vulnérables à différentes attaques3.

Aussi, il y a le problème de la transmission du code au navigateur, la connexion au serveur pouvant être compromise de multiples manières. À priori, ce problème précis n'existe pas avec l'extension End-To-End, puisque tout est embarqué dans le navigateur (si tant est que le téléchargement et l'installation de l'extension ne sont pas compromis ;) ).

Le principal problème avec End-To-End est le fait que les développeurs semblent avoir créé une nouvelle implémentation — il ne semblait pas exister de librairies répondant à leurs besoins au moment où ils ont démarré le projet.
Il faudra donc attendre un certain temps avant de pouvoir faire confiance dans cette nouvelle librairie (et je ne parle que de la librairie, pas de son utilisation), de manière à laisser le temps aux différentes communautés pour valider les implémentations, auditer le code correctement, etc.

À ce niveau, on peut saluer la transparence des développeurs qui mentionnent clairement, dès le départ, que ce projet est en version « alpha » et n'est pas encore utilisable dans l'état.
Donner plus de précisions quant aux raisons aurait été sympa, mais je pinaille un peu sur ce point.

Après, on peut aussi se pencher sur les problèmes de V8, le moteur javascript de Chrome : https://code.google.com/p/v8/issues/list — je vous laisse apprécier les quelques perles qui s'y trouvent.

/static/images/random4.jpg
Javascript, l'aléatoire made-in Debian
Le fameux Math.random()4 retourne une valeur comprise entre [0, 1) (0 inclus, 1 exclu). Le problème principal est que la valeur retournée est basée sur le temps, et peut donc être retrouvée de manière assez simple.
Il ne s'agit donc pas d'un « vrai » nombre aléatoire, tout au plus d'une dérivation et de quelques manipulations5.
Et voir que la librairie en question fait appel à ça me semble un peu… vaseux. On peut donc se poser quelques questions quant à la solidité des clefs générées, le générateur aléatoire étant une des causes principales de faiblesse…

Après, Google semble avoir créé un « truc » qui génère des nombres aléatoires, mais j'avoue que mes compétences pour valider leur procédé sont très limitées (voire absentes)…
Mais employer sha1 est une mauvaise idée6.
Sans parler du fait que SHA1 a été démontré comme « peu sûr », des attaques (théoriques) ayant été démontrées7.

L'extension tente en premier d'employer le générateur natif, mais là encore, il est possible que ce ne soit pas gagné8

On peut donc raisonnablement douter de la solidité et de l'unicité des clefs produites — de là, il est tout autant raisonnable de douter de la sécurité offerte par cette extension.

Le navigateur, coffre-fort des clefs privées ?
C'est l'une des deux choses qui me dérangent le plus : le fait que les clefs privées soient conservées dans le navigateur.
Quelle confiance peut-on avoir, réellement, dans cette application exécutant une multitude de codes divers et (a)variés, dont vous ne maîtrisez même pas la source ?
À ce niveau, les dévs font preuve de transparence et annoncent la couleur : les clefs se trouvant dans le LocalStorage9 ne sont pas protégés contre les accès — leur seule protection est le fait qu'elles soient chiffrées, donc « protégées par un mot de passe »…
Les clefs « en cours d'utilisation », donc déchiffrées et chargées en mémoire, sont protégées par le sandboxing (cloisonnement) des processus au sein de Chrome — là encore, rien n'assure à 100 % que rien ni personne n'arrivera à exploiter une faille quelconque.
Même que c'est précisé : si on active l'envoi automatique des rapports de bugs, il est possible que des bouts de mémoire contenant des éléments de la clef privée soient envoyés lors d'un crash…

On ne peut que se baser sur la confiance qu'on a pour ces développeurs et Google en général. 0, pour moi.

Et le business-model de Google, dans tout ça ?
Bah oui, n'oublions pas comment Google finance le fait de vous fournir un webmail avec 10'000 fonctionnalités, un antispam de qualité, etc : les publicités contextuelles10 !
/static/images/gmail-ads.jpg

Comment comptent-ils faire si tout le monde chiffre ses mails ? Ils ne peuvent, selon leurs propres dires, pas accéder à votre clef privée et donc, logiquement, il leur est impossible de déchiffrer vos correspondances de manière à vous envoyer des publicités ciblées !

De là, plusieurs possibilités :
  • Google se tire une balle dans le pieds (on y croit)
  • Google a laissé une porte ouverte dans son extension pour accéder aux contenus (pratique pour la NSA)
  • Google compte sur le fait que peu de monde utilisera son extension, tout en se rachetant une image un peu moins « evil »

Pour ma part, j'hésite entre la seconde et la troisième, avec un penchant pour cette dernière — la seconde serait possible si et seulement si le code n'était pas ouvert. On peut compter sur les communautés pour se poser les mêmes questions et auditer de manière stricte cette extension.

Bon, j'ai craqué, je l'utilise. Mais j'ai deux ordis…
Pas de miracle, il vous faudra exporter d'un côté, importer de l'autre. Et, évidemment, il sera fortement déconseillé de s'envoyer son keyring par mail.
Clef USB (voire disquettes selon qui vous conseille), volumes chiffrés, etc seront de mise pour un transfert en toute sécurité.
Pas grand chose d'autre à dire sur ce sujet, au final.

Autres considérations
Vouloir pousser les gens à employer des outils cryptographiques est bien. Vouloir simplifier l'utilisation de ces outils est encore mieux. Mais fournir un bout de code douteux, même avec des avertissements, n'est pas une bonne chose :

Il convient de ne pas se précipiter sur cet outil. Pour les multiples raisons invoquées précédemment. Pour d'autres raisons, aussi : après tout, on parle de Google. Google, l'entité qui vous traque où que vous alliez, quelque soit votre appareil, quelque soient vos intentions.
Leurs innovations sont certes intéressantes, mais il s'agit avant tout d'une société privée, ayant des budgets à tenir, des actionnaires à contenter, des retours sur investissements à générer.

Il faudra surtout attendre que des personnes externes à Google se penchent sur le code, sur les implémentations des concepts cryptographiques, etc. Ce n'est pas simple. Cela demande de solides connaissances en mathématiques et en programmation — le fait que ce soit en Javascript ne va pas non plus aider, à mon avis.

Il faut aussi garder en tête que l'extension, dans son état actuel, ne chiffre pas les pièces jointes. Il vous faudra donc les chiffrer à part. Seul le contenu du mail sera chiffré — les données annexes telles que le sujet, les destinataires seront en clair.

Et, à priori, End-to-End ne semble pas prévu pour un autre webmail que celui de Google, ce qui pose 2-3 problèmes annexes ;).

Pourquoi truandage ?
Le mot est peut-être un peu fort. Mais considérons les points suivants tels qu'abordés dans ce billet :
  • Google a besoin de vos contenus pour augmenter les chances que vous cliquiez sur une publicité
  • Google est soumis au Patriot Act, loi le forçant à s'assurer que les autorités US ont accès à vos informations et correspondances
  • Les dirigeants de Google ne sont pas réputés pour valoriser la protection des données personnelles11

Bref. Tout cela me fait penser à une jolie arnaque dont les utilisateurs finaux feront, une fois de plus, les frais.

Pour ma part, je reste avec mon Icedove et Enigmail…

More »»

Catégories en relation

TOR Exit Node - Österreicher wegen Mittäterschaft verurteilt

Par cta @christiantanner @christiantanner — 2014-07-02T08:36:42
Das Landesgericht für Strafsachen in Graz, Österreich hat den Betreiber eines TOR Exit Nodes der Mittäterschaft an der «strafbare Darstellung Minderjähriger» schuldig gesprochen. Bis zu diesem Urteil galt auch in Österreich die Meinung, dass die Betreiber der Infrastruktur nicht für die übermittelten Inhalte verantwortlich sind. 

Dieses Urteil ist höchst frustrierend. Es zeigt erneut, dass die Rechtsprechung das Internet schlicht und einfach nicht verstanden hat; oder - noch schlimmer - es als etwas ganz und gar schlechtes ansieht. Das Gericht hat den Betreiber des Exit Nodes anhand §12 öStGB verurteilt: 

Behandlung aller Beteiligten als Täter
§ 12. Nicht nur der unmittelbare Täter begeht die strafbare Handlung, sondern auch jeder, der einen anderen dazu bestimmt, sie auszuführen, oder der sonst zu ihrer Ausführung beiträgt.

Machen wir mal einen Schritt zurück. Wer einen TOR Exit Node betreibt, hat keine Kontrolle über die Daten, welche darüber laufen. Das ist der Sache inhärent. Gemäss Urteil ist die Betreibende Person dennoch dafür verantwortlich. Das entspricht in etwa der Ansicht, dass der Hersteller eines Brecheisens für den damit begangenen Einbruch verantwortlich ist. Oder der Automobilhersteller für die Geschwindigkeitsüberschreitung. Oder der Strassenbauer für die Fahrerflucht. Das ist Unsinn. 
Die einzige einigermassen zulässige Analogie ist die Verantwortung eines Schusswaffenherstellers für die mit der Waffe begangene Gewalttat. Eine Schusswaffe dient keinem anderen Zweck, als der Gewaltanwendung. Und anscheinend sieht das Landesgericht Graz TOR genau in diesem Licht: ein Medium, welches ausschliesslich der Begehung von Straftaten dient.

Diese Ansicht ist falsch! Und sie ist gefährlich für den Schutz der Privatsphäre. Es gibt genügend gute, legitime Gründe, sich anonym im Internet zu bewegen: Journalisten recherchieren anonym, Eltern wollen die Privatsphäre ihrer Kinder schützen, Menschen wollen sich vor staatlicher Überwachung schützen, sie wollen der personalisierte Werbung privater Anbieter entgehen, etc. 

Dieses Urteil wurde in Österreich gesprochen und ist somit für die Schweiz nicht anwendbar. Dennoch ist es wichtig, hier aufmerksam zu bleiben. Zu weit verbreitet ist die Ansicht, dass sich nur Kriminelle für ihre Privatsphäre interessieren. Auch weil sich zu viele Menschen viel zu wenig für Ihren Schutz und ihre Verteidigung einsetzen. Es ist an der Zeit, das zu ändern. Jetzt

---
Links:
Beitrag zum Urteil: https://network23.org/blackoutaustria/2014/07/01/to-whom-it-my-concern/
Link zum relevanten Artikel öStGB: https://www.ris.bka.gv.at/Dokument.wxe?Abfrage=Bundesnormen&Dokumentnummer=NOR12029553
Information der Electronic Frontier Foundation - EFF zu TOR: https://www.eff.org/deeplinks/2014/07/7-things-you-should-know-about-tor

More »»

Banques vulnérables à POODLE — mais pas seulement.

Par SwissTengu @SwissTengu @SwissTengu — 2014-12-18T16:26:18
Un article, paru dans Le Matin du jour1, met en avant des problèmes de configuration des serveurs e-banking de deux organismes bancaires suisses.

Les commentaires, outre le fait qu'ils passent juste à côté du sujet principal, montrent aussi le manque de connaissances des utilisateurs de ces services. La réponse d'une des banques citées2 est, quant à elle, un ramassis de langues de bois.

Penchons-nous un tout petit peu sur le fond du problème.

POODLE
Sous ce joli nom tout mignon se cache un truc un peu vicieux. On ne va pas entrer dans les détails, déjà expliqués en long3, en large4 et en travers5.
Ce qu'il faut retenir, c'est que c'est exploitable moyennant un peu de connaissances techniques, et que ça permet, entre autres, de récupérer un cookie6 de session7, permettant à un attaquant de vous personnifier auprès des services demandant une authentification (comme une banque, par exemple).

Il est certain que les instituts bancaires ont des mesures de sécurité empêchant un cookie d'être réutilisé. On imagine sans peine que les adresses IP sont contrôlées lors de chaque action, de même que les éléments fournis par les navigateurs des clients. De toutes façons, les informations utilisables pour de tels contrôles sont enregistrées pour le suivi des transactions, leur validation, etc. Avec ou sans POODLE, Heartbleed ou autres à venir.

Il est donc clair que le système e-banking en soi est sécurisé ou, du moins, ne devrait pas être assez mauvais pour que POODLE soit réellement efficace.

C'est quoi le problème alors ?
Le problème, enfin, les problèmes, sont mutliples.

En premier, le silence des banques face à POODLE. Mais pas seulement : peu ont communiqué suite à Heartbleed8 qui a pourtant été pas mal médiatisé. En gros, on paie les banques pour un service et un accès par voie électronique (e-banking), mais on ne sait jamais réellement si elles sont au courant des failles, ni ce qu'elles font pour nous protéger, nous, les clients qui leur confions notre argent.

Outre le silence, le temps de réaction est affligeant : il faut compter des semaines si ce n'est des mois avant de voir le correctif appliqué.

Dans le cas précis de la BCV, on pourra aussi noter leur superbe résultat sur SSLlabs9, montrant qu'ils n'ont pas forcément les moyens de contester quoi que ce soit : leur configuration SSL est mauvaise, du certificat SSL mal fait jusquà la configuration de leur serveur web. Même leur certificat intermédiare est faux et comporte des éléments en trop…

/static/images/bcv-fail.png

Dans le cas de la Raiffeisen, pareil, leur résultat10 est tout aussi parlant, bien que meilleur que la BCV. Ce qui n'est, en soit, pas très dur…

/static/images/raiffeisen-fail.png

Et alors… C'est sécurisé, oui ou non ?
Oui. Enfin… On ne peut que l'espérer, à savoir que le protocole de connexion est pourri, donc on doit faire confiance au backend (l'application d'e-banking) pour qu'elle possède les contrôles nécessaires, et qu'elle soit exempte de failles exploitables. Errare humanum est, comme disait l'autre.

Sans tomber dans la paranoïa complète, voici quelques conseils pour éviter les problèmes en attendant que la situation soit claire :
  • Ne jamais employer une connexion publique sans fil
  • Éviter de passer par les connexions mobile (oui, même avec leur app, le réseau DATA mobile est insécure)
  • Contrôlez que le certificat soit bien émis par une autorité reconnue (VeriSign pour la BCV,  et QuoVadis Global pour Raiffeisen)
  • Dans la mesure du possible utilisez la connexion de votre domicile.

Note: l'émetteur du certificat. À ce niveau, rien n'est gravé dans le marbre, surtout en sachant que ces deux banques ont "prévu de corriger le problème" début 2015. 

Mot de la fin
Ce qui est consternant dans toute cette histoire, c'est le manque de communication des banques.
Si elles savent qu'elles sont protégées, pourquoi ne pas le mettre sur leur page d'accueil ?
Quand on les contacte par mail, en passant par leur messagerie interne (accessible uniquement par les clients donc), pourquoi ne répondent-elles pas ?

Ce qui est aussi consternant, c'est de voir que des instituts censés protéger leurs usagers ne semblent pas prendre réellement au sérieux l'image qu'elles donnent d'elles-mêmes : en effet, se ramasser un F pour un truc aussi basique qu'une configuration SSL, ça ne donne pas confiance.

Pour notre part, cela nous fait nous interroger sur les compétences de leurs équipes (ou prestataires) à gérer correctement une infrastructure.
Du coup, est-ce que nos données sont réellement protégées ?
Est-ce que tout est réellement mis en œuvre pour éviter les fuites ou les vols ?

Autant de questions qui, nous le craignons, resteront sans réponse. Le manque de transparence à ce niveau est mauvais, et n'inspire en tous cas pas la confiance requise pour confier son argent et ses données à de tels instituts.

En comparaison, la connexion fournie par EthACK est plus sécurisée que celle de ces deux banques11. Et on ne vous fait rien payer pour ça ;).

/static/images/ethack-ssl.png


More »»

Superfish, ou comment Lenovo tue la confiance en SSL/TLS

Par SwissTengu @SwissTengu @SwissTengu — 2015-02-19T18:03:34
Lenovo ont fait fort, très fort : en installant une application d'un partenaire commercial, ils viennent de tuer le fonctionnement même de SSL/TLS et de la chaîne de confiance autour de cet écosystème.

Pire que POODLE, Heartbleed et autres failles au niveau des protocoles, on vous présente Superfish.

Superfish, c'est le nom d'une société (Superfish Inc) américaine. Elle fournit, entre autres, une application insérant de la publicité dans vos pages Web, en faisant tourner sur votre machine un serveur, et en forçant les connexions de votre navigateur à passer par lui (un mot : un proxy1).

Là où le bât blesse, c'est que ce proxy insère aussi du contenu dans les connexions chiffrées (vous savez, le petit httpS, avec le cadenas). Or, les connexions sécurisées sont, justement, censée éviter ce genre de comportement.

Comment se fait-il qu'un tiers se trouvant entre vous et, disons, Facebook (ou Twitter, ou votre banque) arrive ainsi à injecter du contenu ? Simple : l'application de Superfish génère des certificats à la volée, déchiffre le contenu, et rechiffre derrière.

Sauf que, normalement, votre navigateur devrait crier : le certificat de votre site n'est pas valide, parce que Superfish n'est pas une autorité de certification reconnue… Et bien, cher lecteur, chère lectrice, grâce à Lenovo, Superfish est considéré comme une autorité de confiance par votre ordinateur !

En effet, Lenovo ont commis une énorme bourde : ils ont installé le certificat de Superfish au cœur de votre système, en lui octroyant, en plus, la confiance maximale ! Du coup, les certificats créés à la volée par le proxy de Superfish sont considérés comme valides.

Mais ce n'est pas tout : pour signer les certificats générés, l'application de Superfish possède la clef. Évidemment. Sans cette clef, le proxy ne pourrait pas signer le certificat généré, et donc il n'y aurait pas moyen d'éviter que votre navigateur ne crie au scandale.
Évidemment, la clef est chiffrée. Mais comme elle est disponible sur quelques milliers de machines2, qu'elle circule déjà sur le Net3, on ne peut pas vraiment dire que ce détail va retenir des hackers de s'y mettre4.
Du coup, n'importe qui peut signer un certificat via l'autorité de Superfish.

Vous voyez où on veut en arriver ? Non ? Bon, reprenons :
vous êtes sur votre site d'achat favori, en SSL/TLS, donc connexion chiffrée. Vous faites vos petites affaires, pensant "c'est bon, je peux donner ma carte bancaire, y a le cadenas". Mais est-ce le bon certificat ? Combien d'entre nous vérifie l'émetteur du certificat ? Combien prennent le temps de réellement vérifier ? Pas des masses.

On ne parlera pas non plus de l'effet avec les mails de phishing5 — à ce niveau, Superfish pourrait être renommé en SuperPhish. Les possibilités sont infinies, à partir du moment où le nombre de cibles potentielles se mesure par le nombre de clients d'un des plus gros distributeurs de matériel informatique.

Et, cette fois, n'importe qui peut vous écouter : de votre voisin, au petit hacker boutonneux. Et sans aucun effort, surtout sur votre réseau local donc la clef WPA est "mon chien s'appelle Fido" voire, plus trivial, votre numéro de téléphone. En quelques manipulations très simples, voire enfantines, on peut faire en sorte que votre trafic passe par une machine sous notre contrôle, possédant les applications nécessaires6, et vos actions sur le Net n'ont plus aucun secret.

Ce qu'a fait Lenovo, c'est juste briser la chaîne de confiance, déjà mise à mal maintes reprises7

En installant de manière globale cette autorité, Lenovo a démontré que les fabricants ne savent pas ce qu'ils font. Qu'on ne peut pas leur faire confiance. Que le système complet des autorités de certification n'est pas fiable : s'il faut, à chaque fois qu'on achète un ordinateur ou, plus généralement, dès qu'on installe quelque chose dessus, s'assurer que le cercle de confiance n'est pas compromis, on n'est pas près de s'en sortir. Personne ne prend la peine de contrôler le keyring système. Plus de 600 autorités diverses, des autorités privées, étatiques, locales… La tâche est impossible. Comment savoir lesquelles sont ne serait-ce qu'utiles ? De là à déterminer nous-même lesquelles sont de confiance…

Mais c'est un autre sujet (tout aussi intéressant cela dit : quelle confiance peut-on avoir dans les autorités de certification ?).

Revenons sur Superfish. Dans le cas où vous avez récemment acheté un ordinateur Lenovo (bien qu'à notre sens il ne faille en aucun cas limiter à cette seule marque), voici les différents points pour vous assurer que vous n'êtes pas compromis par ce certificat vérolé :
  • Exécutez certmgr.msc (Windows+r pour avoir l'invite de commande)
  • Allez dans la partie "Autorités de certification racine"
  • Cherchez "Superfish Inc."

Si vous la trouvez, supprimez-la.

Vous pouvez aussi passer par ce site8 qui vous donnera une indication — mais l'option "vérification manuelle" décrite ci-dessus est la plus sûre.

Il vous faut aussi contrôler dans les logiciels installés que les produits de Superfish Inc sont absents. Histoire d'éviter qu'ils tournent, se mettent à jour ou que d'autres joyeusetés de ce genre n'arrivent.

Cette histoire montre à quel point nous, consommateurs, sommes dépendants des fournisseurs.
Cela montre aussi à quel point les fournisseurs ne peuvent pas avoir notre confiance — or, en sécurité, malheureusement, beaucoup de choses se basent sur la confiance (pour l'utilisateur final).
Nous, consommateurs, n'avons pas les connaissances nécessaires pour repérer les erreurs (volontaires ou non) commises sur des produits qu'on achète.

More »»

Catégories en relation

C'est juste pour le terrorisme

Par SwissTengu @SwissTengu @SwissTengu — 2015-07-01T06:28:18
De plus en plus, on entend des sorties "c'est contre le terrorisme", "c'est pour la sécurité des citoyens", etc.
De plus en plus, on entend aussi des choses dans le genre "il faut forcer les développeurs à donner les clefs de chiffrement".

On entend aussi des personnes qui mettent les deux ensemble : "dans le cadre de la lutte contre le terrorisme, il faut qu'on puisse obliger les entités à fournir les clefs de chiffrement" (bon, ok, comme toujours ils disent "de décryptage"… mais passons).

Arrêtons-nous deux minutes et réfléchissons à tout cela. On se rend compte en moins de 30 secondes que cette idée implique donc un cas d'exception. "Pour lutter contre le terrorisme". Et dans ces cas d'exceptions, on demande des mesures d'exception. "Fournir les clefs de chiffrement".

Mis à part le fait que du moment qu'une exception est créée, des personnes à l'esprit très brillant vont aussitôt s'engouffrer pour proposer d'appliquer cette exception à un autre cas, puis un autre, ce jusqu'à ce que l'exception devienne norme — cela, de toutes façons, on va nous sortir que non, le cadre légal est précis. Et blah-blah-blah. Bref.

Non, ce qui est intéressant, c'est d'imaginer comment une entité mettra à disposition des clefs de chiffrement. Des exemples comme Threema ont été cités. Le fond de commerce de cette application étant le chiffrement asymétrique1 et le fait que les clefs de chiffrement sont sur les appareils, je les vois mal commencer à vouloir récolter les clefs "à des fins de possible enquête et déchiffrement ultérieur". Ou créer une backdoor pour que les clefs puissent être rappatriées (encore que…).
En cas de soupçon de ce genre de pratique, Threema pourra mettre la clef sous la porte.

Une application dont le code est ouvert, dans le genre de Telegram par exemple, ne pourra simplement pas implémenter cela sans s'attirer les foudres de la communauté.
Et, dans le cas où l'application utilise une autre technique de chiffrement (OTR2, à tous hasards), ça devient encore plus drôle : les clefs changent, et la clef "actuelle" ne permet pas de déchiffrer les messages précédents, et ne permettra pas de déchiffrer les messages suivants.

Bref… La transmission elle-même n'est de loin pas assurée, ni assurable. Ça détruira le modèle économique de pas mal d'entreprises, avec les conséquences qu'on peut imaginer. Ouep, je vous ressort le discours d'Economiesuisse ;). Des fois il peut avoir du bon.

Bon, admettons, pafff, coup de baguette magique, y a une solution. La police (et, ne nous voilons pas la face, les services de renseignements divers et (a)variés) peuvent demander (ou s'octroyer) l'accès aux clefs de chiffrement et de déchiffrement. On sait pas comment, mais ça marche ;). Bref.

Comment ces clefs seront-elles stockées ? Je ne sais pas pour vous, mais j'ai pas mal de raisons de douter de la capacité tant du SRC3 que des autres, Fedpol4 comprise, pour conserver des données confidentielles sans la moindre fuite.

Résumons vite-fait : les clefs peuvent difficilement être transmises par les entités fournissant les services de messagerie chiffrées, et le stockage de ces clefs est lui-même des plus incertains.

Ajoutons à cela le fait que les exceptions sont faites pour devenir des normes par la force des choses ("pensez aux enfants", "pensez à l'espionnage industriel", etc), les outils crpytographiques (du moins ceux à bases de clefs statiques) ne serviront plus à rien. Ni pour les vilains, ni pour les gentils.
Le problème étant : les vilains, ils ne sont pas complètement stupides — du moins pas tous. Ils ont des capacités, entre autres financières, pour obtenir des systèmes de communication sécurisés, décentralisés. Des moyens qui les mettront donc hors de portée des services de renseignement et de la police. Laissant les gentils à la portée du premier hacker venu ayant assez de baloches pour hacker fedpol ou toute autre entité à la sécurité vaseuse. Et la sécurité générale ne sera pas meilleure, mais, bien au contraire, encore plus mauvaise, du moins pour les citoyens — on pourra compter sur les États pour se fournir en applications et systèmes, aux frais des citoyens.

En somme, vous l'aurez compris, ces propositions sont dangereuses, et n'apportent rien au niveau sécurité. Un peu comme les projets de lois sur le renseignement, en somme : accumulation de données, pour rien, représentant une masse tellement énorme qu'elles ne seront pas traitées.
Un peu comme en France5, où des dossiers complets sont ignorés, des dangers dé-fichés, des données passant dans l'angle mort…

La surveillance globale telle que préconisée par la plupart des services ne sert à rien — les USA sont en avance à ce niveau… Boston n'a pas pu être évité, et le nombre d'attentats "annulés" change à chaque audition.

More »»

Catégories en relation

Je sécurise mes contenus en zip ou assimilés

Par SwissTengu @SwissTengu @SwissTengu — 2015-08-04T18:15:32
Non, ce n'est pas une blague. Y a même tout un article1 sur une personne, sans doute très bien et consciencieuse, qui explique avec sérieux protéger les informations "très sensibles" envoyées par mail sur un PDF protégé par un mot de passe ou en zip.

Si le premier semble une bonne idée, il convient de rappeler que les mots de passe PDF ne sont pas gage de sécurité, une simple recherche2 permet de s'en rendre compte.

Quant au second… Si "unzip " permet d'accéder au contenu, on ne peut pas vraiment parler de protection. Certains vont parler des mots de passe sur les archives ZIP (voire RAR)… Là encore, non3.

Malheureusement pour cette personne, les données confidentielles pour lesquelles elle signe des NDA4 sont en fait à poils sur le Net. Super.

Maintenant que ces choses sont dites et (je l'espère) claires… "Comment qu'on peut faire pour protéger les contenus confidentiels qu'on communique à droite ou à gauche !?"

Différents systèmes existent, certains pas du tout conviviaux mais offrant une sécurité au top, d'autres carrément plus cools et clic-o-convi tout en offrant une sécurité à priori correcte.

Le pas convi : GPG via Enigmail ou GPGTools
On a tous ou presque entendu parler de GPG5 ou PGP6 et, surtout du fait que cet outil est tout sauf intuitif, pratique et orienté "utilisateur final" : il faut faire des "échanges de clefs", il faut "régler le niveau de confiance", "signer des clefs", "générer des certificats de révocation"… Autant de termes barbares, le tout le plus souvent géré dans des interfaces peu intuitives.
Sans même parler du fait qu'il faut se souvenir d'un nouveau mot de passe…

Bref. GPG est sympa tout plein, mais, franchement, à part des geeks barbus et quelques illuminés, pas grand monde l'utilise. Dommage. Parce que l'outil en soi est excellent.

Le convi : les solutions "tout en un"
Heureusement, des solutions existent et, il faut l'avouer, elles sont séduisantes : imaginez une interface à-la gmail, vous offrant tout le confort d'un client mail tout en vous offrant un moyen de communication chiffré.

C'est le cas, entre autres, de Protonmail7, une solution basée en Suisse, et Tutanota8, une solution libre basée en Allemagne.

Ces solutions offrent une interface simple, efficace et, du moins sur le papier, assurent que les communications effectuées par ce biais sont chiffrées de bout en bout, sans aucun moyen tant pour le fournisseur du service que quiconque autre que vous et le destinataire d'accéder au contenu du mail ou de ses pièces jointes.

Contrairement à GPG, ces deux applications ne demandent pas un "échange de clef", ni la gestion d'un trousseau de clefs, ni rien de tout ce genre.

Dans le cas où votre contact n'a pas de compte sur l'un de ces services, mais que vous voulez chiffrer le contenu, il vous suffit de défnir un mot de passe, que vous vous communiquez par un "side-channel", à savoir un moyen de communication tiers (sms, appel vocal, email sur d'autres adresses, etc).

Notez au passage qu'actuellement, il semblerait que seul Tutanota permet à votre correspondant "externe" au système de vous répondre de manière sécurisée, bien que Protonmail soit sur le point de fournir une mise à jour allant aussi dans ce sens.

Les solutions pour communiquer de manière sécurisée existent. Il tient à vous de vous renseigner et de les promouvoir ;). Parlez-en autour de vous, et ne comptez pas sur ZIP, RAR ou PDF pour protéger vos contenus.

Parce que oui, manifestement, n'importe qui a quelque chose à cacher. Même une traductrice indépendante. Il n'y a donc pas besoin d'être un perdoterroriste tueur de chatons pour avoir besoin de protéger ses données.

À bon entendeur, salut !

More »»