As always, a mix of re-reading books I like and new authors & series and some disappointements as well, nothing is perfect…
I did not achieve the 2019 Goodreads contest this time, partly because this has been a bad year work-wise (no I won’t give any details, please don’t ask) and I went another way to compensate for this, I started being more serious about playing World of Tanks1 so it took most of my time. Still read a decent number of books but I felt I didn’t have enough energy to give to books, WoT is easier on my mind in these times. I did not write any blog posts either as you can see apart from these ones.
Our friends at Goodreads have done some nicely presented stats here and this article will go in more details than just stats :)
To the books!
This year again, I feel the best author for me this year is Adrian Tchaikovsky. The followup to “Children of Time” called Children of Ruin didn’t disappoint at all, even exceeded my rather high expectations… I also read The Expert System’s Brother and this is where Adrian surprises me again (no spoilers), this author is exceptional.
None this year, surprisingly enough, felt that there are way too many new books to take some time to re-read others :)
There we find series I started before 2019 like the Ambassador or The Dresden Files.
Quite a few new authors in this section with debut works and I always welcome new voices in these genres.
Only three this year.
Apparenly none this year, surprising enough even for me.
Ok, every year, some books do not make it and stay on the “Reading” list or even fell to the “Nope” one. I have not given up on these but sadly they didn’t caught me as I expected. Maybe later.
So, this year was not as plentiful as the previous one, having a hard time to read, especially in the second part, funny how the brain works… Gaming does exercise it too but in so many different and unexpected ways. It was difficult to find the energy needed to go into a book but shooting tanks was ok. I will try to balance a bit more in 2020.
Some of these books are referenced by a French blog from a friend of mine, either for the original versions or their translations. Do not hesitate to visit Outrelivres, Stéphanie does a great job of reviewing!
And as always, read books by and on women, they know their stuff.
The officiel sites for the authors, GR or WP if no site are available.
See the main EU site if you are interested, I can even “recruit” you if you want to play, that way you get stuff for free. ↩
Once again, I was too shy and blew away my challenge of 42 with reading… 100 1! This was an exceptional year for reading. Not that I mind though but I shall try next year to be more precise… :)
Our friends at Goodreads have done some nicely presented stats here and this article will go in more details than just stats :)
As always, a mix of re-reading books I like and new authors & series and some disappointements as well, nothing is perfect… This article is fairly long of course, due to the much higher number of books :)
To the books!
Without any contest, the best author for me this year is Adrian Tchaikovsky. I discovered him in “Children of Time” and read two more of his books, with a lot of enjoyment each time. It is difficult to stress out of much I enjoyed this first book and there is a following book next year (“Children of Ruin”). Can’t wait to read the Shadow of the Apt fantasy series :)
I know that I have so many books to read that I should try to focus on the new ones but I always find myself going back to books I’ve loved, like old friends :)
There we find series I started before 2017, like Ambassador or The Secret Histories.
I’m not often reading a whole series in one go but that one did clicked enough inside me :)
Lots of new series and authors this year (which means also a lot of upcoming books!).
Like many Froggies, I’m fan of comics, european-style. I didn’t count all the albums I read individually (see below) but I re-read the entire Tanguy & Laverdure set for example.
As many readers of my Twitter feed or this blog, know, Cryptography (mainly the history thereof) is one of my main hobbies and of course, books talking about it as well :)
It will come to no surprise for you readers of my annual article, I’m not much of a French language reader (although I love it) so this section is scarse :)
Ok, every year, some books do not make it and stay on the “Reading” list or even fell to the “Nope” one. I have not given up on these two, I know a lot of people appreciated them (I mean, N. K. Jemisin did not win a Hugo for every book for the last three years for nothing!) but sadly they didn’t caught me as I expected. Maybe later.
Trust me, I’m surprised too.
After a thread on Twitter about how so many people need to relate to the main character(s) in order to appreciate a book, here is my take:
I’m a white cis-het male and I absolutely love books about PoC/WoC/women/LGBT+/aliens/whatever.
I want and need to read about everything I do not know.
Some people want to read about aliens, magic and unicorns but can’t stand books by/with PoC or women? Get lost.
And as always, read books by and on women, they know their stuff.
The officiel sites for the authors, GR or WP if no site are available.
I basically cleared the challenge in… May. I know I’m terrible at predictions ↩
10 ans déjà… depuis ce 21 octobre 2008 où tu es née sans souffle.
Nous t’aimons, nous ne t’oublierons jamais.
]]>I have now completed my API Wrapper series with this new one for the SSLLabs API, currently at v3. It is the perfect complement to the Cryptcheck) API and the Mozilla Observatory one I published earlier.
Welcome to the Golang API wrapper, now at version 0.10.0 (and using Semantic Versioning to ensure compatibility) and available on Github there.
Like many Go libraries and utilities, it is very easy to install:
1
|
|
I use this form because in addition to the library itself, there is a small command included.
The current version of the API wrapper is v0.10.0 (see here)
All calls except for getRootCertsRaw
are implemented. The current list is:
Function | Arguments | Returns | API call |
---|---|---|---|
Info | none | struct ssllabs.Info |
info |
Analyze | site: string | struct ssllabs.Host |
analyze |
GetGrade | site: string | struct ssllabs.Host |
analyze |
GetEndpointData | site: string | struct ssllabs.Endpoint |
getEndpointData |
GetStatusCodes | none | struct ssllabs.StatusCodes |
getStatusCodes |
Currently more than 88% of the code is covered by tests, what is left are some error cases that I find a bit complicated to implement (for now). All the modules are automatically build and tested through Travis CI.
Like the README.md shows, usage is very easy, there are only to main functions, GetGrade
and GetDetailedReport
. You have to initialize the client first of course:
1 2 3 4 5 |
|
You can also pass parameters to NewClient()
to change defaults:
1 2 3 |
|
Changeable parameters include the log level for verbosity (Log
can be 0, 1 or 2) and whether you want to force a re-check of the site to avoid getting a cached version. (Refresh: true
). See the README.md
file.
For convenience, I have also written the ssllabs
utility (found in cmd/ssllabs
of course) if you just want a nice example and a quick reading:
1 2 3 4 |
|
You can run ssllabs
with the -d
option, in which case you will get a JSON dump of the whole report. You can send it over to jq
for further processing.
If you like this module, you can “star” on github, fork it, etc. It is under the BSD 2-clause license.
I use the Semantic Versioning numbering scheme for this API to facilitate developers’ usage and maintenance.
It is also vgo
-compatible and includes the go.mod
file for vgo
metadata. See this series of articles for more details. vgo
aims to be the future scheme to properly manage module dependencies as proposed by Russ Cox.
You can find a very detailed example about using the three API wrappers in my erc-checktls utility, which was at the start of all this. I begun to write it to analyse the output of the SSLLabs utility ssllabs-scan
and during its evolution, I extracted my code into the modules.
Enjoy!
This is a rant. You are warned. Expect strong language. There be Dragons. You can still get away.
I have been protecting my personal DNS zone with DNSSEC for quite some time, it was not difficult, I used the “DNSSEC in 6 minutes” presentation a few years ago and it worked. I have changed the way I manage my zones mainly because Let’s Encrypt happened in my TLS certificates workflow but still use DNSSEC. It is fine.
DNSSEC has this nice concept called DANE (see below) in which one inserts special records in their zones with the signature of the certificates for the various services n-one is running run (mail, web, imap and so on). That way, you do not need to trust a large set of Certificate Authorities (CA) to do the right thing.
We have seen in the past many of them screwing the process of validating ownership of a given domain before issuing certificates. There are ways of protecting this stuff too (The CAA record being a recent one) but still, your average certificate store has litterally hundreds of different CA. Unless you manually remove every single one you do not trust, you trust all.
DNS is hard. That’s a fact. I’ve seen so many people (including me of course) breaking their zone files for some reason (misplaced “;”, not changing the serial number, etc.) so yeah, I know. Been there, done that.
DNSSEC is a great thing but yes, it does complicate some things, mainly key management and rollover. Day-to-day operations are not really changed, especially if you have a decent IPM product (COTS or homegrown) to deal with zone management. So yes, DNSSEC is complicated too.
DANE can be used to validate that the mail server you are connecting to is the right one. DANE does not care whether you are doing web stuff, mail stuff or anything stuff, as long as you are dealing with TLS certificates and validation. You just put a TLSA record with the hash of your public key/certificate/both and the client on the other side can easily check that. And you know that this data has not been modified (signatures and all that.)
but
Many people find DNSSEC too complicated, especially when they have thousands of hostnames, changing frequently (think of Content Delivery Networks or massively parallel infrastructure), they do not want to deal with the cryptographic aspects of DNSSEC, its key management part and stuff.
What else if not our great (NOT!) friend called Not Invented Here (NIH) syndrom?
The nice thing about DANE is that it involves only two entities that are already talking together, the mail server sending mail and its DNS resolver, because everything it needs for DANE is in the DNS. Must be too easy, right?
So some guys at Microsoft, Google and Yahoo! (you know, the biggest mail providers, yadda yadda yadda) invented something that does not need DNSSEC to operate but (wait for it)…
…add a webserver to the mix!
The MTA, in addition to fetching the MX & associated A records, has to
Sounds easy, no?
Wrong
It adds yet another entity (the website) to contact (and timeout with sometimes), yet another completely specific cache for the sending side.
But, that’s not all.
On the receiving site, you will need a specific website (mta-sts.DOMAIN
) with its own certificate (unless you use a wildcard) to host a specific file with a specific format (albeit not in a new location, .well-known
has been accepted as a place to put stuff for some time now).
Oh and of course, everytime you change you policy (the aforementioned file), you need to record the change in the DNS.
Oh and of course, MTA sending to a subdomain of DOMAIN
must not use the policy of DOMAIN
and you must install a policy in subdomains too.
And do not start me on the process of delegating the policies (something you may want to do if you have a lot of them) to another host/entity. If you delegate the policy for example.com
to example.net
, not only you have to use a CNAME
to redirect the names in the DNS but the certificate must remains the same (i.e. example.net
must answer with a example.com
certificate even hosted on foobar.example.net
).
BTW it does less than DANE because in the policy you specify only the MX, not the signatures of the certificates.
Nice way to keep the lucrative (a bit less now thanks to Let’s Encrypt) business of certificates and CA, eh?
All this crap just to avoid DNSSEC whereas they could use their resources and time to properly install & manage DNSSEC.
Fuck this. I might be getting too old for this shit.
Read the draft below and be enlightened (or not).
Stéphane Bortzmeyer has its own analysis — a bit more technical than what you are reading, see below (in French).
Like I did for the cryptcheck.fr
API in the previous article), please welcome the API wrapper for the Mozilla Observatory API. The Mozilla Observatory is a site which include many tests for websites including TLS (SSLLabs & Cryptcheck) and HTTP-related ones (XSS protection, X-Frame, Content Security Policy and many others).
My Golang API wrapper, now at version 1.0.0 (and using Semantic Versioning to ensure compatibility) is available on Github there.
Like many Go libraries and utilities, it is very easy to install:
1
|
|
I use this form because in addition to the library itself, there is a small command included.
The current version of the API wrapper is v1.0.0 (see here)
I have not implemented the full 1.0 API as a few functions do not seem that important to me. I have nonetheless opened an issue about this and comments & discussions are welcome.
Currently Implemented:
Function | Arguments | Returns |
---|---|---|
GetGrade | site: string | the site’s grade: string |
GetScore | site: string | the site’s score: int |
GetScanID | site: string | latest scan ID: int |
GetScanReport | scanid: int | RAW json with full report: []byte |
GetSiteHistory | site: string | All scans: array |
Like the README.md shows, usage is very easy, there are only to main functions, GetGrade
and GetDetailedReport
. You have to initialize the client first of course:
1 2 3 4 5 6 7 |
|
You can also pass parameters to NewClient()
to change defaults:
1 2 3 |
|
Changeable parameters include the log level for verbosity (Log
can be 0, 1 or 2) and whether you want to force a re-check of the site to avoid getting a cached version. (Refresh: true
). See the README.md
file.
For convenience, I have also written the observatory
utility (found in cmd/observatory
of course) if you just want a nice example and a quick reading:
1 2 3 4 |
|
You can run observatory
with the -d
option, in which case you will get a JSON dump of the whole report. You can send it over to jq
for further processing.
If you like this module, you can “star” on github, fork it, etc. It is under the BSD 2-clause license.
I use the Semantic Versioning numbering scheme for this API to facilitate developers’ usage and maintenance.
It is also vgo
-compatible and includes the go.mod
file for vgo
metadata. See this series of articles for more details. vgo
aims to be the future scheme to properly manage module dependencies as proposed by Russ Cox.
Enjoy!
Many of you know the SSLLabs site. Built by Qualys, Inc., it enables anyone to test various TLS-related parameters for given website running on port 443 (the default for TLS). But did you know there is also the cryptcheck.fr one? Formerly known as Imirhil, it allow not only for https
websites to be tested but also SMTP, IMAP, SSH and general TLS (using a different port like a few API do) ones.
Both are integrated in the Mozilla Observatory which also include more tests such as HTTP headers and whether a given site is pre-loaded in browsers (HSTS).
Cryptcheck also has an API to get the information programmatically and I just wrote a Golang library for its API. It is named — not very original I know — as github.com/keltia/cryptcheck
and can be found on Github like many Go modules.
Like many Go libraries and utilities, it is very easy to install:
1
|
|
I use this form because in addition to the library itself, there is a small command included.
The current version of the API wrapper is v1.2.0 (see here)
Like the README.md shows, usage is very easy, there are only to main functions, GetGrade
and GetDetailedReport
. You have to initialize the client first of course:
1 2 3 4 5 |
|
You can also pass parameters to NewClient()
to change defaults:
1 2 3 |
|
Changeable parameters include the log level for verbosity (Log
can be 0, 1 or 2) and whether you want to force a re-check of the site to avoid getting a cached version. (Refresh: true
). See the README.md
file.
I have not included a generic GetGrade()
(without the need to create the client first) because it means no default can be overriden which does make testing rather complicated. Its code, in case you need this, is trivial:
1 2 3 |
|
For convenience, I have also written the getgrade
utility (found in cmd/getgrade
of course) if you just want a nice example and a quick reading:
1 2 3 4 |
|
You can run getgrade
with the -d
option, in which case you will get a JSON dump of the whole report.
If you like this module, you can “star” on github, fork it, etc. It is under the BSD 2-clause license.
As of v1.x, cryptcheck
only implements version 1 of the Cryptcheck API (from tls.imirhil.fr
), the second and more complete version is not yet usable nor really documented (as per its author — Aeris).
I use the Semantic Versioning numbering scheme for this API to facilitate developers’ usage and maintenance.
It is also vgo
-compatible and includes the go.mod
file for vgo
metadata. See this series of articles for more details. vgo
aims to be the future scheme to properly manage module dependencies as proposed by Russ Cox.
Enjoy!
Thanks to Aeris for creating both site and API and not getting too annoyed at my constant questionning and asking for changes & features :)
Cet article est né du constat que plein de gens, pour plein de bonnes raisons, ne savent pas vraiment comment fonctionne la résolution des noms et adresses IP sur les équipements. Du coup, l’annonce de Cloudflare sur 1.1.1.1 (et dans une certaine mesure celle plus ancienne de Quad9) fait se poser plein de questions sur les performances et la gestion de la vie privée sur ces aspects.
J’essaie donc — comme sur Twitter 1 début avril — d’expliquer du mieux possible tout ça. Comme d’habitude, le diable est dans les détails et si l’offre Cloudflare est intéressante, il ne faut pas faire les choses à moitié.
Je ne parlerai pas du protocole DNS et de comment il fonctionne, certains comme Stéphane Bortzmeyer et les documents de référence s’y prennent mieux que moi.
Quand une application ou votre système d’exploitation essaie de résoudre un nom ou une adresse IP, il est fait appel à un bout de code appelé en anglais “stub resolver”. Chaque application intégre ce code d’une manière ou d’une autre.
Ce code, configuré d’une manière assez spécifique selon les systèmes (/etc/resolv.conf
ou équivalent sur les systèmes UNIX/Linux 2 & macOS, un service ou une clé de registre sous Windows) pour savoir à qui s’adresser pour discuter. Ce programme / serveur / service va après suivre le processus classique de résolution en discutant avec les serveurs racines, puis les serveurs intermédiaires, etc. jusqu’à obtention du résultat final.
Cloudflare a annoncé en fanfare son propre service de résolution le 1er avril — choix de date quelque peu bizarre mais passons :) 6. Cloudflare met l’accent sur les performances, s’appuyant sur son réseau mondial pour faire répondre le serveur le plus proche du requérant et sur les aspects de vie privée, promettant de ne pas garder de journaux, etc. Il vient via deux adresses, 1.1.1.1 et 1.0.0.1, le premier étant apparemment utilisé en loucédé par certains équipements ou fournisseurs ce qui peut obliger à utiliser le deuxième 7. Ily a bien évidemment deux adresses IPv6 correspondantes (2606:4700:4700::1111 et 2606:4700:4700::1001).
Il y a quelques mois, la société Quad9 avait elle-aussi annoncée un service équivalent, lui aussi se targant de mieux respecter la vie privée des internautes (pas de rétention de journaux de fonctionnement, possibilité de chiffrer le trafic au travers de DNS-over-TLS, filtrage de domaines avec du malware, etc.)
Le premier à avoir faire ça étant Google avec ses fameux 8.8.8.8 et 8.8.4.4, resolvers ouverts et validants accessibles partout dans le monde 8. C’est également avec Google qu’on a vu apparaître la « mode » des adresses IP facilement mémorisables 9. Reconnaissons néanmoins à Google d’avoir augmenté de manière significative le nombre de gens utilisant un resolver validant DNSSEC, 8.8.8.8 le faisant par défaut.
La différence principale que je vois dans l’offre Cloudflare est que comme c’est réalisé en partenariat avec le registre d’adresses IP APNIC (Asie-Pacifique), on peut supposer que ces aspects vie privée vont être plus respectés que ce que l’on pourrait attendre de Google (aucun) ou Quad9 (non vérifiés à ce jour que je sache).
Le truc est que l’on délègue la tâche de resolution à un tiers que l’on ne contrôle pas, sans même parler des aspects détournement et trafic en clair.
La suggestion que plein de gens font — à raison — est de faire la résolution… soi-même. C’est assez facile à réaliser pour peu qu’on ait le minimum de connaissance technique et un peu de moyen. Ça consiste à faire tourner son propre service de résolution au travers d’utilitaires comme Unbound, Bind ou encore Knot Resolver.
On peut faire ça sur sa propre machine / routeur ou sur une machine distante (genre, hors de France).
Sauf que ça ne va pas assez loin en soi si on veut vraiment que rien ne soit visible. Le trafic restera en clair, restera interceptable et détournable pour le FAI et les performances risquent de ne pas être au rendez-vous. Ça restera une faille unique (à moins d’avoir plusieurs serveurs) également.
Parlons maintenant des deux aspects :
Aussi bien Cloudflare que Quad9 et Google résolvent l’aspect performances comme le montre le site DNSPerf, Cloudflare est devant, suivi de près par Quad9 et Google. OpenDNS a aussi son propre service mais je ne suis pas personnellement sûr de la qualité de leur réponse, leur business model étant justement plus sur l’aspect safe et filtré.
Il existe plusieurs manières de rendre le trafic DNS confidentiel :
Notons tout de suite que si la 4ème possibilité (Tor) assure la confidentialité des échanges (pas seulement du DNS), l’impact sur la performance de la navigation est assez important et, pour l’immense majorité des usages, ne concernent que ce qui passe par un navigateur, à moins de tout faire passer par Tor.
Cloudflare permet aussi bien le premier que le deuxième (que je n’ai pas exploré encore), pour l’instant Quad9 ne permet que DNS-over-TLS (mais leur site manque à la fois d’explication et d’information, notamment comment vérifier l’identité du serveur resolver sur son port 853).
Pour un système UNIX/Linux que l’on contrôle, il est possible de configurer DNS-over-TLS mais ça reste un peu compliqué.
La plupart des resolvers actuels ne permettent pas directement de faire du DNS-over-TLS, il faut passer par un étape intermédiaire, le démon stubby. Celui-ci, soit au travers du paquet getdns
soit tout seul, est capable de se connecter à de multiples sources extérieures et de répondre à un resolver. Par contre, comme il ne fait pas cache du tout, il faut lui coller un unbound
/knot-resolver
/bind
devant.
Ça donne le schéma suivant :
client -> unbound|knot-resolver|bind -> stubby -> {1.1.1.1,9.9.9.9}
L’intérêt à utiliser plusieurs sources va paraître assez évident, essayer de noyer un peu le trafic entre celles-ci et rendre plus difficile la corrélation entre les requètes 11.
On me signale (merci Yann) un tutoriel pour utiliser unbound
en mode DNS-over-TLS sans stubby
:
Aucun mécanisme n’est parfait ni aucune solution à tous les problèmes. On a plutôt un ensemble de morceaux qui, mis bout à bout, offre un éventail de mécanismes qui aident, dans leur ensemble à préserver et les performances et le respect de la vie privée. Les avocats du « rien chez un prestataire extérieur » ont des objections tout à fait valables mais pour ce que je peux voir, pas de solution(s) globale(s) à part faire tout soi-même, ce dont on vient de voir les limites.
Ne pas oublier non plus qu’ils s’agit de sociétés de droit américain ce qui, compte tenu de certains événements et de l’avénement de Trump, est clairement un souci 12.
Personnellement, pour à la fois améliorer les performances de résolution (mon FAI a trop de problèmes), je passe par DNS-over-TLS via stubby
+unbound
connectés à 1.0.0.1/9.9.9.9 et je vais surveiller comment ça fonctionne.
À vous de décider ce qui vous est approprié.
Le site DNSPrivacy donne plein d’informations sur tous les aspects (en anglais).
(merci Stéphane et Nolwenn pour la relecture)
https://twitter.com/Keltounet/status/980927623529402369 et suivants. ↩
Avec l’avènement de l’horreur appelée systemd qui réécrit (mal) le monde, je finis par ne plus vraiment savoir comment ça fonctionne (ou pas). ↩
DNSSEC est un ensemble d’extensions au DNS classique destiné à générer des signatures électroniques des données présentes dans les zones DNS ce qui permet de s’assurer 1. que la réponse vient bien de la bonne origine et 2. que la réponse n’a pas été altérée en route. ↩
Souvent en renvoyant des réponses tronquées ou sans les signatures DNSSEC. ↩
Je soupçonne d’ailleurs SFR de faire quelque chose d’analogue sur son réseau en « fausse fibre » car j’ai souvent des soucis DNS le week-end et ce même en utilisant mon propre resolver… ↩
Ceci étant, il y a un précédent célèbre, Google Mail aka GMail a aussi été annoncé un 1er avril… ↩
Notamment par SFR et RED-by-SFR en France
…modulo les diverses censures de certains pays bien évidemment. ↩
Ça beaucoup été utilisé en Turquie lors des troubles en 2016-2017 où, suite à la censure Internet des autorités, 8.8.8.8 était apparu sur des murs pour rappeler aux gens comment la contourner. ↩
Je connais DNSCrypt de nom mais je n’ai pas encore exploré ses possibilités, surtout comparé aux deux autres. ↩
Il reste encore quelques doutes sur le fait qu’on puisse déduire tout ou partie du trafic même chiffré et le groupe de travail sur DNS-over-TLS réfléchit à améliorer les choses par du padding, etc. ↩
Cloudflare, de par sa position dominante dans les réseaux de distribution de contenus (CDN en anglais), fait un peu trop ce qu’il veut, notamment bloquer/dégrader fortement Tor cf. The Cloudwall. ↩
J’en ai un peu parlé dans le premier article de cette série, celui consacré à la mort de l’Amiral Yamamoto. La bataille de Midway, qui se passe peu de temps après la bataille de la Mer de Corail en mai 1942, marque la fin de la suprématie japonaise et l’arrêt des conquêtes. C’est aussi l’aboutissement d’années d’efforts conjugués entre Américains et Britanniques dans le domaine cryptographique pour casser les codes statégiques japonais, notamment le JN-25.
Cette bataille ainsi que celle de Midway, s’inscrivent dans la stratégie de conquête du pacifique des japonais, aidés par les pertes assez faibles jusqu’à présent et la victoire à Pearl Harbour. De vastes étendues ont été conquises en quelques mois, des Philippines, la Malaisie, Singapour puis ce qui est maintenant l’Indonésie 1.
Yamamoto , plus conscient que bien de ses compatriotes de la puissance des Américains et de leur industrie militaire, veut en finir le plus vite possible avec la flotte du Pacifique, surtout que les porte-avions n’étaient pas présents à Pearl Harbour. D’autant que le raid des B-25 du Major Doolittle en avril 1942 sur Tokyo elle-même, avait montré la puissance des forces aéroportées US lancées du porte-avions Hornet 2.
Rappelons nous l’article sur la mort de Yamamoto, le système de chiffrement stratégique du Haut commandement japonais est le code JN-25, gros dictionnaire en deux parties de plus de 30 000 groupes de 5 chiffres 3 avec comme sur-chiffrement une clé additive dans deux recueils de plus de 50 000 groupes.
Du fait de la taille du dictionnaire (plus de 30 000 groupes), la tâche est compliquée. De part la taille de la clé additive, ça devient titanesque, jusqu’à ce que l’on considère un ensemble de choses :
Le point 3 est le plus intéressant puisqu’il va permettre d’ouvrir des brêches dans le point 2 puisqu’on va, au travers d’erreurs de chiffrement, de transmission multiples de messages avec des codes différents, de phraséologie connue et d’envoi répétitif de messages identiques ou peu s’en faut. Le livre de Michael Smith donne pas mal d’exemples sur la manière de casser de tels systèmes.
C’est le britannique John Tiltman qui va le premier « entrer » dans le JN-25.
C’est un procédé itératif, long et compliqué (il faut trouver notamment des messages chiffrés avec la même portions de clé additive afin que de par la magie des mathématiques, on puisse la faire disparaitre). Une fois qu’on a des messages sur-chiffrés avec la même portion de clé, on peut essayer de retrouver, aidé par la connaissance du format des messages et d’un peu de chance sur le contenu, soit des groupes clairs déjà connus soit en déduire de nouveaux.
Les Américains vont industrialiser le processus en employant des machines IBM qui permettent de comparer et trier des dizaines de messages beaucoup plus rapidement que les humains 4.
L’unité qui s’en occupe est appelée OP-20-G et est dirigée depuis mai 1941 par le Lieutenant Commander Joseph John Rochefort.
Cette unité a été créée en 1922, anciennement “Code and Signal Section” dans la Department of Naval Communications, leur principal travail consiste à casser les systèmes allemands, italiens et japonais. Après Pearl Harbour en décembre 1941, leur principal travail fut de reconstituer le code JN-25 que les Anglais ont entamé avec notamment la Hut 7 à Bletchley Park, centre névralgique du GC&CS en Angleterre 5.
Le 3e point va aider les Américains : les Japonais ont conquis de grandes étendues, très vite et de ce fait les lignes de communication se sont grandement étirées et la conséquence la plus directe est que le changement du JN-25b par le JN-25c, initialement prévu en avril 1942 va être repoussée d’un mois 6.
C’est ainsi que vers le 17 avril, les Américains ont, au travers de leurs décryptages fragmentaires, déterminé le plan de l’invasion de Port-Moresby en Nouvelle Guinnée et c’est ainsi que la bataille de la Mer de Corail a pu être menée et gagnée.
La bataille de la mer de Corail est néanmoins en demi-teinte pour les Américains, bien qu’ils aient réussi à empêcher l’invasion de Port Moresby et de l’île de Tulagi et détruit deux porte-aviosn (“Shoho” et “Shokaku”), ils ont perdu le Lexington et le Yorktown est fortement endommagé 7.
Le changement de code va de nouveau être repoussé au 1er juin, erreur qui va être fatale.
En ce mois de mai 1942, les Américains et les Britanniques ont reconstitué environ un tiers du JN-25b et des portions de la clé additive, ils peuvent ainsi décrypter environ 90 % des messages.
Midway est un petit atoll perdu dans le pacifique, à quelque distance de l’île de Wake et stratégiquement placé sur la route vers Hawaii et Pearl Harbour, base de la flotte US du Pacifique. Son attaque devait attirer le reste de la flotte US qui aurait été écrasée par les porte-avions japonais, aidés par des cuirassiers (qui furent trop loin pour intervenir au final). Ce plan comportait une diversion avec une attaque sur les îles Aléoutiennes.
Début mai, le plan de bataille de l’invasion de Midway et des Aléoutiennes est diffusé aux différentes forces navales et aéronavales japonaises, divisées en plusieurs armadas. Il est décrypté à environ 80-85 % mais il reste quelques inconnues, notamment dates et confirmation des lieux. Se pose aussi la question de la cible réelle ? Midway ? Les Aléoutiennes (qui sont très proches des USA) ? Hawaii ?
L’Amiral Chester Nimitz est persuadé que Midway est la cible mais le reste du Haut-commandement US n’est pas convaincu.
L’ordre de bataille japonais cite AF comme étant l’objectif principal. Les Japonais, comme beaucoup d’armées utilisaient des cartes avec des noms de codes pour les lieux principaux ce qui facilitait à la fois la transmission et permettait d’éviter les erreurs de transcriptions. le code s’appelle CHI-HE et quelques semaines auparavant, des avions japonais passant au dessus de Midway avaient transmis AF comme lieu. Pour en être totalement sûr, Rochefort conçoit un plan ingénieux, laisser Midway transmettre en clair un message de service assez anodin, en l’occurrence à propos de son désalinisateur d’eau qui aurait subi une panne.
Deux jours après, dans les différents messages décryptés, ils apprennent que AF manque d’eau potable…
Comme les lieux, les différentes dates sont également chiffrées mais c’est là plus compliqué, c’est une substitution polyalphabétique avec deux alphabets de 47 signes générant une table de 2 209 entrées… C’est l’assistant de Rochefort, Wright, qui va passer la nuit et finalement réussir à convaincre Rochefort de la validité de sa solution.
Nimitz sait dorénavant que l’invasion démarre le 2 juin dans les Aléoutiennes et le 3 pour Midway. Il va envoyer ses porte-avions Yorktown 8, Enterprise et Hornet à POINT LUCK, un endroit situé à 325 miles au nord de Midway, là où il espère qu’ils seront plus difficiles à trouver pour les Japonais qui pensent bénéficier de la surprise.
Le reste fait partie de l’Histoire, comme on dit…
Au premier juin, les Japonais ont commencé à enfin diffuser le JN-25c qui sera peu reconstituté avant la mise en service du JN-25d en août 1942 de manière inattendue. On voit que si les Japonais avaient réussi à changer le code au mois de mai (à fortiori en avril), la face de la guerre aurait pu être complètement changée puisque les Américains auraient été privés de ces informations.
Privés de la surprise qu’ils avaient pourtant mis au centre de leur plan, les Japonais vont essuyer une défaite sévère, ils perdent 4 porte-avions (Soryu, Akagi, Kaga en premier et le Hiryu le jour d’après), des milliers d’hommes et ne réussissent à couler que le Yorktown.
Nimitz déclara que la victoire de Midway était essentiellement une victoire du renseignement. Peu de décryptages eurent autant d’importance que celui de l’OP-20-G aidé par les Britanniques pendant une guerre. Les travaux sur le JN-25b sont à rapprocher du décryptage du télégramme Zimmerman qui précipita les USA dans la 1ère Guerre mondiale.
En 1976, Jack Smight dirige le film “Midway”, version un peu romancée et surtout passant quasiment sous silence les aspects cryptographiques. La distribution est prestigieuse (Charlton Heston, Henry Fonda, James Coburn, Toshirô Mifune, Robert Mitchum, Glenn Ford et Robert Wagner) mais l’histoire aurait pu se passer du chapitre sur les internés américano-japonais.
La taille très importante de ces conquêtes a son importance dans ce qui nous intéresse… ↩
Paradoxalement, ces mêmes militaires avaient expérimenté la puissance de leur propre flotte avec le raid de Pearl Harbour… ↩
Une des caractéristiques du JN-25 qui aidera beaucoup les Britanniques et les Américains réside dans le fait que, pour pouvoir facilement vérifier qu’un message est déchiffré correctement, chaque groupe est divisible par trois. On comprendra aisément l’intérêt d’une telle particularité pour les cryptanalystes… ↩
On parle de machines électro-mécaniques, pas encore d’ordinateur mais étant très spécialisées, elles resteront pendant longtemps plus rapides que les ordinateurs, plus généralistes et plus compliqués à programmer. ↩
Contrairement à ce qui a été longtemps cru, Bletchley Park n’a pas travaillé que sur Enigma ou la machine à chiffrer de Lorenz. ↩
On parle quand même de diffuser des documents volumineux et secrets à des centaines d’exemplaires vers des lieux très éloignés et surtout, des bâtiments qui par définition bougent. La tâche est énorme. ↩
À ce propos, ma première exposition à ces faits d’armes fut au travers de la BD de Charlier et Hubinon, Buck Danny. ↩
Malgré l’estimation de plusieurs semaines pour la réparation du Yorktown, les ateliers de Pearl Harbour vont réussir l’exploit de le remettre en ordre de combat après 72 h de travail acharné… ↩
Comment la cryptographie a permis d’innocenter le principal accusé de l’affaire Dreyfus
L’affaire Dreyfus restera comme la plus connue des histoires d’espionnage de la Belle époque, moins pour les aspects liés à la cryptographie qu’à ceux liés à l’antisémitisme d’une partie de la population.
L’affaire ébranlera la République au travers de la chute du gouvernement Dupuy et le « J’accuse ! » de Zola.
Fin septembre 1894, le « bordereau », un mémo annonçant la livraison prochaine de documents stratégiques à l’Allemagne tombe entre les mains du Commandant Henry, du service de Contre-espionnage. C’est une lettre adressée à von Schwartzkoppen, l’attaché militaire allemand en poste à Paris. Une enquête interne est ouverte par le ministère.
Elle conclut à l’implication d’un stagiaire de l’État-major, un artilleur, qui aurait écrit le bordereau. Les soupçons se portent alors sur le capitaine Alfred Dreyfus, polytechnicien et juif d’origine alsacienne.
C’est un coupable idéal, il est issu de la méritocratie républicaine et le seul juif passé par l’État-major. La réputation de Dreyfus d’avoir un caractère fermé et froid et d’être hautain va jouer contre lui. On va donc assister à la victoire de la conviction, aussi fausse et partiale qu’elle soit, sur les faits.
Va suivre une séance d’analyse des écritures — du bordereau et celle de Dreyfus — par les experts auto-proclamés du ministère avec en particulier le commandant du Paty de Clam, qui conclut très rapidement à la culpabilité de Dreyfus. Un autre expert, Alphonse Bertillon, ira jusqu’à dire que Dreyfus s’est auto-contrefait pour expliquer les différences d’écriture. Que ne ferait-on pas pour justifier ses convictions ?
Le ministre et général Mercier tenant un coupable décide de poursuivre malgré le dossier vide.
Donc, le 15 octobre, Alfred Dreyfus est convoqué pour une réunion avec des officiers supérieurs au ministère de la Guerre (pas encore de la Défense !), rue Saint-Dominique à Paris. Le but est de provoquer des aveux en lui faisant copier une lettre inspirée du bordereau mais Dreyfus n’avoue pas. Du Paty de Clam essaiera même de lui proposer le suicide avec une arme posée devant lui.
Dreyfus refuse, il « veut vivre afin d’établir son innocence ». Du Paty de Clam l’arrête néanmoins. L’arrestation était secrète mais le 29 octobre, le journal antisémite « La Libre parole » sort un article
« Haute trahison. Arrestation de l'officier juif Alfred Dreyfus ! ».
C’est le début d’une bataille médiatique énorme.
(je ne vais pas résumer l’affaire elle-même, wikipedia et plein de livres en parlent mieux que moi)
Ce qui suit est l’histoire d’un document qui fera partie du dossier secret qui sera illégalement fourni par du Paty de Clam à la Cour pendant le Conseil de guerre qui aboutit à la condamnation de Dreyfus le 22 décembre, sa dégradation et son envoi au bagne à l’île du Diable en Guyane.
Lors de la sortie de l’article de La Libre parole, l’attaché militaire italien, le colonel Panizzardi, inquiet de voir mentionné que Dreyfus ait pu avoir travaillé pour l’Allemagne ou l’Italie, contacte ses chefs à Rome pour dire qu’il n’a jamais eu de contact avec Dreyfus, tout en précisant que ça aurait pu se faire sans qu’il le sache lui. Le 2 novembre, voyant la campagne de presse s’intensifier, il décide d’envoyer un télégramme demandant de publier un démenti si Dreyfus n’a jamais été en contact avec Rome.
Le télégramme chiffré bien sûr, est comme tout ce qui passe par les télégraphes des PT&T, intercepté pour décryptage.
913 44 7836 527 3 88 706 6458 71 18 0288 5715 3716 7567 7943 2107 0018 7606 4891 6165 | Panizzardi
Le Bureau du chiffre est constitué de 7 personnes, son chef est Charles-Marie Darmet, 59 ans. Ça fait 3 ans qu’il est en place à ce poste. Les cryptanalystes, voyant le mélange de groupes de 1-2-3-4 chiffres y voient l’utilisation d’un code — ou nomenclateur cf. l’article précédent — commercial appelé Baravelli.
Ce code est divisé en sections. La 1ère contient les voyelles et ponctuations, la 2ème les consonnes, quelques formes grammaticales et verbes auxiliaires, la 3ème des syllabes et la dernière des mots et phrases. Certains groupes de 4 chiffres sont laissés en blanc pour permettre à l’utilisateur d’ajouter des mots.
Anecdote amusante, quelques mois auparavant, des télégrammes entre le Comte de Turin, neveu du roi d’Italie et la Duchesse Grazioli, voluptueuse italienne vivant en France avaient été interceptés. Sandherr, chef du Renseignement militaire avait pu récupérer un exemplaire du code sous la forme d’un petit livre fortement parfumé, volé dans les affaires de la Duchesse. Les télégrammes s’étaient avérés ne contenir que les échanges enflammés des deux amants.
À l’époque, les codes tels que le Baravelli étaient commercialisés et, pour obtenir une certaine sécurité, employaient diverses techniques pour surchiffrer : on pouvait soit faire des additions groupe à groupe (comme pour le code JN25) soit changer la pagination des différentes sections. Pour “Reischtag” ça donne page “75” + groupe “78”
soit “7578” mais pouvait se transformer en “1378” en changeant le numéro de page en haut pour un “13”. Pour la 1ère section, il suffisait de changer chaque chiffre. Du coup, les cryptanalystes tentèrent au départ de déchiffrer « en l’état ». Le résultat n’était pas cohérent :
Une des caractéristiques du Baravelli allait aider, à savoir cette division des mots en catégories avec des groupes de taille différente. De plus, compte tenu du contexte médiatique, penser que le télégramme pouvait parler de l’affaire Dreyfus était logique, Panizzardi étant attaché militaire en poste à Paris.
Selon le Baravelli tout seul, Dreyfus, s’écrirait “dr e y fus” soit “227 1 98 306” (page 2 colonne 27, ligne 1, etc.).
Remarquons les groupes “527 3 88 706” du télégramme, non seulement c’est la même structure mais aussi les mêmes bases (sauf pour le chiffre seul évidemment) pour “27”, “8” et “06”. On voit donc que Panizzardi a utilisé une pagination particulière pour son exemplaire. Le décryptage très partiel aboutit le 6 novembre à un texte très ambigu d’autant que de prime abord, “913” avait été traduit par “arrestato” alors qu’il ne s’agissait que du numéro du télégramme.
« Si le capitaine Dreyfus n'a pas eu de relations avec vous, il serait bien que l'ambassadeur
publie un démenti officiel. Notre émissaire prévenu. Panizzardi. »
qui va être interprèté contre Dreyfus par Sandherr via les brouillons de décryptage et envoie tout à du Paty de Clam.
Le 10 novembre, les cryptanalystes cassent la pagination de Panizzardi donnant le texte clair
« Si le capitaine Dreyfus n'a pas eu de relations avec vous, il conviendrait de faire publier
par l'ambassadeur un démenti officiel pour éviter les commentaires de la presse. »
Le texte clairement va dans le sens de l’innocence de Dreyfus, ce qui ne plait pas à Sandherr mais il va néanmoins accepter un dernier test : faire passer une information à Panizzardi de telle sorte qu’il l’envoie “verbatim” à ses chefs ce qui permettrait de valider les travaux des cryptanalystes. L’un des mots était “Schlissenfurt” dont le chiffrement ne pouvait être ambigü. Ce télégramme, décrypté indépendamment par le Quai d’Orsay, prouve la véracité du texte final.
Malgré tout ceci, la volonté des anti-Dreyfus — qui allèrent jusqu’à falsifier des documents y compris une fausse version du télégramme Panizzardi qui était incohérente avec le code Baravelli — n’empêchera pas ni la condamnation ni la déportation de Dreyfus. Même le décryptage devant la Cour de Cassation d’une copie n’y changera rien.
Il faudra attendre 7 ans pour que Dreyfus soit réhabilité avec la Légion d’honneur. La cryptographie aura tenté — et réussi — à innocenter un innocent mais reste un outil dans les mains des hommes.
Comme quoi il ne faut jamais laisser la vérité (ou la cryptographie) se mettre en travers d’une bonne histoire (sic).
Storify est mort, vive le blog !
Cet article et le suivant ont été publié sous forme de fil de tweets, lui-même regroupé par feu storify.com en Tweet story. Pour faciliter l’exploration via des moteurs de recherche, je les re-publie sous forme de billet.
On commence par deux petits rappels, l’un sur Yamamoto et l’autre sur la cryptographie 1 (rapide !)
Isoroku Yamamoto est le héros de toute l’armée japonaise, commandant en chef de la Marine.
Il a conçu l’attaque de Pearl Harbor (mais pas responsable du timing qui en a fait une trahison en droit international 2 3).
Donc, Yamamoto, en plus de ses états de service brillants, est aussi champion d’échecs de la marine et excellent au poker. Il a voyagé beaucoup dans le monde, a fait des études à Harvard et a même été attaché militaire à Washington dans les années 20.
Brillant stratège, adepte des attaques aéroportées très agressives (cf. Pearl Harbor donc), idolâtré par ses hommes.
Voici pour le personnage lui-même, inutile de préciser que les Américains le détestent pour Pearl Harbor, ne pouvant pas savoir que Yamamoto avait prévu que l’attaque ne commence qu’après la déclaration de guerre mais les circonstances (à l’ambassade japonaise à Washington — ça mérite un billet oui) en ont décidé autrement.
Je vais essayer de ne pas entrer trop dans les détails (Midway, n’oubliez pas !) mais un peu.
Le système japonais de l’époque au niveau stratégique s’appelle JN-25 pour les Américains et “D” puis “RO” pour les Japonais. C’est un code (oui, dans les temps anciens ça s’appelait un “code” ou “nomenclateur” par opposition aux “chiffres”).
C’est en gros un dictionnaire, contenant des phrases & des mots et leur équivalent en « mots » de 5 chiffres. Par exemple, dans une édition “94807” représente “3F”, “31614” et “42007” représentent “3F⚐” (whatever that means). En soi la sécurité est relativement faible donc ce système est protégé (sur-chiffré donc) par une clé additive (un ensemble de mots de 5 chiffres « aléatoires » ajoutés par addition sans retenue (un XOR / OU exclusif quoi) :
73535 ⨁ 92745 => 65270
Ça permet de rester sur des groupes de 5 chiffres. On y ajoute généralement un ou plusieurs groupes « indicatifs » pour donner le numéro du message, la clé additive utilisée, etc.
Il est important de préciser que ce sont les Britanniques de Bletchley Park (GH&CS) et leurs divers bureaux dans le monde qui ont commencé la lourde tâche de reconstituer le JN-25).
Les “chiffres” par opposition aux “codes” travaillent lettre par lettre.
Le système JN-25 était changé à peu près tous les 6 mois, rendez vous compte, ça faisait distribuer — sans Internet ! — environ 2 000 000 d’exemplaires d’un document énorme, le tout sur l’étendue de l’avancée de l’armée japonaise.
La clé additive était changée si possible tous les mois mais souvent moins que ça (ai-je déjà mentionné Midway ?)
Les aléas de la guerre, de l’avancée des troupes japonaises, des victoires & défaites compliquait cette distribution bien évidemment. De plus, les erreurs de procédures voire de chiffrement compliquaient l’usage pour les Japonais (et aidaient les Américains !).
Campons le sujet : nous sommes au printemps 1943, les Japonais viennent de se faire jeter de Guadalcanal et les attaques aériennes des Américains touchent les approvisionnements. Yamamoto décide d’aller remonter le moral aux troupes dans les îles Salomon, notamment sur l’île de Bougainville. Il faut bien évidemment avertir les différentes bases et donc diffuser la planification. Quoi de mieux que le plus secret des codes pour diffuser cette information ?
Le JN-25 est donc utilisé pour chiffrer et protéger cette information vitale et hautement confidentielle.
La clé additive a été changée récemment, le 1er avril (si si) mais elle est déjà largement reconstituée et introduite sur des cartes dans les machines mécaniques IBM (et oui, déjà) utilisée par les cryptanalystes.
Quelques semaines avant, les Américains avaient intercepté le sous-marin I-1 et récupéré une partie de ses documents dont des éléments de la clé additive courante pour le JN-25. Can you see it coming folks? #oops
Les différents cryptanalystes de l’armée US s’échangeant leurs informations, le texte est rapidement décrypté et quelques éléments manquants sont rapidement ajoutés et le message traduit en anglais.
Les lieux sont pré-encodés par des groupes de lettres, plus pratiques : RR = Rabaul, RXZ = Ballale Island, etc.
Yamamoto étant extrêmement ponctuel, les Américains ont quasiment minute par minute le programme et les lieux de passage de l’amiral japonais. Se pose maintenant le dilemme de la vie pour l’amiral Chester W. Nimitz.
Il doit décider en fonction de ce qu’il sait de Yamamoto et ce qui pourrait résulter de sa mort pour les Japonais le tout balancé avec ce que ça pourrait engendrer en terme de perte cryptographique si les japonais comprennent comment ils ont été au courant. La zone est gérée par l’amiral William F. Halsey et Nimitz est son chef direct.
« Un tien vaut mieux que deux tu l’auras » va prévaloir mais Nimitz va quand même préparer une histoire « plausible » 4 comme couverture pour limiter les dégâts pour les cryptanalyste. L’arrêt de mort est scellé, reste à l’exécuter.
Le 17 avril 1943 se prépare le plan de bataille. Pour minimiser les risques, il est décidé une interception en vol plutôt qu’à terre. Le souci est que la base la plus proche est Guadalcanal, presqu’en limite de portée du P-38 Lighting. Ils décident de l’intercepter à 35 miles de la base pour éviter les chasseurs à terre, l’avion ayant déjà au moins 6 chasseurs d’escorte, les Zeros. Tout le plan s’appuie sur la ponctualité légendaire de Yamamoto.
Le lendemain 18 avril 1943 à 7:25 (heure US), 18 P-38 décollent de Guadalcanal. 35 min plus tard à 700 miles l’avion de Yamamoto décolle, parfaitement à l’heure. Après 2h 9 min de vol au raz des vagues dans un silence radio total en contournant les îles Munda, Rendova et Shortland, à 5 miles devant, apparaissent les avions du convoi.
Le timing est parfait.
— « Bogey. Ten o’clock high » lance le Lieutenant Doug Canning. 14 P-38 montent à 20 000 pieds pour s’occuper de l’escorte. Le capitaine Thomas G. Lanphier Jr. et son wingman Lt. Rex. T. Barber montent et atteignent l’avion de Yamamoto qui tente de s’échapper au dessus des arbres. Lanphier détruit un des Zeros de l’escorte et tire plusieurs rafales sur le bombardier. Le moteur droit puis l’aile prennent feu. Au moment où Lanphier arrive à portée du mitrailleur arrière, l’aile droite s’arrache et le bombardier plonge. Son équipier détruit le deuxième bombardier Mitsubishi. Les deux s’échappent à 20 000 pieds rapidement et repartent vers la base d’Henderson Field à Guadalcanal. Tous sauf un rentreront sains et saufs.
À Rabaul, le corps de Yamamoto, retrouvé calciné sur son siège, est soigneusement retiré de la carcasse et solennellement incinéré selon la tradition japonaise. Le 21 mai 1943, le présentateur de la radio japonaise annonçant le décès de Yamamoto est presqu’en larmes. Le coup porté à la nation japonaise est immense. Son successeur déclara sa perte comme insurmontable.
L’urne avec ses cendres est enterrée avec les honneurs nationaux au Hibiya Park à Tokyo le 5 juin 1943.
Pour éviter de donner trop de publicité et surtout d’éviter des questions sur le comment, les Américains ne parlèrent pas de cette victoire chez eux et seuls les rapports venant des journaux japonais furent diffusés.
L’information finit par filtrer mais plus tard et sans trop de détails. Apparemment, même ceci n’atteignit pas l’État-major japonais et le changement d’édition pour le JN-25d au mois d’août semble avoir été prévu.
Le gouvernement américain a même failli faire jouer le Espionnage Act de 1917 pour éviter les sorties dans la presse.
Voici comment la cryptographie a joué un rôle majeur dans la fin du génie de Pearl Harbor le 18 avril 1943.
La vraie cryptographie, rien à voir avec les crypto-monnaies, qui reposent plus sur des preuves de travail avec divers hachages. ↩
On verra sans doute Pearl Harbor dans un autre billet. ↩
Il faudra aussi en faire un sur la bataille de Midway parce que les avancées cryptanalytiques à cette période ont permis la mort de Yamamoto. ↩
Ladite couverture est de faire croire que des indigènes de Rabaul ont renseigné les Australiens qui surveillent les côtes et recueillent des informations, ceux-ci ayant la réputation de renseignements de haute qualité. ↩
Hopefully I have broken the bad luck series I have been in the past two years; not only I managed to read all the books I planned to, I even manage to more or less explode my challenge with 65 books out of 35 \o/. What happened? Better work conditions with my new position and a new house might just have been what I needed so I could find more time for reading…
Our friends at Goodreads have done some nicely presented stats here and this article will go in more details than just stats :)
As always, a mix of re-reading books I like and new authors & series and some disappointements as well, nothing is perfect…
To the books!
There we find series I started before 2017, like the The Frontier Saga or The Secret Histories.
It does not happen often but I got into a binge-reading frenzy toward the end of the year. I guess some book or discussion reminded me of the various series by David Eddings, namely The Belgariad, The Malloreon, The Ellenium and The Tamuli. So except for The Hidden City, I read all the books…
As usual, some books never make it to the “Read” state. Something was wrong with it, I didn’t felt anything, got bored and finally never managed to get back to these.
You may have noticed over the years that I read a lot of books written by women. From Fantasy to Space-Opera, they always manage to surprise me and show incredible skills in weaving stories. No surprise there to find strong female characters and I do enjoy this. I fully intend to keep on discovering new authors and series in 2018 :)
Here is her review on Outrelivres ↩
“Everything is better with Dragons!” — more or less then feeling of many on Twitter, including me :) ↩
A long time ago, I got a RIPE Atlas probe from a friend of mine — who does not know Stéphane Bortzmeyer?. For those who don’t know, these probes creates a big friendly botnet that enables all users — including you, whether you have one or not — to create “measurements” on the global Internet.
Measurements are used today to (guess what) measure things like DNS queries, network latencies and more. Having a probe enables you to participate by submitting your own network data. The more probes there are, the better. It has been frequently used on the past to find out about DNS censorship like here, here or here.
How does it work? The probes have a set of builtin measurements that get sent regularely to the RIPE servers and there is an API available to make queries out of these probes. There is of course an official tool available but it is in Python. While I could just use it, I do not like Python.
Various tools are available in different languages as well here.
As a Golang fan, I’ve tried to use these and was never satisfied. Either the CLI sucks or the tool had too many dependencies or something else. So you can guess, I had to write one myself. That was also an excuse to play a bit more with Go as a language :)
And today, I released version 0.21 of my so called ripe-atlas tool. After (way too many) commits, changes and test-by-errors, it is now usable.
Of course it is still lacking many features — mainly related to output formatting — but both the Go API and the CLI tool are usable. In the coming months, I plan to add templating support to the CLI tool (atlas
) whiled the API itself should be relatively stable.
The API itself is v2-only; while I was beginning to write ripe-atlas
, they moved from API v1 to API v2 and I decided to only implement v2, v1 being officially deprecated. I tried to play with Swagger to save myself some lines of code (LOC) as the documentation is generated by it but while it is fine when you are designing an API, when you have re-create all the stuff yourself, it is cumbersome.
I started using one of these REST libraries (after testing a few, I settled on the Sendgrid one) but in the end, after writing the HTTP proxy code, I ended up using on the standard HTTP client which is fine for my usage.
The API itself is very rich and has a lot of parameters; that tends to complicate both the API usage and its configuration. It also make the atlas
tool complicated as well, I’m sure there are improvements to be made to its UI.
I tried to implement as many unit tests as possible but I always gets behind. TDD (Test-Driven Development) is a fine concept and I try to use it as much as possible but when I’m writing I generally do not know exactly how I want to shape things which means I would spend way more time thinking about the tests and less on writing it. I am ok with the philosophy but I can’t seem to be able to follow it stricly. Oh well.
One of the way I always do when using/defining an API is to have a way to test these things but less formally. The atlas
CLI (Command-Line Interface) is such a way. In fact, the first goal of projects like this one is to have a nice CLI tool. That way, I was able to experiment and play with nice Go modules such as cli and TOML.
Everything is available on my github.com
account here. As it is a publicly available Go program, the documentation is automatically generated on Godoc. As you can see, it is far from complete. I need to add many comments to structures and function calls throughout the program.
Most of the development is done on the develop
branch as I’m trying to use the Git flow workflow to manage development and release management.
As usual, all comments, issues and pull request are welcome, enjoy!
You may remember these articles I posted a while ago in the “howtos” category on my website. I had two of them on my ZFS-on-root setup, one on FreeBSD 8.2 for a local machine and one for a remotely managed server on FreeBSD 9.2.
The most important one was the latter as I moved all my services on dedicated servers hosted in datacentres (all managed by Online1).
My most heavily used machine at Online is getting old now by today’s standards and, to stay within the scope of the aforementioned articles, lacking the cryptographic hardware extensions in its CPU (an Intel Xeon L3426 — as you can see, old :)).
While I was just running my web & mail site out of it, I do not really need blazing fast disks (or I’d have taken SSD) but still, now that I’m sharing stuff with the Transmission P2P client and building my own set of FreeBSD packages for the host and its jails with Poudriere, the bandwidth limitation is taking its toll (35 MB/s without the AES-NI instructions vs 150 MB/s).
I may also running out of disks space (ahem), the disks are 90% filled…
There is also this slightly (read: enormously) annoying thing with both HP and Dell machines, their remote management systems (known as BMC), respectively iLO and iDRAC, just sucks. These thingy require either a .Net machine (read: Windows) or a Java applet to be run to be able to access the remote console. The keyboard when running the java applets is completely fscked up (not to mention heavily biaised toward QWERTY ones). I just hate them.
So, after looking for some time for a replacement machine at Online (and even on other providers such as Hetzner in Germany) and experimenting with another one here (a 2013 dedibox on an HP DL120G7 machine), I finally took another machine at Online, the new 2017 ST8.
It is a Dell R210 machine (iDRAC is slightly less cumbersome than iLO from HP) and while it is still using an oldish Xeon processor (the E3-1220V2), it is way better than the L3426 and it has the AES-NI instruction set. The nice thing is also that after two-three years of reducing the hard disks from 2 TB to 1 TB to cut costs, they got to put 2 4 TB disks which means two times as much disk space \o/
Considering the issues I had with the previous machines and the BMC, and following some discussions with a Linux (now FreeBSD) friend, I decided to find a setup where I do not rely on the BMC for the most simple task of all: rebooting! With my previous setups , I had to log on the BMC, run the virtual machine then I could have access to the early boot stages when the GELI passphrase is supposed to unlock the encrypted pool duing boot.
If you add the keybaord mapping issues I also mentioned you can see why such a setup is not only necessary but also better on my nerves :) In the last days of “oldnext”, the HP machine that was supposed to replace the main one, I was not able to connect to the iLO system at all. Very frustrating.
You may recall that I started using mfsbsd to bootstrap the installation of the remote system as FreeBSD was not a usable option for the “Rescue System” (it is now). I started to think that mfsbsd would be a good system to boot the entire system on, enabling me to ssh into the machine to unlock the encrypted pool, thus removing the need to use the BMC.
During these years, two things happened, one is the availability of FreeBSD as an installaton (alas just with UFS) & rescue system at Online and the second is an interesting addition to the reboot(8)
utility: the -r
flag. This flag allows the system to do everything regular reboot does except rebooting it the kernel itself. That way, you can change the root-to-be filesystem, shutdown all processes and restart with the new root.
I can now install a system with mfsbsd, boot from there, unlock the encrypted pool and “reboot” into it \o/
Only constraint is to keep the mfsbsd partition in sync with any kernel change (including modules) as you are still running that mfsbsd kernel but you will load modules from the encrypted pool.
There are some pieces missing (like the script that will do the reboot -r
thing) but the tutorial is online as a Work-In-Progress there.
As usual, all comments and corrections are welcome.
You may have noticed there is this slightly bigger and and even more well-known French hosting provider called OVH. They seem to have weird technical design choices (like watercooling), an even more weird network setup (can you say fscked up IPv6?) and some “interesting” notions on spam filtering I happen to disagree with. In short, I do not trust them for my stuff. ↩
fork(2)
fails. New header file to have better declarations like for die()
, courtesy of Bertrand Petit.
It is available on my Bitbucket and Gibhub repositories. There is a fingerprints
file signed with my GPG key. Please, check the signature before using the files. BTW, the GPG key is here
It is now-ish in the FreeBSD ports tree.
]]>Well, if I thought (cf. the previous article) that 2015 was bad for reading, well, 2016 clearly beat 2015 by a long shot :(
I planned reading a bit more than 2015 (goal was 48) and I managed… 30. A freaking disaster. I was mostly unable to read during the first half of 2016, too many issues at work and in my personal life.
See for yourself: the 2016 challenge
Anyway on to the books :)
There we find series I started before 2016, like the “The Final Formula” or “The Secret Histories”.
I managed to read a few books in French, by French authors:
2017 started much better than 2016 and although I have reduced my goal, I’m still on track. Buying a dedicated ebook reader was definitely the thing to do and am very happy with my Pocketbook Lux 3 (yeah I have changed my mind :)).
The last day of BSDCan is always special: all talks start at 10AM instead of the usual 9AM to account for the preceding night, generally filled with beer and food for some reasons :) It is also when the famous auction is taking place. During the closing session, Dan will auction a few items and the money given to the Ottawa Mission charity. He does that also with PGcon, the equivalent of BSDCan for Postgresql.
But for now, the talks!
I started with an interesting talk about a different way to test a given software package (in that case, the FreeBSD kernel): instead of testing for what we know works, we will try to make the kernel crash by doing the unexpected. When that is achieved, we try to insolate the reason and thus find the bug.
Then, one of most interesting talk for me today. Rod Grimes is one of founders of the FreeBSD project, after creating the famous 386BSD Patchkit with Jordan Hubbard, Terry Lambert and Nate Williams. David Greenman coined the name “FreeBSD” and they started it. Rod Grimes gave us the history of these early days and I’m a sucker for this kind of talk :)
The thing is, I was there like many 386BSD users both on the mailing-lists and the Usenet newsgroups and it was nice to hear this from himself. The talk was so popular it had to be moved into the larger room to fill everyone (despite the excellent talks at the same time, sorry guys!) :)
After lunch, I attended the talk from Bernard Spil about the state of OpenSSL/LibreSSL, the latter being a fork of OpenSSL by the OpenBSD guys. Miod Viallat, Bob Beck and others started a very large and much needed cleanup of the ancient codebase. Who needs VAX code now? Or code for some never-released big-endian i386 (yes, the code for this did exist).
Bernard is working on upgrading the OpenSSL in HardenedBSD and FreeBSD to LibreSSL.
The next talk was by Saen Chittenden who has been working on facilitating build managements for creating images with tools such as Vagrant and Packer, pushing them to some cloud like Digital Ocean or AWS and using tools like Puppet or Ansible to manage them.
The idea of reproducible builds has been floating around for some time now and other OSS projects like Debian Linux have started to implement them. Ed Maste talked about the status of reproducible build in FreeBSD, both on the base and ports sides.
Every BSDCan (at least from 2005 which was the first one I attended) had had the auction and it is always a fun moment at the end of the conference. This year, the fine folks at iXsystems donated a 8-drive FreeNAS-based TrueNAS system! One of the items this year was a towel made by the RIPE NCC for Towel Day :)
George Neville-Neil also had a special item to auction: one of the rare FreeBSD Foundation shirt while he was wearing it which leads up to… him taking the shirt off in front of everybody :) The pictures are on my site (see below) and I got some success with my tweet about it 1
The FreeBSD Foundation then gave gifts to four people that have done great things to FreeBSD: there was Rod Grimes of course with Warren Block (for his work on documentation), Brian Dewery (for his work on build management) and Gleb Smirnoff (security stuff).
Our dear friend Groff got in the care of Gavin Atkinson (who will bring him to the next devsummit in Cambridge: BSDCam) after being brought to Canada from Japan by OpenBSD dev Henning Brauer.
And do not forget the next conference in line, EuroBSDCon 2016 in Belgrade, Serbia!
Thanks to Dan and everyone working to make BSDCan such a success!
Did I ever entioned I take pictures at every BSD conference I go? :) Go to the usual place to see them :)
So long BSDCan and thanks for all the fish!
Dan officially opened the conference as usual, under supervision by Groff of course, now a regular attendee of all conferences :)
We seem to have a lot of newcomers this year as illustrated by all the people raising their hands.
There was some hardware donations during this opening session, with Shawn Webb giving away RPi3 to several people like the newest committer in any BSD, the oldest one and so on. TL; DR: Kirk & Rod won one :)
Like last year, BSDCan is having an additional track which means 33% more talks \o/
Of course I can’t go to every talk to as usual, I had to choose.
Started with a talk about what is VXLAN, a way to create lots of VLAN-like kind of network over UDP/multicast. It was created by VMWare and has been implemented in all the major OS like FreeBSD, OpenBSD and Linux (in addition of ESX and cisco).
Next was the Capsicum/Casper talk on what was Capsicum at the beginning and how casper was born, first as a daemon ad next as a library. Interesting comparisons with pledge(2)
was well.
During the lunch break, we had a nice OpenZFS BoF with both Matthew Ahrens and AllanJude, the former being one of the original authors of ZFS back at Sun.
It is exciting to see who ZFS has kept on growing since the fork from Oracle, we will finally have encryption support in OpenZFS \o/
The next talk was about fighting the current streak of Monoculture happening in Tor where most of the nodes (relays and exit ones) are mostly Linux boxes; like in any monoculture, flaws and weaknesses spread faster. Some of the figures are really bad :(
Then I had this talk about how PAM became the nightmare it is right from the beginning at Sun to OpenPAM and the other stuff. Groff was there as well to supervise Michael Lucas’ talk :)
The end of the day was another talk by Matthew Ahrens about some performances (up to like 2x faster!) improvements for writes in OpenZFS. This will be upstreamed soon and be in OpenZFS next year or so.
End of day one, pictures as usual there
]]>This is a followup on yesterday’s post
It has become some kind of a tradition during the BSDCan’s devsummit to more or less give ourselves a set of goals for the next major release. But before, as 11.0 is really around the corner, we did a list of what is in 11.0.
The list is always more impressive than many think at first. Have a look at the different pictures I got in the slides section; the first two are what we had in mind before really thinking about it, the next two or three are the really long list :)
Next, what we need / want for 12. The main items being trying to get 12.0 GPL-free and have a proper replacement for the rc.d
stuff which is showing its age now (whoever thought systemd
can remove him- or herself out of here, thanks).
You can see the list of interesting things people want, including better external toolchain support and a few things about ZFS like compressed ARC and encryption.
You can find a more readable version here.
Then we has a short presentation by Deb and Justin about the FreeBSD Foundation
That was following bu a Q&A session with the core team members present:
After lunch was the traditional developers’ photo by David Maxwell (and yours truly, see above). I’m in the final one do not worry ;-)
The afternoon for me was more into general hacking & mail. I began to have a second look at Poul-Henning’s ntimed daemon (I hope to replace the ancient and frankly increasingly unsecure ntpd with it as soon as it gets more complete) and ended up writing a manpage for it :) (GH pull request).
This day ended gloriously with Poutine :)
While going back to the hackers’ lounge in L140, I tried to get some pictures of the massive sinkhole that appeared very near the Rideau centre Mall yesterday. This part around the centre has been closed to the public of course — by sheer luck no one was hurt which is almost unbelievable considering the amount of car and bus traffic going there…
and I tumbed upon that sign on a well-known pub near ByMarket :)
Like the last few years, I’ve taken a few pictures :) Be sure to visit every day for updates!
]]>As usual, we will have two days of both tutorials and FreeBSD devsummit, a regular event in almost all BSD-related conferences now.
Like last year, BSDCan kind of unofficially starts with the Goat BoF, the day before the devsummit & tutorials start. Groff was a bit late this year so I have less pictures :)
While waiting for Groff to arrive, I noticed his little brother watching over us :)
After a few rounds of beer and food (which was greatly needed on my part), Henning was there carrying Groff with him \o/
Pictures for yesterday’s session are there.
The agenda for today (and tomorrow) is available here.
You can find most of the slides of today’s presentations (and tomorrow’s soon) here. I think it makes looking at the picture easier, don’t you think?
It seems that Hell has frozen over here in Canada because not only we had a very interesting presentation by Microsoft about FreeBSD support in their Cloud offering called Azure but they also sponsored the devsummit!
To summarize: not only FreeBSD has been supported by Microsoft on Azure in 2014 (with support for Hyper-V and stuff) but they now have it available on the Azure Marketplace, meaning they have engineers to do the support, just like any other supported OS. While there are many things that could be said about them (just witness the PR disaster that is W10), they are not the same company as before. We’ll see how it goes.
Next presentation was from Intel about their QuickAssist Driver (and its port to FreeBSD). QuickAssist is a driver made for high-speed hardware support for cryptography & compression. It is already supported on Linux and they want to make it on par feature-wise on FreeBSD.
Then lunch \o/
The afternoon is divided into working groups as per the schedule, I stayed in DMS1160 for the Toolchain session.
Lots of things going on there as you can see on this agenda:
We are still struggling with the remains of our ancient toolchain based on GPLv2 tools and we use more and more the external ports-based toolchain, especially for architectures not using Clang. Sparc is still an issue and we are not decided whether to keep the support for in inside the tree or not. Progress has been made on both lld
and LLDB
.
The day ended with the devsummit dinner with Pizza, softs and beer in the hacking lounge back at the residence (sponsored by Intel this time).
Like the last few years, I’ve taken a few pictures :) Be sure to visit every day for updates!
]]>