Mise à jour : Orange n'aime pas trop ça. Allez savoir.

Il y a SIP, et SIP par Orange.

En effet, l'opérateur historique a décidé de migrer une partie de ses clients ADSL et Fibre vers le protocole SIP pour la signalisation téléphonique de la téléphonie par Internet de la Livebox.

Orange propose ainsi trois manières d'exploiter la téléphonie par IP incluse dans ses connexions Internet :

• on peut tout simplement brancher un bon vieux téléphone analogique (ou une interface FXO) en insérant la prise RJ11 à l'arrière de la Livebox ;
• on peut aussi connecter directement des téléphones DECT compatibles à la box ;
• enfin, et potentiellement le plus intéressant : on peut aussi utiliser l'application Livephone pour utiliser son PC comme un "softphone" qui a l'avantage de sonner lorsqu'un appelant externe compose le numéro fixe associé à la Livebox.

Cette application, uniquement disponible sous Windows malheureusement, n'est pas compatible avec toutes les connexions, et je conjecture qu'elle ne fonctionne qu'avec les abonnés utilisant la signalisation SIP pour le téléphone. Ce qui signifie qu'il serait théoriquement possible d'utiliser n'importe quel softphone avec ce service. Pour moi, cela me permettrait de m'affranchir du câble RJ11 entre mon serveur et la box, et de bénéficier d'une méthode plus élégante pour détecter le début et la fin d'un appel téléphonique.

Hélas, il n'en est rien ! Une analyse plus détaillée révèle en effet que le Livephone implémente une version modifiée du mécanisme d'authentification SIP, que je n'ai pu relever qu'après un long travail d'ingénierie inverse (légale, dans ce cas particulier). Ces modifications violent bien entendu la RFC 3261, cassant de fait la compatibilité avec les clients SIP autres que le Livephone.

Constatant que des demandes d'informations antérieures ont été infructueuses, j'ai donc été contraint de me lancer dans une analyse technique plus poussée. Les informations que je publie ici sont principalement des résultats d'analyses de trames réseau et de traces de débogueur ; néanmoins, j'ai également été amené à décompiler le programme pour comprendre entièrement le mécanisme d'authentification.

C'est dans une démarche d'interopérabilité que j'exposerai dans les grandes lignes le fonctionnement de l'authentification SIP par Orange. Nous constaterons très rapidement pourquoi un téléphone SIP conforme à la RFC ne pourra jamais utiliser en l'état le réseau SIP Orange, puis j'expliquerai dans une dernière partie une solution possible pour contourner ces modifications propriétaires.

Certains paragraphes seront délibérément vagues ou peu détaillés, par manque de recherches, ou afin d'éviter les ennuis (comme ceux que j'aurais pu avoir avec la SNCF il y a quelques temps et qui m'ont conduit à censurer des morceaux d'article).

Le SIP par Orange en trois étapes

Le schéma ci-dessous résume le processus d'authentification du Livephone auprès du proxy SIP Orange.

On voit déjà immédiatement que le processus est beaucoup plus compliqué qu'une simple requête REGISTER auprès du proxy. Reprenons chacune des trois étapes en plus de détails.

Login

Tout d'abord, le client envoie en HTTPS (mais sans vérifier le certificat, ce qui est bien pratique pour faire du sslstrip comme un gros dégueulasse) une requête au serveur d'authentification. On dirait que celui-ci reconnaît l'utilisateur en se basant sur l'IP source (du moins, je crois), mais substituer ses propres serveurs DNS à ceux d'Orange permet de "forcer" un downgrade vers une authentification par login et mot de passe. Il semblerait que la toute première authentification se fait toujours par login et mot de passe.

Récupération de la configuration

Si l'authentification passe, le client reçoit entre autres un token qui est une chaîne hexadécimale tellement longue qu'il faut trois segments TCP pour la transmettre. Il envoie ce token (concaténé à d'autres variables, comme le nom et les versions de l'OS et du client) à un serveur de paramètres par HTTPS lui aussi, cette fois pour récupérer une liste de paramètres SIP : nom du proxy SIP, URI SIP de l'utilisateur (de la forme +33123456789@orange-multimedia.fr) entre autres, mais aussi une étrange chaîne de caractères en base64 appelée AuthentData.

Enregistrement auprès du proxy SIP

