iTunes et l’App Store ne distribuent pas leurs contenus en HTTPS

Mickaël Bazoge |

Apple, qui est si attachée à la confidentialité des données, s’en tient toujours au bon vieux (et pas très sécurisé) HTTP pour distribuer ses contenus sur l’App Store et l’iTunes Store. Musique, films, applications, mises à jour… Tout cela arrive chez l’utilisateur sans la couche de transport sécurisé (TLS, Transport Layer Security) qui est le propre du HTTPS. Et que l’on repère au petit cadenas à côté de l’URL d’un site web.

Tous les portails web ne présentent cependant pas cet indicateur graphique. C’est le cas d’iTunes et de l’App Store, et c’est ce qui a poussé les chercheurs de Disconnect à fouiner un peu dans l’architecture des services d’Apple. C’est là qu’ils ont découvert l’absence de certificat TLS.

En théorie, cette pratique facilite la vie des malandrins qui voudraient en savoir plus sur un utilisateur : avoir connaissance des applications qu’un individu télécharge, c’est déjà en savoir beaucoup sur la personne. De plus, chacun de ces téléchargements non chiffrés intègre un code Apple, le Destination Signaling Identifier (DSI), un numéro unique lié à l’appareil généré par iCloud, et qui change régulièrement.

Que se passerait-il si un pirate exploitait ce code DSI pour traquer un utilisateur à son insu ? En septembre, Discover déposait un bug report auprès d’Apple, qui a répondu que la situation n’avait rien d’un bug, au contraire : ces téléchargements via HTTP sont le comportement normal. Si les envois de données ne sont pas chiffrés, les interactions pour initier et compléter un téléchargement sont, elles, sécurisées. En particulier les métadonnées de transfert avant le téléchargement du contenu à proprement parler.

La validité et l’intégrité des fichiers téléchargés sont protégées par un processus de confirmation cryptographique, précise aussi le constructeur. Apple n’explique cependant pas pourquoi le téléchargement dans son ensemble ne se déroule pas via HTTPS. Wired, qui rapporte l’histoire, rappelle que depuis 2016, Apple demande aux développeurs d’utiliser TLS dans leurs applications ; de fait, le trafic internet à l’intérieur des apps est chiffré.

En l’absence d’explications sur l’usage du simple HTTP pour le téléchargement des données provenant des boutiques d’Apple, on en est réduit aux conjectures. Will Strafach, le chercheur bien connu, avance une hypothèse : cela fournit aux administrateurs système, en particulier dans les grandes entreprises, une manière de stocker en cache les grosses applications et les fichiers afférents sur leurs réseaux locaux. La distribution des apps en est donc facilitée.

Si le téléchargement était chiffré de bout en bout, cette halte ne pourrait pas exister. « Cela n’a pas l’air aux normes et plutôt étrange à première vue », convient Strafach, « mais je ne pense pas que cela représente une menace sur la sécurité, puisque des vérifications d’intégrité sont toujours en place ». Il indique aussi qu’un brigand peut toujours tenter de deviner les applications téléchargées d’un utilisateur en fonction du poids de l’app, même si le processus est complètement protégé par un certificat TLS.

En ce qui concerne le Play Store, Google a mis en place une procédure de téléchargement qui transite entièrement par HTTPS. Cela ne signifie pas que les applications Android n’aient aucun problème de sécurité bien sûr, mais de ce côté Google s’est assuré que tout était bien bordé.

avatar marc_os | 

Moi ce qui m'étonne c'est que les téléchargements de fichiers complets ne soient pas faits en ftp, à priori bien plus efficace car dédié au "transfert de fichiers", d'ailleurs c'est dans son nom ! (PS: Je ne parle pas du streaming).

avatar Kazquo | 

@marc_os

Le FTP n’augmenterai pas le débit plus que ça. Pire, il faudrait le faire sur des ports « neutres » pour éviter le filtrage et les limitations de débit de certains FAI.
Enfin, le FTP est juste une plaie derrière du NAT.
HTTP et HTTPS, ça passe partout.

