Comment contourner Firefox pour résoudre l’absence de prise en charge de WebUSB

 (github.com/ArcaneNibble)
1 points par GN⁺ 2025-03-15 | 1 commentaires | Partager sur WhatsApp
  • Ce proof-of-concept montre qu’une page web peut communiquer avec un périphérique USB même sans WebUSB, en faisant agir un Raspberry Pi Pico comme une clé de sécurité U2F afin d’exploiter la prise en charge existante des clés de sécurité par le navigateur
  • Le Pico n’assure aucune fonction de sécurité réelle et cache des données arbitraires dans le key handle du message U2F_AUTHENTICATE ainsi que dans la zone de signature ECDSA, ce qui permet de piloter la LED et de lire l’état de la broche GP22
  • Le key handle U2F est conçu comme un blob de données opaque appartenant au dongle de sécurité, et cette fonction, prévue pour permettre à des dongles bon marché de gérer des inscriptions sur plusieurs sites avec une mémoire limitée, est détournée pour y dissimuler des données
  • Cette méthode n’est pas une faille donnant accès à un périphérique USB arbitraire ; elle ne fonctionne qu’avec des appareils qui enfreignent délibérément les règles, mais le problème du modèle de sécurité USB demeure, puisqu’un périphérique USB malveillant peut toujours se faire passer pour un clavier ou une souris
  • Au-delà de la prise en charge ou non de WebUSB dans Firefox, la question s’élargit à la manière de construire une plateforme informatique saine et un écosystème que développeurs et utilisateurs peuvent réellement comprendre et maîtriser

Démonstration d’accès à un périphérique USB sans WebUSB

  • Il s’agit d’un proof-of-concept montrant comment une page web peut communiquer avec un périphérique USB sans passer par les débats politiques autour de WebUSB ni par des demandes de consentement utilisateur
  • La démo rapide consiste à flasher u2f-hax.uf2 sur la version RP2040 du Raspberry Pi Pico, puis à ouvrir index.html en localhost ou dans un autre secure context
  • Les boutons On! et Off! de la page basculent la LED du Pico
  • L’état de la broche GP22 est mis à jour périodiquement sur la page, et peut être testé en la court-circuitant avec le pad GND adjacent à l’aide d’un fil ou d’un morceau de métal

Fonctionnement : se faire passer pour une clé de sécurité U2F

  • Le Pico est émulé comme un dongle U2F, c’est-à-dire comme une clé de sécurité physique de double authentification
  • Au lieu d’assurer de vraies fonctions de sécurité, il dissimule des données arbitraires dans le message U2F_AUTHENTICATE
    • Les données sont placées dans le key handle et dans la zone de signature
    • Si le key handle commence par 0xfeedface, le Pico considère immédiatement que la présence de l’utilisateur a été confirmée et renvoie les données
  • Du point de vue du navigateur, il s’agit simplement d’utiliser les fonctions existantes d’interaction avec une clé de sécurité

Pourquoi le key handle U2F peut être détourné

  • Le key handle d’U2F est, en théorie, un blob de données opaque appartenant au dongle de sécurité
  • Le flux classique est le suivant
    • Le dongle renvoie un key handle lors de l’enregistrement
    • La relying party le stocke tel quel
    • Lors de l’authentification, elle renvoie cette même valeur au dongle de sécurité
  • Cette fonction est liée à une conception permettant à des dongles bon marché à mémoire limitée de gérer de nombreuses inscriptions sur différents sites
    • Le dongle stocke en interne une clé de chiffrement master unique
    • Lors d’un nouvel enregistrement, il génère une paire de clés publique/privée et renvoie la clé publique
    • Il renvoie comme key handle la clé privée chiffrée avec la clé master
    • Lors de l’authentification, il déchiffre le key handle reçu avec la clé master afin d’utiliser la clé privée
  • Pour ne pas imposer d’algorithme interne particulier, le key handle est traité comme opaque, et c’est précisément cette propriété qui est exploitée pour dissimuler des données arbitraires