Enfin, la troisième étape consiste à faire l'enregistrement du client auprès du proxy SIP. Cela se fait avec un message REGISTER, comme le décrit la RFC 3261. Comme on peut le voir, l'authentification se déroule par challenge-response, de la même manière que l'authentification HTTP Digest, décrite dans la RFC 2617.

En réalité, le calcul de la réponse au challenge est un peu compliquée. La seule différence est que le paramètre H(A1) n'est pas égal à md5("${username}:${realm}:${password}"). Il faut en effet (censuré).

En conclusion, j'ignore si cela a été fait sciemment ou par flemme, mais le résultat ressemble presque à un échange conforme à la RFC 2617, alors qu'il n'en est rien en réalité.

Récapitulatif

En résumé, on dégage les informations suivantes :

• l'authentification se fait en trois étapes auprès de trois serveurs différents, au lieu du seul proxy SIP ;

• un des paramètres pour le calcul de la réponse au challenge envoyé par le proxy SIP ne correspond pas à ce qui est prescrit par la RFC. Au lieu de ça, il s'agit d'un bloc binaire, récupéré depuis une source extérieure, et chiffré avec un algorithme dont je suis à peu près sûr que (censuré).

• de fait, il est impossible de se passer des deux premières étapes de l'authentification car celles-ci permettent d'obtenir des informations essentielles à l'authentification SIP.

Se défaire des extensions propriétaires

Se pose maintenant la vraie question : quelle est la solution la plus simple pour assurer l'interopérabilité entre l'infrastructure SIP Livephone d'une part, dont on a vu qu'elle ne respecte pas les RFC, et l'ensemble des clients SIP d'autre part ?

Une première possibilité aurait été de mettre au point des patchs pour Asterisk, car c'était dans l'optique de faire fonctionner le Livephone avec ce serveur de téléphonie que je m'étais lancé dans ce travail.

Cependant, j'ai préféré privilégier la solution d'un proxy SIP, qui serait alors utilisable directement avec n'importe quel client SIP, y compris Asterisk, et éviterait à ceux qui souhaiteraient tenter la même chose d'être obligé d'installer Asterisk chez eux, et d'avoir juste besoin de ce proxy et d'Ekiga ou de Linphone.

Le proxy ne ferait que du bête forwarding de requêtes et de réponses entre les deux parties, sauf dans le cas du REGISTER qu'il intercepterait pour faire l'authentification « à la sauce Orange » à la place, tout en répondant "OK" au client si tout s'est bien passé.

Le seul problème restant est la dernière étape d'authentification. Cet aspect risque de rendre l'interopérabilité bien plus difficile à obtenir que ce que j'aurais espéré. La réalisation d'un proxy en devient à la limite de la légalité, car à part décompiler l'algo de hachage pour l'analyser plus en détail et voir avec quels paramètres il est appelé, je vois mal comment faire autrement.

Conclusion

Ces recherches sont incomplètes, dans la mesure où je n'ai pu valider mes analyses que partiellement à l'aide de preuves de concept incomplètes.

Bien que je puisse comprendre qu'Orange ait pu décider de fournir une méthode centralisée de distribution d'éléments de configuration (après tout, j'imagine qu'ils font la même chose pour la Livebox elle-même de toute façon), une modification aussi lourde au processus d'authentification SIP proprement dit (c'est-à-dire le challenge-response) a tout d'une action délibérée. Modification difficilement justifiable d'un point de vue technique, qui plus est.

Comme je le disais au-dessus, la prochaine étape consistera bien évidemment à concevoir et implémenter un proxy SIP faisant le lien entre un client SIP lambda, et l'infrastructure SIP propriétaire du Livephone. Ce proxy ne fonctionnera que sur la connexion Internet Orange de l'utilisateur, entre autres parce que beaucoup de noms de serveurs que j'ai pu voir passer dans tcpdump ne sont résolvables que par le biais des serveurs DNS Orange (rappelez-vous du serveur SMTP d'Orange, par exemple). Tous mes essais sont concluants jusqu'à maintenant, et si je parviens à implémenter un proxy qui fonctionne, le résultat fera bien entendu l'objet d'une autre publication sur ce site.

Étant donné que ces modifications protocolaires sont manifestement intentionnelles dans le but de casser la compatibilité avec les matériels et logiciels respectant les normes, cet effort de reverse engineering en est d'autant plus légitimisé.

Mise à jour du 4 mai : correction de quelques inexactitudes, notamment liés à l'authentification.

Mise à jour du 28 mai : faire un plugin pour siproxd : ça, c'est fait.