Alfred1664 a dit:

J’ai mon intranet privé sur le port 554, j’ai plus le droit d’y accéder maintenant ?!

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.

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 ⁸⁰⁄₄₄₃, 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 443 ah 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…

Inodemus a dit:

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.

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.

J’utilise plein de services entre mes machines éloignées sur des ports que j’ai choisis moi-même.

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).

Inodemus a dit:

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.

Un port dynamique, c’est à partir de 50000…

VDD ?

Voisin du dessus.
J’ai dû chercher aussi

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.