Du SSL gratuit pour tout le monde ?

letsencrypt-logoLet’s Encrypt est une initiative toute récente de Mozilla, Cisco, l'EFF, Akamai, et IdenTrust. Elle vise à permettre à tout webmaster de proposer son site en HTTPS sans surcoût. Il s'agit de proposer aux administrateurs de serveurs web la possibilité d'obtenir gratuitement, automatiquement, et sans contrainte le précieux certificat SSL nécessaire au chiffrement des échanges entre le serveur et les clients. Le certificat sera bien évidemment reconnu nativement dans les navigateurs. C'est en tout cas la promesse du projet. Si cela permet de mettre fin à un racket que je dénonçais il y a quelques semaines, cela lève aussi quelques questions.

Un des principaux arguments des Verisign et autres Thawte pour vous facturer une fortune pour chaque certificat est que la création et le maintient d'une autorité de certification (CA) est extrêmement onéreux. Cela coûte en effet assez cher : les contraintes de sécurité sont immenses, les audits nombreux, etc. En effet la moindre compromission de l'autorité de certification réduit tous les efforts à néant : l'attaquant qui parviendrait à s'infiltrer dans la CA serait capable d'émettre des faux certificats passant pour tout à fait valides dans les navigateurs. Votre belle connexion sécurisée avec "barre verte" pourrait alors être détournée sans que vous n'en ayez conscience (sécurité ≠ confiance).
Mais on le sait ces grosses CA ne sont pas forcément plus fiables que les petites. Elles ne résistent pas forcément mieux aux pressions des agences gouvernementales, ni aux détournements ou piratages. Quelques exemples par ici. Finalement, ce surcoût n'a guère de valeur. Ce qui compte vraiment c'est de savoir si on peut faire confiance à la CA, ou pas.

Dans l'initiative Let’s Encrypt, la question de confiance peut se poser. Je n'ai pas de souci avec Mozilla, et la présence de l'EFF est rassurante. Par contre celle de Cisco m'interpelle. Snowden nous a montré comment la NSA s'amuse à intercepter les livraisons de matériels de cette marque pour caviarder les firmwares et ajouter des portes dérobées. Rien, bien évidement, n'incrimine Cisco directement dans ces magouilles. Néanmoins le doute raisonnable peut naître sur leur degré de connaissance de ces agissements.
Au bout du compte je n'ai pas trop envie de faire confiance à un groupement d'entités sachant que la duplicité d'une seule d'entre elles peut réduire à néant la sécurité des certificats délivrés.

Le protocole proposé (ACME) me laisse aussi dubitatif. J'avoue n'avoir pas lu l'ensemble du brouillon. Je n'ai pas de critique fondée à son encontre mais la débauche d'automatisme (le serveur web qui commande lui même le certificat par exemple) me laisse dubitatif, et je pense que j'attendrai sagement de voir ce que ça donne chez les autres avant d'essayer moi-même.

L'outils lets-encrypt est conçu pour fonctionner assez simplement. C'est sans doute une bonne idée au départ, mais cela laisse peu de maitrise sur le processus. Bien sûr, tout comme le protocole, il faudra attendre de voir ce que ça donne, quelles plateformes sont supportées, quels logiciels aussi. Mettre du SSL dans le web c'est sympa, mettre du SSL dans du mail (smtp, pop, imap) c'est primordial. A priori la première version sera livrée à l'été 2015, donc il reste un peu de temps.

Je souhaite profondément que Let’s Encrypt réussisse son pari. Fournir des certificats SSL reconnus et gratuits, avec des outils simples, basés sur une autorité de certification et sur des protocoles sûrs est un vrai défi.

Related posts

Le racket des certificats SSL