Les données renvoyées sont emballées comme une signature ECDSA

  • Pour renvoyer des données, des données arbitraires sont dissimulées sous la forme d’une signature ECDSA
  • Une signature ECDSA est un tuple de deux nombres (r, s), chacun calculé par rapport à n, l’ordre du point de base de la courbe elliptique
  • Les nombres qui entrent dans l’intervalle de l’ordre du point de base de secp256r1 sont emballés en ASN.1
  • Il est parfois possible de distinguer une vraie signature ECDSA correctement calculée, mais aucun composant autre que la relying party n’a de raison forte d’aller au-delà des vérifications de validité de base
  • Le comportement diffère selon les navigateurs
    • Chrome semble vérifier que les nombres de la signature sont dans l’intervalle 0 à n
    • Firefox ne semble même pas effectuer cette vérification de plage
  • Pour passer de manière fiable la vérification minimale de Chrome, le premier octet de chaque nombre est sacrifié et fixé à 0x7f
    • Cela garantit que le nombre est toujours positif et inférieur à n
    • La pile logicielle jusqu’au JavaScript du navigateur transmet ensuite ces nombres « suffisamment valides » tels quels

Faille de sécurité ou modèle de sécurité USB ?

  • Cette technique n’est pas une faille permettant d’accéder à n’importe quel périphérique USB
  • Elle ne fonctionne qu’avec des appareils qui enfreignent volontairement les règles et constitue donc, au fond, un périphérique délibérément rendu vulnérable
  • En revanche, sur la plupart des plateformes, le modèle de sécurité autour des périphériques USB reste globalement discutable
  • Si l’on branche un périphérique USB malveillant, il peut agir via des interfaces comme un clavier ou une souris pour effectuer ce qu’un utilisateur pourrait faire
  • Il ne faut pas connecter à un ordinateur, un téléphone ou tout autre appareil des périphériques inconnus et non fiables

Une remise en question des plateformes et de l’écosystème

  • L’objectif du proof-of-concept ne se limite pas à un simple « parce qu’on peut le faire » personnel, mais vise à mettre en lumière l’état actuel des plateformes informatiques
  • Du point de vue d’un fabricant de gadgets, on souhaite que l’utilisateur final puisse utiliser un nouveau périphérique avec le moins de friction possible
  • L’écosystème actuel des ordinateurs et des gadgets présente un décalage entre ce que les utilisateurs s’attendent intuitivement à pouvoir faire et ce qui est réellement possible
  • On s’attend à ce qu’une « clé de sécurité » ressemble à un produit bien emballé et à usage unique, alors qu’en réalité elle peut exécuter du code arbitraire, prendre n’importe quelle apparence et adopter un comportement arbitraire
  • USB Rubber Ducky et O.MG Cable sont aussi des exemples qui touchent à ce problème
  • Le caractère « Universal » de l’USB présente à la fois des avantages et des inconvénients
    • Ni les humains ni les ordinateurs ne disposent d’un bon moyen simple et fiable de distinguer si un périphérique USB agit dans l’intérêt de l’utilisateur, contre lui, ou comme conséquence d’une plus grande puissance et de comportements émergents
  • Le Web est le moyen le plus simple de distribuer des logiciels destinés à s’exécuter sur l’ordinateur de quelqu’un d’autre
  • Les développeurs ont moins besoin d’apprendre les détails de toutes les plateformes cibles, mais en contrepartie ils apprennent aussi moins les conventions et attentes propres à chacune
  • La discussion devrait aller au-delà de « pourquoi Firefox n’implémente-t-il pas WebUSB ? » ou de « va-t-il perdre encore plus de terrain face à Chrome ? » pour se déplacer vers la construction délibérée de plateformes saines à l’échelle de l’informatique dans son ensemble, des ordinateurs de bureau et portables aux tablettes, téléphones, objets connectés et maisons intelligentes

À lire aussi

