Il y a trois ans, Skype était tombé pendant un peu plus de deux jours pour une raison restée assez floue à l'époque. L'éditeur ne s'était en effet pas senti obligé de communiquer plus que ça sur la question, en dehors d'une maladroite mise en cause du Patch Tuesday d'août 2007 qui avait fait couler son lot d'octets sur la blogosphère. L'hypothèse la plus crédible alors évoquée pointait une défaillance des serveurs d'authentification, seul service centralisé de l'infrastructure.

Dans le cas présent, c'est la structure distribuée qui aura failli. L'accès au réseau Skype se fait en effet par le truchement de clients élevés au rang de supernodes. Ces clients, parce qu'ils bénéficient d'une connectivité favorable[1], sont promus à ce statut privilégié pour servir d'intermédiaires dans la mise en liaison des autres clients, comme ceux disposant de connexions restreintes[2]. Si leur intérêt est évident pour le routage des flux de communication, ils servent également de points d'entrée dans le nuage lors de la séquence de boot d'un client.

Pour faire court : pas de supernode, pas de réseau. Pas de réseau, pas de d'authentification. Pas d'authentification, pas de Skype. C'est ce qu'il fallait lire derrière l'erreur cryptique renvoyée par les clients incapables de s'authentifier "Connexion P2P impossible"[3].

Il est intéressant de constater qu'une fonction aussi critique du réseau, mais en même temps autant distribuée justement pour contre-balancer le risque de faute généralisée, ait pu faillir avec des conséquences aussi fâcheuses. La faute en revient probablement à l'importante uniformité de version des clients. Les mises à jour automatiques, c'est très bien pour garder un parc à jour. Mais c'est également très efficace pour le flinguer quand un bug majeur se glisse au milieu de tout ça. Ce qui vient manifestement de se passer avec les supernodes...

On notera également que Skype a retenu la leçon de sa quasi-absence de communication sur le blackout de 2007. Silence qui a laissé la place aux théories les plus folles. Pas moins de cinq billets ont été publiés pour informer les utilisateurs des causes de la panne et de l'évolution de la situation, dont deux vidéos du CEO Tony Bates. Sans parler des nombreux tweets qui les ont accompagnés. Communication qui se révèle fort intéressante pour se faire une idée de l'ampleur de la panne et du rythme auquel s'est fait le retour à la normale.


Comme je le disais en introduction, rares sont encore ceux qui ont osé ne serait-ce qu'émettre l'hypothèse d'une attaque. Ce qui est surprenant à deux titres. D'abord parce qu'il est dans l'air du temps d'attribuer le moindre problème à une cyber-attaque... Comme on dit aujourd'hui... Sauf qu'ici, la communication débridée de Skype a un peu coupé l'herbe sous les pieds de tous les grands penseurs de la cyber-guerre généralisée. Il faut dire que s'il y a bien quelqu'un que ça n'intéresse pas qu'on puisse y voir une atteinte à l'intégrité du service, c'est bien Skype ! Ce qui fait d'ailleurs de cet évènement un bel exemple de l'efficacité de la transparence pour la communication de crise en ligne...

Ensuite, parce que cette éventualité est bien loin d'être impossible. Comme l'ont démontré en leur temp Kostya, Philippe et Fabrice avec une série de présentations que je vous encourage à lire, ou tout du moins parcourir. La gestion des supernodes par le réseau Skype est en effet basée sur un certain nombre de messages de contrôle. Et si certains sont là pour les mettre en place et les promouvoir, d'autres sont également là pour les ramener au statut de simple nœud. Vous voyez immédiatement où je veux en venir...

Quand bien même je ne pense pas qu'il s'agisse d'une attaque, je trouve cependant amusant qu'en cette période souvent qualifiée de cyber-mondialement-instable, on préfère voir des actes de cyber-guerre là où absolument rien n'indique que ce soit le cas, quand ce n'est pas le contraire, et qu'on laisse filer d'aussi belles opportunités de se faire mousser[4]...

Notes

[1] IP publique, pas de firewalling externe, bonne bande passante, entre autres.

[2] Derrière une passerelle NAT typiquement.

[3] "P2P connect failed" en langue originale.

[4] Vous ne manquerez pas, j'en suis sûr, de noter toute l'ironie de cette conclusion...