Autrefois, Internet était un peu open bar. C'était un lieu de partage où tout le monde pouvait publier, échanger, créer librement. C'était l'insouciance. Puis il y a eu l'arrivée du commerce en ligne, avec des échanges d'argent numérique. Il a alors fallu créer la confiance, car dans nos vies pressées il n'est plus question de l'acquérir sur le long terme, non, il faut la créer de toute pièce pour en disposer immédiatement.
Sont alors arrivés en masse les sites marchands (ou non) proposant des connexions sécurisées "https". Plus récemment, l'usage des connexions sécurisées par SSL/TLS s'est beaucoup élargi, non plus pour protéger vos données bancaires d'une interception mais pour protéger votre vie privée. Il est en effet primordial de pouvoir publier sa vie sur facebook ou twitter sans qu'un méchant pirate puisse espionner directement sur votre connexion ce que vous écrivez sur ces sites.

C'est bien de promouvoir la sécurité des échanges sur internet, d'encourager les gens à proposer des services chiffrés, et les initiatives ce multiplient dans ce sens, avec par exemple des navigateurs qui vont tenter de se connecter à la version https d'un site web par défaut, et se rabattre sur la version http seulement quand la version sécurisée n'existe pas.

Pour transformer un service http classique en service sécurisé https, il faut disposer d'un certificat SSL/TLS. Malheureusement seuls les gens riches peuvent proposer des services sécurisés "de confiance". En effet il existe globalement trois manières de se procurer un certificat SSL. Vous pouvez le fabriquer vous même, c'est assez simple, cela prend quelques minutes et c'est totalement gratuit. Vous pouvez demander à un opérateur libre et gratuit comme CaCert.org de vous le proposer, c'est à peine plus long et toujours gratuit. Ou alors, vous avez de l'argent (beaucoup), et vous l'achetez chez un prestataire.
Et là, nous sommes face à trois obstacles majeurs, qui sont le Certification Authority Browser Forum, les moteurs de recherche, et le prix.

Chrome vous ment, ce qui ne profite qu'aux grosses entreprises

Chrome vous ment, ce qui ne profite qu'aux grosses entreprises

Le Certification Authority Browser Forum est un lieu d'échange entre les développeurs de navigateur d'une part et les autorités de certification d'autre part. Ces gens se mettent d'accord sur plein de détails techniques autour de l'implémentation de la sécurité des certificats dans les navigateurs. Notamment, c'est en partie là-bas qu'ils se mettent d'accord sur quelle autorité de certification (CA) va se trouvée incluse d'office dans la liste des CA valides des navigateurs. En effet, quand vous ouvrez une page web en https, le serveur présente son certificat. Ce dernier indique par quelle CA il a été signé. Si la CA est reconnue par le navigateur tout va bien, sinon l'utilisateur reçoit une alerte indiquant que la connexion n'est pas sécurisée, qu'on ne peut pas lui faire confiance, etc. Ces messages d'alerte ont d'ailleurs beaucoup évolué depuis quelques années. Actuellement, ils sont juste mensongers. Ils induisent pour son bien l'utilisateur en erreur allant jusqu'à prétendre à tort que la connexion n'est pas sécurisée. Ce mécanisme induit chez les utilisateurs une confusion (criminelle oserais-je dire) entre sécurité et confiance, en faisant passer "une confiance que l'outil ne peut vérifier" pour une "sécurité qui n'existe pas".

Confusion sécurité confiance

Confusion sécurité confiance

Les moteurs de recherche ne sont plus ce qu'ils étaient à leurs balbutiements dans les années 90. Ils intègrent désormais des algorithmes extrêmement complexes de classement (ranking) autorisant des recherches personnalisées et un placement de produits optimisé. En parallèle ils se sont arrogés le droit de surclasser ou de déclasser des résultats de recherche selon des critères tout à fait critiquables. Google a notamment décidé d'améliorer la visibilité des sites qui répondent à des critères de sécurité arbitraires. Essentiellement cela revient à surclasser les sites internet disposant d'un certificat SSL EV (extended validation, les plus chers).
Ainsi, si vous n'êtes pas en mesure de proposer votre site web en https, avec un certificat valide et de préférence un certificat EV, vous êtes déclassés au profit de la concurrence.

