La nouvelle version du navigateur promet des améliorations de performances et plusieurs nouveautés pour les développeurs, détaillées par ici.
Mais on note également l'arrivée d'un encodeur AV1, un codec plus efficace pouvant être utilisé par des applications RTC, les équipes citant Duo, Meet ou Webex.
Le port 554, très peu utilisé selon les relevés de Google et d'autres navigateurs est aussi bloqué désormais pour éviter certaines attaques, dont NAT Slipstreaming 2.0.
Commentaires (24)
#1
Je comprend pas trop le “blocage du port 554”, car Chrome n’est pas un OS, donc au mieux, il peut juste ne pas ouvrir un serveur sur le port 554.
En lisant https://www.bleepingcomputer.com/news/security/google-chrome-to-block-port-554-to-stop-nat-slipstreaming-attacks/ , j’ai l’impression que Chrome bloque en fait l’accès au port 554 (ainsi qu’à une longue liste d’autres ports) d’une machine distante, donc une url comme www.google.com:554 ne fonctionne plus
#2
Étrange car le blog Google Chrome ne mentionne que la 89 et pas la 90…
https://chromereleases.googleblog.com/2021/04/stable-channel-update-for-desktop.html
#3
C’est vraiment énervant ces navigateurs qui bloquent des ports sans rien demander à l’utilisateur. Et dans certains cas on ne peux même pas désactiver le blocage…
J’ai mon intranet privé sur le port 554, j’ai plus le droit d’y accéder maintenant ?!
#3.1
surtout qu’il aurait été beaucoup plus logique de bloquer l’ouverture d’une connexion au port 554 d’un serveur différent de celui de la page web depuis javascript, et non pas globalement
#3.2
Il faut lire le lien donné par le 1er commentaire qui explique très bien le problème et pourquoi limiter le domaine de destination ne change rien vu que c’est exploit qui touche le routage des requêtes par ton routeur.
#3.3
Merci de me dire de lire un lien que j’ai moi-même posté ^^
Et l’attaque repose uniquement sur du javascript malveillant, donc aucune raison (à part celle de la facilité) de bloquer les ports globalement.
Mais à ce rythme, on va se retrouver avec une liste de ports autorisés de plus en plus petite
#3.4
Dans ce cas tu l’a mal lu. Ça n’implique pas nécessairement un JS externe à la page que tu viste. C’est parfaitement faisable sur un seul domaine. C’est une attaque qui utilise des mécanismes équivalents à STUN et permet du coup à accéder au port de ta machine depuis internet.
Ceux qui critique “Google” peuvent lire https://github.com/whatwg/fetch/pull/1148 et voir que c’est fait en accord avec les autres Browser. Mozilla le bloque déjà.
#3.5
Ai-je dit que ça nécessitait un script externe à la page ? Par contre ça nécessite du javascript malveillant qui se connecte à un site différent de la page visitée et sur le port 554.
Un navigateur, ça ne sert pas juste à aller sur internet, le réseau ne se limite pas à internet, heureusement
#4
Quoi, Internet c’est pas le port 443 ? On m’aurait menti ? Enfin de nos jour c’est de plus en plus l’impression que ça donne…
#4.1
On parle ici de ports utilisés depuis un navigateur. Mais, ça n’empêche pas que bloquer des ports pour protéger de failles dans les routeurs, c’est un peu abusif.
Surtout que le port 69 est lui aussi bloqué ! On ne peut même plus faire un site Web X sur ce port !
#4.2
Balance ton port !
#4.3
Merci à mes 2 VDD pour cet échange extrêmement constructif.
C’est pour ça que j’aime particulièrement les commentaires ici
Cette histoire de port 69 me chagrine aussi …
#5
Les ports numérotés de 1 à 1024 (ou 1023, je sais plus) sont réservés à des usages particuliers. Par exemple, le port 80 est le serveur http, 443 le https, 20 et 21 pour ftp, etc. Ces ports sont attribués par l’IANA.
Je ne sais pas par coeur à quoi exactement est dédié le port 554 (et je m’en fiche un peu, je dois dire…), mais créer un serveur web intranet qui écoute sur ce port pour faire du http(s) est le meilleur moyen de se prendre un problème de compatibilité dans la tronche le jour où la machine inclura un service qui veut justement rendre le service associé au port 554. Ou bien, comme c’est le cas ici, quand un antimalware bloque ce port pour éviter un exploit.
Accessoirement, beaucoup d’OS interdisent à un processus de faire un “listen” sur un port < 1024 s’ils n’est pas root.
C’est pour cela que la plupart des serveurs http qui veulent utiliser un port autre que 80 se rabattent plutôt sur 8080. Ou 2000, ou 3000, ou 4000 comme Angular, Node.js ou Python.
#6
Voir mon commentaire précédent pour le blabla technique (désolé, trop tard pour faire un edit et include mes deux réponses dans un seul post), mais oui, Internet c’est le port 443…
#7
Pas du tout, le port 443 c’est HTTPS (et seulement par défaut, on peut le changer), et ce n’est qu’un seul protocole utilisé sur Internet, qui englobe beaucoup beaucoup plus que ça.
Restreindre la définition d’Internet comme tu le fais ici, c’est justement le genre de chose reprochée ici à Google, et c’était même la signification du commentaire ironique que tu as cité, apparemment sans avoir compris l’ironie. Tout comme on voit régulièrement certains membres utiliser le terme Minitel pour désigner la dérive de la définition d’Internet chez pas mal d’acteurs et personnalités publiques.
#7.1
De fait, tu as raison, j’ai répondu un peu trop vite et trop succinctement. En faisant l’amalgame Internet = https. Je l’avais fait exprès, un peu, ça m’a pété à la tête.
Comme être succint n’a pas marché, accroche-toi, je vais être verbeux.
TL;DR: “Internet” délaisse pas mal de well-known ports, mais ce n’est pas un blanc-seing pour que n’importe qui se les réapproprie.
Internet, de nos jours, se résume pour le grand public à quelques sites qui fonctionnent tous en http. De plus en plus de protocoles qui étaient autrefois distincts passent tous désormais par un transport http(s), même pour transporter du json.
C’est parti du fait que de nombreuses grosses boîtes bloquaient l’accès extérieur à tout ce qui ne passait pas par 80⁄443, ce qui a poussé les fournisseurs de service à passer par http(s) pour tout et n’importe quoi. Même le mail et l’upload de fichiers passe désormais par du json (bon, ouf, ça aurait pu être du XML), alors qu’il existe (existait) des protocoles spécialisés. Pratiquement tout, de nos jours, passe par une connexion https qu’on upgrade en websocket si on veut du bidirectionnel.
C’est très vrai que pour me connecter au bureau j’utilise un VPN (un “vrai” VPN, pas un truc pour pirater Netflix). Ben il utilise le port 443. J’ai un Outlook (pas taper, merci) pour mon mail pro. Ben il utilise le port 443. J’ai une messagerie instantanée. Ben elle utilise le port 443. Et je me connecte pour mes tests à un serveur Postgres, ben il utilise le port
443ah tiens non 5432 :-) Ah, et SSH semble résister lui aussi, quoique je suspecte que pas mal de gens voudraient faire passer SSH par un websocket…#8
Bonne chose que Chrome bloque les ports utilisés pour les attaques NAT Slipstream.
Plus important que le 554, c’est le blocage du port 10080.
Autant les ports < 1024 sont souvent bloqués, autant celui là est trop grand et est souvent laissé ouvert. D’autant plus qu’il termine par “80” ce qui laisse croire que c’est pour du dev http :)
#9
Ca a fini en tête à queue cette histoire.
#10
On va être deux alors
Les ports ne sont à personne, on ne peut pas les perdre ni se les réapproprier. Même ceux qui sont encore couramment utilisés sur la majorité des serveurs peuvent signifier autre chose sur un autre serveur. On parle bien de blocage de connexions sortantes, le navigateur qui le bloque ne peut avoir aucune idée de ce qui va passer dessus, que ce soit un port courant ou non, ni des caractéristiques des équipements réseau qui suivent, et de leur vulnérabilités potentielles. C’est de la divination que de se dire qu’il y a peut-être un NAT foireux quelque part.
Ca ne date pas de nos jours, ça s’est peut-être accentué, mais pour le grand public, Internet a toujours été uniquement le Web et les messageries. Ca ne veut pas dire que des gens peu informés ne peuvent pas être initiés à un usage plus particulier par d’autres plus informés, et c’est important qu’ils ne soient pas bloqués à ce moment-là parce que quelqu’un a décidé unilatéralement et plus ou moins discrètement que c’était “peu utilisé”.
J’utilise plein de services entre mes machines éloignées sur des ports que j’ai choisis moi-même. A quel moment peut-on penser que le port que j’utilise est trop suspect pour que je puisse le faire ? A ce rythme-là, pourquoi ne pas bloquer silencieusement aussi des noms de domaines suspects (ne pas confondre avec les fonctionnalités type filtre anti-phishing, où l’utilisateur est clairement informé et peut passer outre voire le désactiver) ?
Ou alors c’est le genre de choses que je peux attendre d’un firewall, et je sais que si j’en ai un d’installé (ce qui est le cas de quasiment tout le monde aujourd’hui), il va bloquer des trucs indéfinis si je ne le configure pas correctement, et où on peut voir ce qui est bloqué et ce qui ne l’est pas. Mais bon c’est pas le boulot d’un navigateur de faire ça, et en plus sans rien dire à personne.
Tu peux chercher longtemps où ça coince avec ce genre de truc, et un débutant ne cherchera pas longtemps. Ca peut aussi bloquer des usages sur du matériel existant, même récent, où il n’est pas possible de changer le port, juste parce que quelques gens ont décidé que c’était mal. Et y a pas que le 554, y en a toute une tripotée. C’est pas du tout ma vision d’Internet, et faut pas s’étonner avec des décisions pareilles que des entreprises refusent des mises à jour logicielles.
#11
C’est semble-t-il sur ce point précis que nous ne sommes pas d’accord. Les standards de TCP/IP ont depuis longtemps été adaptés pour que les réseaux se fondent bien dans une structure de type Internet. Se fondre dans la structure requiert un certain nombre de concessions à la liberté absolue.
En théorie, rien ne t’empêche de nommer un de tes serveurs “localhost”. Rien ne t’empêche d’attribuer à ton serveur une adresse réservée à Google. Rien ne t’empêche de te créer un réseau local avec un netmask en /2 (pour la simplicité du propos, j’ignore volontairement IPv6).
En pratique, cependant, si tu fais cela, hé bien ça ne marchera pas correctement dans un certain nombre de cas. Ca ne marchera pas, et ce sera entièrement de ta faute, personne ne te donnera raison si tu te plains que Chrome restreint ta liberté de faire tout et n’importe quoi.
Il en va de même pour les ports. Les 1024 premiers sont réservés. Ils n’appartiennent certes à personne mais leur usage est prescrit par des normes. En théorie tu fais ce que tu veux, mais en pratique, y’en a qui ont essayé, et ils ont eu des problèmes. Si tu ne respectes pas ces normes, tu ne peux pas reprocher que les applications qui tentent de les respecter soient impactées négativement. Tu peux t’attendre par exemple qu’un NAT reconnaisse nativement les ports 20 et 21 pour laisser passer du FTP sans action particulière de ta part, alors qu’il ne le fera pas si tu mets ton ftp sur les ports 22 et 23…
Je me permets un parallèle avec CORS aussi. Il y a plein d’applications qui font légitimement appel à une API sur un site A alors qu’ils viennent d’un site B, et pourtant ça ne marchera pas si on ne se plie pas à un certain nombre de règles absconses qu’un débutant n’a strictement aucune chance de suivre. Là non plus, le navigateur n’a pas une connaissance a priori des vulnérabilités cross-domain du site, il bloque et basta démerde-toi.
Tout ceci étant dit nous sommes bien d’accord que si un navigateur inclut son propre firewall, il devrait clairement s’identifier comme tel et être aussi configurable que n’importe quel autre firewall afin de passer outre les blocages.
Il est à-peu-près garanti que si tu choisis des ports dans le range dynamique, la probablilté que tu aies des ennuis est fortement diminuée par rapport au cas où tu choisirais un port en-dessous de 1024… Personnellement, j’ai attribué des ports custom à mes applications dans un range au-dessus de 50000 et aucun firewall n’a jamais bloqué un quelconque de ces ports (même si ce n’est pas une garantie absolue, je te l’accorde).
#12
Sauf qu’il y a déjà de la triche répandue, notamment comme tu l’indiquais dans un post précédent, mettre autre chose que du HTTPS sur le port 443. Ca relativise la validité de cette norme dans la pratique.
Fortement diminuée mais pas supprimée, puisque dans la liste des ports bloqués par Firefox et Chrome, il y a des ports >=1024. Tu n’es donc pas à l’abri qu’un jour, un des ports que tu as choisi ne leur revienne pas et qu’il soit bloqué. Firefox est d’ailleurs bien plus explicite dans ce cas, avec même un bouton disponible directement pour passer outre.
VDD ?
#13
Un port dynamique, c’est à partir de 50000…
Voisin du dessus.
J’ai dû chercher aussi
#14
Non, 49152.
2^15+2^14
#14.1
Oui, je sais, 0xC000 mais en pratique 50000 est une bonne approximation si ton but est de choisir un port qui a une chance d’être libre.