avatar Nicnl | 

Non, ça ne change absolument rien

Quand tu télécharges un fichier en HTTP ou en FTP, tout ce qui change c'est la façon dont le fichier est demandé au tout début de la transaction

Mais le transfert lui même se fait de la même façon : en envoyant les données brutes du fichier à travers la connexion TCP
Du coup, il y a techniquement/réellement/mathématiquement zéro différence de débit entre de l'HTTP et du FTP

Je précise que je parle bien de l'HTTP vs le FTP, hein.)
L'HTTPS, c'est autre chose; Un poil plus lent étant donné qu'il faut encrypter le flux de données côté serveur pour le décrypter côté client, ce qui bouffe en puissance de calcul...

avatar fte | 

@Nicnl

"L'HTTPS, c'est autre chose; Un poil plus lent étant donné qu'il faut encrypter le flux de données côté serveur pour le décrypter côté client, ce qui bouffe en puissance de calcul..."

Il y a une courte latence ajoutée et effectivement une charge de calcul, mais toutes les puces récentes ont des instructions pour accélérer ces opérations et la vitesse du câble reste le facteur limitant la vitesse, pas la rapidité de chiffrement.

avatar occam | 

@marc_os

Quand SSH est disponible, il serait bien plus logique d’utiliser SFTP que le FTP non sécurisé, ou la poudre à gratter qu’est FTPS, surtout quand il s’agit de lui faire traverser des firewalls.

Mais rendons hommage à Apple : avec Sierra, ils ont réussi à casser l’intégration de SSH dans macOS, et le remède a réussi l’exploit d’être presque pire que le mal.
Et ça, sur un Unix moderne, il faut parvenir à le faire.

avatar Nesus | 

C’est un peu du pinaillage. La méthode d’Apple assure la sécurité. Pas celle que tout le monde attend, mais toute aussi efficace.

avatar en ballade | 

@Nesus

"assure la sécurité"

Source, chiffres? Ou juste fantasme du Fan?

avatar fte | 

@Nesus

En effet, c'est ce qu'il semble. Cependant les développeurs tiers n'ont pas cette même liberté de protocoles sécurisés bien que non chiffrés. Faites ce que je dis, pas ce que je fais, je sais mieux que vous vous savez. Ça, ça me dérange.

avatar Nicnl | 

N'oubliez pas un deuxième truc important

L'HTTPS est très strict, et requiert OBLIGATOIREMENT que le serveur fournisse les bons certificats

En utilisant de l'HTTP avec des fichiers signés, ça permet aux entreprises et autres grosses structures de mettre en place des systèmes de caches

(Des serveurs intermédiaires qui gardent en mémoire les contenus téléchargés pour pouvoir les redonner instantanément aux autres sans devoir les retélécharger)

Vous seriez surpris, mais du coup beaucoup d'autres logiciels utilisent l'HTTP de cette manière pour cette raison en particulier
Typiquement Steam
Ça permet aux organisateurs de LAN Party de mettre des systèmes de mise en cache de jeux, et ça permet aux joueurs de "télécharger" (choper depuis le cache) leurs jeu avec steam à 100 Mo/s

Tout ça n'est pas possible avec l'HTTPS

avatar gimly54 | 

En soit, je ne voit pas le problème, les transactions se font en HTTPS avec une vérification complète du contenu. Seul le téléchargement du fichier se fait en HTTP afin d’offrir des fonctions supplémentaires. Rien de bien inquiétant.
Après ces news vont avoir l’intérêt d’attirer l’œil sur cette pratique et de faire un bon test de sécurité.

avatar Ali Ibn Bachir Le Gros | 

Si les envois de données ne sont pas chiffrés, les interactions pour initier et compléter un téléchargement (...)

Compléter un téléchargement avec quoi ? Il manque quelque chose au téléchargement pour qu'on ait besoin de le compléter ?

A moins que vous vouliez écrire terminer un téléchargement.

avatar Lightman | 

@Ali Ibn Bachir Le Gros

Je me suis fait la même remarque.

CONNEXION UTILISATEUR