Comme vous l'avez compris, la seule planche de salut pour obtenir la confiance des navigateurs et donc des utilisateurs qui sont derrière est de proposer une connexion https avec un certificat acheté chez un fournisseur du commerce. Ces certificats sont excessivement chers. Et ce tarif ne permet simplement pas, même à des individus passionnés, de proposer une connexion https qui aurait les faveurs de Mozilla ou Google.
J'utilise sur ce serveur un certificat SSL de CaCert qui contient 20 noms différents (patpro.net, www.patpro.net, patpro.fr, etc.). Ce certificat ne me coûte rien, il me permet de proposer le chiffrement SSL/TLS pour mon serveur web et pour mon serveur de mail. Si je veux obtenir un certificat comparable chez les autorités de certification du commerce, il m'en coûtera 2582 euros chez Thawte ou 6280 dollars chez Verisign/Symantec, pour un certificat valide pendant une année. À ce tarif là, c'est un certificat d'entrée de gamme, qui sera reconnu dans votre navigateur, mais ne disposera pas de la belle "barre-verte-qui-stimule-la-confiance-du-visiteur-et-améliore-le-référencement".

La fameuse barre verte qui doit donner confiance aux utilisateurs

La fameuse barre verte qui doit donner confiance aux utilisateurs


Pour disposer d'une telle parure il me faut être une entreprise, montrer patte blanche, et débourser 18200 dollars chez Verisign, toujours pour 1 an et mes 20 noms de domaines.
Heureusement il existe des alternatives un peu moins coûteuses, comme chez Gandi par exemple, où je pourrai trouver un certificat répondant à mes besoins pour 210 euros par an, ou 1900 euros en version EV. C'est toujours un coût sérieux pour un individu.

Donc la situation actuelle se résume assez simplement : les gros acteurs du web, Google en tête, poussent très fort pour que les utilisateurs ne fassent pas confiance à des certificats autosignés, ou gratuits. Ils utilisent un discours tellement simpliste qu'il en devient mensonger. En trompant l'utilisateur, ils favorisent la visibilité sur internet des gens riches, au dépend de ceux qui n'ont pas les mêmes moyens. En diffusant des messages anxiogènes aux utilisateurs, ils dévoient la sécurité réelle proposée par des certificats SSL légitimes.

Related posts

Giving up on Logstash

splunk-logoMore than six months away, I've put both Splunk and Logstash (plus ElasticSearch and Kibana) to trial. Since the beginning of my experiment, the difference between both products was pretty clear. I was hoping that ELK would be a nice solution to aggregate GBs of logs every day and more importantly to allow me and my team to dig into those logs.
Unfortunately, ELK failed hard on me. Mostly because of ElasticSearch: java threads on the loose eating my CPU, weird issue where a restart would fail and ES would become unavailable, no real storage tiering solution, and so on.
ElastickSearch looks like a very nice developer playground to me. It's quite badly - if at all - documented on the sysadmin side, meaning if you're not a developer and don't have weeks to spend reading API documentation you will have a hard time figuring out how to simply use/tune the product.
Also, this data storage backend has absolutely no security features (at the time I was testing Logstash). Just imagine you put valuable data into a remotely available database/storage/whatever and you're told that you are the one that should create a security layer around the storage. Imagine a product like SMB, NFS, Oracle DB, Postgres, etc. with zero access control feature, no role. Anyone who can display a pie chart in Kibana can gain full control of your ElasticSearch cluster and wipe all your data.
Logstash too has important issues: almost every setting changes require an application restart. Writing grok pattern to extract data is an horrendous process, and a new pattern won't be applied on past data. Splunk on the other hand will happily use a brand new pattern to extract values from past logs, no restart required.
Logstash misses also pipes, functions, triggers… Search in Kibana is not great. The syntax is a bit weird and you can easily find nothing just because you've forgot to enclose your search string with quotes… or is it because you put those quotes? And of course there is this strange limit that prevent you from searching in more than seven or eight months of data…