1 commentaires

 
GN⁺ 2025-03-15
Avis sur Hacker News

  • Firefox ne prend pas en charge la communication avec des périphériques USB arbitraires, alors que Chrome dispose de WebUSB pour cela.
    En revanche, Firefox prend bien en charge la communication avec des clés de sécurité U2F via USB.
    Ce projet tente de faire passer un microcontrôleur pour une clé de sécurité U2F, afin de communiquer avec lui par USB depuis Firefox.
    Avec l’API JavaScript Credentials (https://developer.mozilla.org/en-US/docs/Web/API/Credential_...) et quelques astuces, il envoie des données et reçoit des réponses.

    • Ce n’est pas fait pour accéder à n’importe quel périphérique.
      Mais cela peut tout de même servir à créer des périphériques personnalisés qu’une page web peut utiliser sans invite de consentement.
    • Si j’ai bien compris, Firefox serait donc vulnérable au problème qu’il voulait éviter, tout en ne fournissant pas WebUSB ?

  • Personnaliser via WebUSB un clavier avec un firmware QMK/Via relève presque du cauchemar.
    Pour que le navigateur puisse communiquer avec le firmware, il faut en pratique rendre un périphérique /dev/hidraw lisible par tout le monde, ce qui ouvre la porte à toutes sortes de bidouilles de keylogging.
    Le mode d’utilisation est très dérangeant, et les outils de personnalisation hors ligne sont tous basés sur Electron, donc l’avantage n’est pas énorme.
    Le contournement le plus raisonnable consiste à créer la disposition de clavier souhaitée sur un site web à partir d’un modèle JSON, à télécharger le JSON obtenu, puis à flasher le firmware sur le clavier avec un outil de flash doté des droits sudo.
    Malgré tout, ce serait bien d’avoir une méthode moins dérangeante.

    • Plusieurs microcontrôleurs sont livrés avec MicroPython et un lecteur flash émulé, ce qui permet de déposer du code Python pour modifier le main() en cours d’exécution.
      Les claviers pourraient probablement faire quelque chose de similaire.
      Il suffirait que le système de fichiers signale une erreur si un JSON invalide est écrit, et que le système de fichiers émulé ait des attributs de sécurité n’autorisant l’écriture qu’aux administrateurs.
      Pas besoin de sudo : il suffirait d’approuver une invite d’autorisation au moment de télécharger ou copier la nouvelle configuration sur le lecteur flash virtuel.
    • Un clavier standard a 3 LED : Caps Lock, Num Lock, et une autre, toutes configurables côté système d’exploitation.
      Au moins Caps Lock semble pouvoir être réglé depuis JavaScript, ce qui en fait en pratique un bus de communication d’une largeur de 1 bit.
      Avec les outils ordinaires du système d’exploitation, on pourrait aller jusqu’à 3 bits.
    • Il y a un peu de confusion ici.
      Le cœur du modèle de permissions, c’est que la famille de navigateurs sert d’intermédiaire pour l’accès au matériel.
      Évidemment, pour que le navigateur puisse faire cela, il faut lui donner l’accès au matériel dès le départ.
      On peut refuser de faire confiance au navigateur comme administrateur de la couche d’abstraction matérielle, mais c’est bien le modèle attendu par Via.
      Je ne vois pas pourquoi ce serait plus « dérangeant » que de donner au navigateur l’accès à la caméra, au micro ou à la lecture du stockage.
      Même sur un Chromebook d’entreprise verrouillé, je peux aller sur https://usevia.app et modifier un clavier QMK sans problème, alors que je n’ai évidemment aucun accès aux nœuds /dev sur cette machine.
    • D’après ce que je comprends, la prise en charge de Via est une fonctionnalité du firmware du clavier qui autorise ce type de personnalisation à la volée, et c’est distinct de QMK lui-même.
      QMK repose entièrement sur le flash manuel.
      Cela dit, j’ai été surpris de voir à quel point il est facile de personnaliser par le code la disposition, les couches et l’éclairage, en grande partie grâce au soutien de la communauté.
    • Si vous cherchez une alternative côté QMK à Via, je recommande la combinaison QMK Configurator et QMK Toolbox.
      Ce n’est pas aussi pratique que Via, mais il y a tout de même un éditeur graphique de keymap, il compile le firmware, et c’est beaucoup moins lourd.
      J’ai eu une bonne expérience avec les cartes Keeb.io.

  • Ce fil de commentaires est intéressant parce qu’il mélange des personnes qui disent à quel point WebUSB est agréable à utiliser, et d’autres qui ne l’utilisent pas et ne comprennent pas pourquoi il serait nécessaire.
    Personnellement, j’ai trouvé ça excellent.
    La plupart des utilitaires WebUSB que j’utilise existent aussi sous forme d’apps à installer, mais je m’en sers si rarement que la version web est beaucoup plus simple que d’installer l’app, la mettre à jour, puis la lancer.
    Avoir une app de moins à installer est aussi un avantage.
    J’aurais pensé que ce serait populaire auprès des gens lassés de devoir installer une app pour chaque objet.

    • Le site qui fournissait cette app utile peut un jour disparaître complètement, alors qu’une app installée reste parfaitement disponible tant qu’on ne la supprime pas.
      C’est donc une arme à double tranchant.
    • Ce qui m’inquiète davantage, ce sont les problèmes de sécurité liés au fait de donner au navigateur web trop d’accès aux ressources locales.
      Confort et sécurité font rarement bon ménage.
    • J’ai déjà flashé un appareil Android avec WebUSB.
      C’est utile et facile, mais c’est aussi un terrain idéal pour l’apparition de vulnérabilités.
      Il faut arrêter l’embonpoint du web.
      Le navigateur ne doit pas devenir l’évier fourre-tout contenant tout ce que n’importe qui dans l’industrie tech veut y mettre.
      Installer une application native n’est pas si difficile.
    • Par exemple, il arrive qu’on achète une étiquette d’expédition tout en pesant l’objet réel avec une balance.
      Strictement parlant, ce n’est pas de l’USB mais du HID, mais l’idée est similaire.

  • C’est un peu hors sujet, mais l’essentiel de ce fil semble porter sur WebUSB en général plutôt que sur l’article d’origine
    Cela dit, le hack présenté dans l’article est vraiment assez chouette
    D’un côté, WebUSB est vraiment nécessaire, mais de l’autre, je n’ai vraiment pas envie que WebUSB soit mis entre les mains des utilisateurs ordinaires
    En pratique, les pop-ups de consentement n’ont pas fonctionné, et les gens acceptent n’importe quoi sans même s’en rendre compte
    Ils disent « je n’ai cliqué sur rien », mais on finit par fermer 50 notifications push de spam et supprimer les autorisations push d’une douzaine de sites de « news »
    Franchement, le modèle de permissions à la Internet Explorer me plaît jusqu’à un certain point
    Pour activer certaines fonctionnalités, il fallait marquer un site comme « de confiance »
    C’était difficile à trouver, ça prenait un peu de temps, c’était un peu déroutant, et une fenêtre modale au style système affichait une grosse icône d’avertissement assez effrayante
    Si, pour utiliser des API dangereuses comme WebUSB ou WebBluetooth, il fallait passer par une procédure consistant à marquer le site comme « de confiance », beaucoup moins de gens l’activeraient par erreur
    L’expérience utilisateur resterait meilleure que l’installation d’une application native, avec le sandboxing en prime, donc ce compromis semble en valoir la peine

    • Les notifications web de Chrome sont aussi une décharge totale
      L’utilisateur âgé moyen n’a absolument aucune idée de ce que sont les notifications web
      Avec le temps, il active par erreur les notifications de sites web louches et croit vraiment aux notifications de spam web qui arrivent sur son téléphone, du genre « HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE »
    • C’est un combat éternel
      Certaines personnes semblent avoir un superpouvoir pour casser les choses
      Si quelque chose n’est pas rendu littéralement impossible, elles trouveront forcément un moyen de le faire par erreur
      Elles suivent des guides qui modifient des réglages qu’elles ne comprennent pas, lancent des fonctionnalités qu’elles ne comprennent pas et accordent des accès qu’elles ne comprennent pas
      Peu importe à quel point on complique la procédure, combien d’avertissements on ajoute et combien d’efforts on fait pour empêcher ce genre de bêtise : cela arrive quand même
      Le problème, c’est qu’il existe aussi des gens qui savent ce qu’ils font et qui l’utilisent intentionnellement
      Ces personnes peuvent apprécier des fonctionnalités puissantes qu’il ne faudrait jamais donner à un idiot
      Mais le plus pénible, c’est qu’en exposant ce pouvoir, il est difficile, en pratique, d’éviter d’être submergé par des gens qui font des choses stupides
    • Je suis d’accord
      Un gros problème est qu’on ne comprend pas vraiment à quel point beaucoup d’utilisateurs ne comprennent absolument pas ce qu’ils font
      Google ne sait pas concevoir des logiciels sûrs pour ces personnes
      Les procédures pénibles peuvent sembler inutiles, mais elles ont souvent un objectif clair
      Vérifier que l’intention de l’utilisateur est bien ferme
      Apple a récemment implémenté certaines API web de façon à ce qu’elles ne fonctionnent que si le site web a été installé, et cela ressemble à une stratégie qui comprend la conception pour des humains
      Elle permet d’accéder à des fonctionnalités PWA utiles, mais pas de laisser n’importe quel site les utiliser arbitrairement
      Il y a une étape supplémentaire compréhensible par une personne ordinaire
      Une PWA installée reste visible sur l’écran d’accueil, ce qui rappelle visuellement l’autorisation accordée et constitue un signal clair que l’utilisateur voulait cet accès
    • Je veux vraiment que le grand public puisse aussi y accéder
      Beaucoup de gens doivent interagir avec des appareils, et aujourd’hui les applications distribuées via des App Store fermés sont souvent, de fait, la seule option
      Pour diffuser à davantage de personnes un moyen d’accéder à des appareils qui ne sont plus officiellement pris en charge, WebUSB est de très loin la méthode la plus simple
      Dans un autre monde où Chrome ne le prendrait pas en charge, l’utilisateur ordinaire aurait dû être capable d’installer et d’exécuter [python or other scripting language]
      Si le développeur était vraiment motivé, il aurait peut-être dû fournir une application desktop, ou passer par le long et coûteux processus de soumission à l’App Store
      Je pense qu’il est possible de créer une UI sûre pour WebUSB, et je ne vois pas bien non plus quels appareils branchés par l’utilisateur moyen pourraient être compromis
      WebUSB ne devrait pas permettre de prendre le contrôle d’un clavier ou d’une souris (HID), d’un support de stockage, du Wi-Fi, de l’audio, d’une carte à puce ou d’un appareil U2F
      En revanche, il est très utile pour les imprimantes d’étiquettes propriétaires, toutes sortes de jouets et d’appareils, ainsi que pour programmer et flasher des microcontrôleurs
    • Les invites modales par lesquelles les applications et les sites web demandent des permissions sont ce qu’il y a de pire en matière d’expérience utilisateur
      C’est facile et pratique à utiliser, mais cela permet aussi de donner par erreur un accès très large à un tiers non fiable
      Accorder une permission à une page devrait, comme vous l’avez dit, être un flux explicitement lancé par l’utilisateur depuis le panneau des permissions
      Il devrait en aller de même pour les applications desktop sandboxées
      Si une application veut enregistrer l’écran en continu, elle devrait obtenir explicitement cette permission depuis le panneau de contrôle des autorisations
      Elle ne devrait pas pouvoir afficher une boîte de dialogue modale qui pousse les gens à cliquer simplement sur « yes »
      Dans de nombreux cas, les gens ne comprennent pas techniquement ce qu’on leur demande

  • USB Serial est vraiment excellent
    Il met enfin fin à ces pénibles apps Electron à usage unique
    Il existe maintenant des outils pour configurer des appareils depuis le navigateur, et c’est très bien
    Il suffit de regarder ESPHome et les centaines de projets qui s’appuient dessus, Betaflight, ELRS, Flipper
    Je comprends que WebKit soit peu pris en charge puisque c’est Apple qui le développe, et je comprends aussi qu’ils soient prudents s’il s’agit d’autoriser l’accès aux périphériques
    Mais Firefox, c’est différent
    Firefox a toujours eu un sérieux manque de prise en charge des “connexions” matérielles et n’a pas été très accueillant pour les développeurs depuis longtemps, si bien que j’ai fini par ne plus l’utiliser
    Dire que le consentement de l’utilisateur ne suffit pas pour autoriser l’accès aux appareils comme raison de ne pas le prendre en charge, ça n’a aucun sens
    Ils auraient au moins pu le mettre derrière un flag développeur
    Blink a prouvé qu’on pouvait le rendre sûr
    Ils semblent s’entêter sans raison et ne pas voir les cas d’usage qui rendraient le navigateur utile
    https://developer.mozilla.org/en-US/docs/Web/API/Serial
    https://mozilla.github.io/standards-positions/

    • Il y a eu un problème de sécurité assez important où un site web malveillant pouvait accéder à des clés FIDO/U2F via WebUSB
      Les identifiants U2F sont censés être impossibles à phisher
      C’est parce que l’API U2F du navigateur inclut le nom de domaine dans la requête envoyée au jeton
      Mais avec WebUSB, un site pouvait demander un jeton pour n’importe quel nom de domaine
      Comme U2F et WebUSB affichaient tous deux des boîtes de consentement utilisateur assez similaires, il était pratiquement impossible d’éviter que certains utilisateurs se trompent
      Aussi incroyable que cela paraisse, la solution de Google a été de placer de nombreux appareils sur une liste de blocage WebUSB
      Désormais, les fabricants d’appareils U2F doivent demander à Google d’ajouter chaque nouveau produit à la liste de blocage lorsqu’ils le lancent
      Tout le monde aime l’idée que le navigateur soit un bac à sable sûr permettant d’exécuter du code non fiable, mais je ne comprends pas pourquoi tant de gens veulent percer autant de trous dans ce bac à sable
      [1] https://www.yubico.com/support/security-advisories/ysa-2018-...
      [2] https://github.com/WICG/webusb/blob/main/blocklist.txt
    • Même avec des microcontrôleurs sous la main, je peux compter sur les doigts d’une main le nombre de fois où j’ai eu besoin de WebUSB ou de WebSerial
      Je ne pense pas que le risque de fingerprinting vaille la peine pour les quelques dizaines d’utilisateurs finaux qui n’auraient pas à télécharger une app Electron pour interagir avec du matériel physique
      Implémenter une fonctionnalité puis la verrouiller derrière un toggle développeur, c’est délirant
      Cela revient à gaspiller des centaines d’heures de développement qui pourraient servir à quelque chose d’utile, juste pour exposer une fonctionnalité que personne ne trouvera de toute façon
      En tant que développeur, cela ne me dérange pas que ce genre d’API réservée à Chrome reste dans Chrome
      De toute façon, il faut garder un navigateur Chromium sous la main pour les sites qui cassent réellement dans Firefox, donc autant l’utiliser pour les opérations Web USB
      C’est une démo technologique intéressante, mais ce n’est pas le rôle d’un navigateur
      Le fait que personne n’ait ajouté WebUSB sous forme d’extension Firefox semble aussi montrer que, même pour ceux qui l’utilisent, cela ne vaut pas le temps de développement
    • Ce n’est pas vrai
      Des problèmes de confidentialité et de sécurité ont été soulevés
      Web Serial n’est pas un standard du Web, et ne pourra pas le devenir tant que Mozilla ou Apple ne considéreront pas que ces problèmes sont résolus
      Google ne peut pas en faire seul un standard du Web ; un standard nécessite un consensus
      La discussion côté Mozilla est ici : https://github.com/mozilla/standards-positions/issues/336
      La discussion côté WebKit est ici : https://github.com/WebKit/standards-positions/issues/199
    • Je ne sais pas combien d’appareils vous configurez par jour pour en arriver là
      J’ai du mal à imaginer abandonner Firefox pour la navigation web à cause de webusb
    • Je n’accepte pas que mon matériel physique devienne soudain impossible à programmer simplement parce que l’entreprise qui hébergeait le site de flashage a fait faillite
      Il faut que ce soit un logiciel téléchargeable, qui ne dépende pas d’un serveur externe
      Cela dit, si l’appareil dépend dès le départ des serveurs de cette entreprise pour fonctionner, alors ne pas avoir à télécharger ni à faire confiance à un logiciel est un avantage

  • Le fait que du code exécuté dans un navigateur ne puisse pas utiliser de ports USB est peut-être plutôt une bonne chose

    • En tant qu’utilisateur Linux, j’aime WebMIDI
      Parce que je n’ai plus besoin de lancer une VM Windows pour exécuter des mises à jour de firmware ou des outils utilitaires de fabricants de matériel audio qui le prennent en charge, comme Novation
      WebUSB devrait permettre la même chose pour davantage de types d’appareils, mais il faut évidemment un mécanisme d’autorisations approprié

  • Pour les personnes qui flashent souvent des appareils, l’avantage est évident
    Mais l’utilisateur ordinaire, c’est-à-dire les quelque 3 milliards d’autres personnes, s’en moque complètement
    Percer des trous dans le bac à sable pour eux est, au mieux, imprudent
    La solution pourrait être un outil séparé dédié à cet usage, peut-être même un navigateur séparé
    Quelque chose comme Flash Browser
    Il pourrait inclure des outils supplémentaires pour aider à cette tâche
    Par exemple des listes d’autorisation ou de blocage préconfigurées, des favoris vers les outils de flashage courants, et de la documentation
    On pourrait offrir une meilleure expérience que d’ajouter WebUSB brut de force dans le navigateur

  • Je comprends les controverses et critiques autour de ce “standard”, mais quand je l’ai utilisé pour flasher GrapheneOS sur un téléphone Pixel, c’était l’installation d’OS la plus agréable, simple et rapide que j’aie jamais faite sur un appareil
    Littéralement : on branche, on clique, et c’est prêt

  • Le fait que la clé privée soit chiffrée avec une clé « maître », puis que la clé privée chiffrée soit renvoyée comme handle de clé, est surprenant
    Cela doit effectivement fonctionner
    Donner à un attaquant des occasions illimitées de tenter de déchiffrer la clé privée qu’il a en main me semble voué à se retourner contre soi un jour ou l’autre, mais qu’est-ce que j’en sais

    • À bien y réfléchir, c’est exactement le même risque que pour toute implémentation possible d’authentificateur sans état
      Par exemple, une autre approche consisterait à générer la clé privée par dérivation déterministe à partir du handle de clé
      Un attaquant pourrait aussi la brute-forcer, tout comme la clé chiffrée propre à un site stockée dans le handle de clé
      Le point essentiel est qu’un authentificateur sans état est, par définition, déterministe globalement, c’est-à-dire sur l’ensemble des secrets et des sites
      Avec une paire entrée-sortie, on peut tenter de brute-forcer le secret interne
      La solution consiste à rendre cet état interne suffisamment grand pour que ce soit informatiquement impossible

  • Je me demande quelle est la controverse politique autour de WebUSB

    • WebUSB n’est pas un standard du Web
      C’est une API propre à Blink créée par Google, et Mozilla comme Apple l’ont rejetée pour des raisons de confidentialité et de sécurité
      Sans deux implémentations indépendantes, cela ne peut pas devenir un standard du Web, et Google n’a convaincu personne en dehors de Google de l’implémenter
      Pourtant, sur de nombreux sites web, Firefox et Safari sont présentés comme s’ils « ne prenaient pas en charge » cette API
      “This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.”
      — https://wicg.github.io/webusb/
      “WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting”
      “We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.”
      — https://github.com/WebKit/standards-positions/issues/68
      “Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.”
      — https://mozilla.github.io/standards-positions/#webusb
    • Je ne connais pas vraiment la controverse politique en général, mais personnellement je ne veux pas de WebUSB et je trouve que c’est une très mauvaise idée
      Le navigateur peut déjà accéder aux périphériques USB nécessaires via les interfaces habituelles de l’OS
      Le clavier et la souris en sont des exemples évidents
      Je ne vois pas pourquoi un site web devrait avoir besoin d’un accès direct séparé
      Les seuls cas d’usage semblent être de donner un accès à des programmeurs web qui ont la flemme d’utiliser une application autonome, ou d’offrir une méthode supplémentaire pour suivre les utilisateurs
      Je n’ai envie de faire confiance à aucun des deux
      Je ne fais déjà pas assez confiance à Google et Mozilla pour leur donner ce type d’accès, alors encore moins à un inconnu quelconque qui a créé un site web
      Tout ne doit pas forcément être accessible depuis le Web
      Je ne sais pas où tracer la limite, mais pour moi l’accès USB la franchit
    • C’est la politique entre exposer les utilisateurs à des problèmes de sécurité et donner davantage de capacités au Web
      En général, ce sont ceux qui veulent des fonctionnalités tout de suite qui gagnent ce bras de fer
      Parce que les failles de sécurité ont l’air hypothétiques jusqu’à ce qu’elles soient exploitées en conditions réelles
    • Fondamentalement, c’est un problème de fingerprinting, et aussi la question de savoir si les navigateurs devraient avoir encore plus de capacités à ce stade
      Plus c’est le cas, plus la dépendance à Chrome devient profonde
    • C’est probablement parce que le navigateur peut accéder au matériel
      Moi non plus, je n’en veux pas