I've tried, hard. I've registered to not-so-helpful official mailing lists for Logstash and ElasticSearch and simply reading them will show you how far those products are from "production approval". I've used it alongside with Splunk, it boils down to this statement: Kibana is pretty, you can put together many fancy pie charts, tables, maps and Splunk is useful, reliable, efficient.

Yes, I'm moving to Splunk, @work and @home. My own needs are very easily covered by a Free license, and we are buying a 10 GB/day license for our +350 servers/switches/firewalls.

You might say that Splunk is expensive. That's true. But it's way less expensive to me than paying a full time experienced Java developer to dive into ElasticSearch and Logstash for at least a year. Splunk has proper ACL that will allow me to abide by regulations, a good documentation, and a large community. It support natively storage tiering, too.

ELK is a fast moving beast, it grows, evolves, but it's way behind Splunk in terms of maturity. You can't just deploy ELK like you would do for MySQL, Apache, Postfix, Oracle DB, or Splunk. Lets wait few years to see how it gets better.

Related posts

Metasploit hearbleed scanner reliably crashes (some) HP ILO

Disclaimer: HP ILO Firmware involved here is NOT the latest available. ILO 3 cards were not affected.

Using Metasploit to scan my network for OpenSSL "Heartbleed" vulnerability I've been quite shocked to get a handful of alerts in my mailbox. Our HP C7000 was no longer able to talk to some of our HP Proliant blades' ILO.

oh-crap

Production was all good, and service was still delivered, but blade management was impossible: Metasploit's auxiliary/scanner/ssl/openssl_heartbleed.rb probe has just crashed six HP ILO 2 cards. That's funny, because the ILO firmware is not vulnerable to heartbleed, it's only vulnerable to the scanner...

heartbleed

I've made some tests to repeat the problem. It happens with a 100% reliability. Quite impressive.

Software versions:

Metasploit
Framework: 4.8.2-2013121101
Console  : 4.8.2-2013121101.15168
openssl_heartbleed.rb : downloaded on April the 22th.

HP ProLiant BL490c G6 (product ID 509316-B21), ILO 2 firmware undisclosed for security reasons.
Related posts

Collecte en aveugle

Elle est belle celle-là :

213.61.149.100 […20:00:26 +0100] "GET / HTTP/1.0" 301 235 
213.61.149.100 […20:00:27 +0100] "GET /blog/ HTTP/1.0" 200 63772 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.sql HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.sql HTTP/1.0" 404 493 

Et particulièrement astucieuse, je suis persuadé qu'elle permet de ramasser des tonnes de trucs très intéressants.

Related posts

Les bons mots de passe…

jtr-crossword-10-donation_design Donner des conseils en matière de mot de passe, c'est délicat. Ça implique en général de croire un minimum dans le système de protection par mot de passe. Et comme toute la sécurité en général, le mot de passe est un compromis, et comme tout compromis, il est donc faillible. Je crois personnellement de moins en moins au principe du mot de passe pour protéger des informations vraiment vitales. Sans doute suis-je encouragé dans cette impression par des démonstrations récentes de casse de mots de passe complexes-mais-humainement-utilisables.
Je ne prendrai qu'un exemple : des mots de passe aussi complexes en apparence que "momof3g8kids" ou "qeadzcwrsfxv1331" peuvent être cassés en quelques heures.
En fait, dès l'instant où vous enregistrez un mot de passe sur un site web vous n'avez aucune maitrise (ni information en général) sur la qualité du stockage de ce mot de passe. Souvent, mais pas toujours, le mot de passe est chiffré, ou hashé. Mais rien ne vous garantit que cette protection est suffisante. Compte tenu de la puissance des machines et logiciels actuels, je doute sincèrement qu'elle le soit.
La probabilité pour qu'on casse votre mot de passe par des tentatives d'authentification successives sur votre compte hotmail est extrêmement faible. Par contre, celle qu'un pirate vole la base de mot de passe du forum d'équitation auquel vous êtes inscrit n'est pas négligeable (piratage d'un serveur de jeu en ligne de RockYou : plus de 32 millions de mots de passe aspirés - stockés en clair...).
Une fois la base de mots de passe dérobée, le pirate n'a plus qu'à s'y attaquer, si ils ne sont pas directement stockés en clair bien sûr. Quelques heures après en général, il aura cassé un échantillon non négligeable de mots de passe, dont chacun est associé à des données intéressantes telles que login, adresse email, etc.
À partir de là, le pirate va pouvoir tester ces mots de passe / login / emails pour se connecter à des sites comme facebook, gmail, hotmail, apple store, etc.
En 2010 je conseillais d'utiliser des mots de passe par type de risques, ce qui évitait d'en avoir un différent pour chaque site tout en cloisonnant un peu les choses. Depuis, je suis un peu plus désabusé. Avoir une grosse poignée de bons mots de passe ne semble plus suffisant. Je me garderai aussi à présent de donner quelque conseil que ce soit tant le problème a pris une ampleur hors de tout contrôle (PRISM, etc.).

Voici ce que je fais depuis quelques temps, vous n'êtes pas obligé de faire pareil :

- une adresse email différente pour chaque site sur le quel je m'inscris
- un mot de passe différent à chaque fois
- un mot de passe long, aléatoire et donc impossible à retenir

Le tout est stocké dans une application locale de type keychain. Ce trousseau n'est pas sauvegardé dans le cloud (mais il est tout de même sauvegardé, hein). Le trousseau est protégé par un mot de passe fiable que j'ai dans la tête et qui n'est pas utilisé ailleurs.

Mes mots de passe ressemblent à ça désormais :

xwMxTgX7g@*Gd&BW31dlc`ME<
j?UI?@CQe`=p5D(-w<q{FUOWb
&X52&/*.U4Otm/rH?oT-VhTIn
$kUT5_XP\ncw9cYM_\8NHbIm*
...

Des chaînes aléatoires de 25 caractères, choisis parmi 93 lettres, chiffres et symboles. Autant dire qu'avec ça, j'ai bon espoir que mon mot de passe se trouve dans les derniers à être craqués lors d'une attaque. En prime comme je n'utilise chacun que pour un site unique, la valeur ajoutée de la casse de ce mot de passe est très faible.

Si vous êtes sur BSD (Mac OS X, FreeBSD…) vous pouvez utiliser la commande jot pour créer autant de mots de passe que vous souhaitez :

jot -r -c 200 33 126 | rs -g0 0 25

-r : random
-c 200 : 200 caractères
33 126 : du "!" au "~" dans la table ASCII (man ascii)
rs -g0 0 25 : re-formate en ligne de 25 caractères

Avec ça, je vais bien tenir 2 ou 3 ans avant de devoir allonger les chaînes…

Related posts

On s’amuse avec IPMI

AOC-IPMI20-E-copyright-supermicroJ'ai passé un week end plutôt divertissant en compagnie d'IPMI. Tout a commencé avec la lecture d'un article édifiant sur arstechnica.com présentant IPMI comme un parasite, une sangsue.
J'ai toujours su instinctivement que l'IPMI pouvait, quelque part, poser un souci en terme de sécurité. Mais jamais je n'aurai imaginé que la situation fût aussi dramatique.
Les failles sont à tous les niveaux, tant dans le protocole IPMI, que dans les implémentations semi-propriétaires des fabricants. Elles sont dans les logiciels utilisés, elles sont dans le verrouillage que les fabricants imposent aux BMC, les rendant impossible à auditer, etc. Sysadmin de tout poil, je vous invite fortement à lire l'article d'Ars, et les proses de Dan Farmer et HD Moore.

Bref, j'ai tout lu, et disposant d'exemplaires HP et SuperMicro, j'ai tenté moi-même d'exploiter les failles décrites. Je ne rentre pas dans les détails, tout est déjà très bien expliqué dans la littérature sus-mentionnée. Par contre je vais donner quelques pistes pour l'installation des outils sous FreeBSD.

ipmitool, l'outil de base doit être installé avec FreeIPMI, sinon les manipulations permettant d'exploiter les BMC vulnérables ne fonctionneront pas. Sous FreebSD on peut simplement utiliser les ports :

# cd /usr/ports/sysutils/ipmitool
# make install clean
On active l'option "FREEIPMI" dans la configuration, et c'est parti.

On active l'option "FREEIPMI" dans la configuration, et c'est parti.

Ensuite il est possible d'installer metasploit, outils puissant et complexe. Pour gagner du temps, et si vous ne souhaitez pas approfondir l'usage de ce logiciel, vous pouvez décocher l'option "DB" au moment de l'installation du port :

# cd /usr/ports/security/metasploit
# make install clean

Si vous souhaitez jouer un peu avec les outils et scripts développés par Dan Farmer, vous devrez installer en plus le module perl CaptureOutput.pm, nécessaire au fonctionnement de rak-the-ripper.pl :

# cd /usr/ports/devel/p5-IO-CaptureOutput
# make install clean

Si vous avez en plus une machine disposant d'une BMC qui tourne sur FreeBSD, voici ce qu'il faut faire pour accéder à ce contrôleur parasite via ipmitool :

# kldload ipmi

Cela charge le module ipmi, si ce n'est déjà fait. Vous aurez quelque chose de ce style dans la sortie de dmesg -a :

ipmi0: <IPMI System Interface> port 0xca2,0xca3 on acpi0
ipmi0: KCS mode found at io 0xca2 on acpi
ipmi0: IPMI device rev. 1, firmware rev. 2.35, version 2.0
ipmi0: Number of channels 2
ipmi0: Attached watchdog
ipmi1: <IPMI System Interface> on isa0
device_attach: ipmi1 attach returned 16

Et vous pourrez ensuite vous livrer à toutes sortes d'expériences en local (donc une fois de plus sans authentification…).
La prudence veut que vous désactiviez immédiatement ce module ensuite :

# kldunload ipmi

même si, ne nous voilons pas la face, ça retarderait juste de quelques dizaines de secondes un éventuel attaquant.

Mettez bien à jour le firmware de vos BMC. Et quand je dis bien à jour, c'est très sérieux, puisque des firmwares récents chez HP (juin) ne corrigent pas l'énorme faille du Cipher-0. Il faut utiliser le firmware 1.60 publié fin juillet pour avoir une chance de corriger cette faille de sécurité.

Related posts

Pas tous égaux devant le spam

Là où je travaille, une partie de la population ne reçoit pas de spam, ou presque. L'autre partie reçoit une grosse quantité de spam. La raison est simple : les utilisateurs du second groupe ont leur adresse email publiée sur le portail web de l'université.
Alors bien sûr, c'est une évidence. On le sait tous depuis longtemps : une adresse email publiée sur un site web devient immanquablement, et en l'espace de quelques jours, une cible privilégiée pour le spam. Oui, on le sait. Mais est-ce qu'on le mesure ?
Comme mes serveurs MX brassent des millions de messages par mois, je peux faire des statistiques assez simplement (moyennant de longues heures de traitement sur des giga octets de logs). J'ai donc compté le spam visant les deux groupes, ainsi que les volumes de phishing relevés lors de 4 "attaques" facilement traçables. Le constat est sans équivoque :

Une adresse email publiée sur le portail web de l'université reçoit 31,2 fois plus de spam qu'une adresse non publiée.

Une adresse email publiée sur le portail web de l'université a 59 fois plus de risque d'être la cible d'un phishing qu'une adresse non publiée.

À bon entendeur...

Related posts