Ouais, ben justement DLFP fait partie de ces sites qui s'apparentent plus à un forum usenet - d'ailleurs la passerelle existe - qu'à un site web traditionnel "avec contenu". Et si je n'utilise pas usenet, c'est simplement parce que la plupart des clients chez qui je taffe ne proposent qu'un proxy http 8-(
Par exemple, pourquoi faire du transfert de fichier par http plutôt que ftp? Ben imaginons que j'héberge un site web, avec des liens vers des fichiers ftp. Bon. Un jour un gars me dit "salut ch'suis emmerdé ch'peux pas charger ton fichier j'ai pas accès à ftp :-( ". Bon, bah comme je suis pas contrariant je vais installer la passerelle vers http, et hop voilà comment ftp est petit à petit bouffé par le web, alors que celui-ci n'est pas adapté.
Typiquement, j'ai très souvent eu des problèmes pour télécharger Emacs pour NT en http alors que c'est simple comme chou de le trouver en ftp. Je peux pas trop en vouloir à la FSF, ils proposent leurs fichiers en accès ftp, c'est très rationnel et ça colle bien à l'esprit "respectons les standards".
Et je me demande si l'incroyable succès du port 80 n'est pas simplement d'être autorisé par la plupart des firewalls. Aujourd'hui on voit de plus en plus de protocoles qui peuvent être "encapsulés" dans des requêtes HTTP. Alors voila, quelle est l'intérêt d'une telle manoeuvre?
A long terme, c'est nul, parce que tout va passer par le port 80, les autres ports seront désertés - trop ringard - et on sera ramené au cas précédent, à savoir qu'il faudra interpréter le contenu de ce qui passe sur le port 80 pour savoir quel type d'info c'est.
D'ailleurs dès aujourd'hui certains firewall savent reconnaître si on fait passer le bon protocole sur le bon port. Mais ça va pas être de la tarte pour faire le tri plus tard, une fois que tout pourra potentiellement passer n'importe où, et où il faudra faire le tri sur le contenu et pas seulement sur la forme.
D'un point de vue sécurité, la situtation "toutes les applications sont capables de se déguiser en HTML sur HTTP" est déplorable. C'est d'ailleurs un des aspects de la plate-forme .NET de Microsoft, tu peux appeler des "web services" un peu partout, et donc tu ne bénéficie plus de la protection des firewalls. OK c'est vrai un firewall ne se contente pas que de laisser passer tel ou tel port, il sait aussi analyser la provenance/destination des packets. Mais quand même, je pense pas que ça soit un bon choix de tout déguiser en HTTP.
L'eternelle course à l'armement:
je suis un firewall qui bloque tout ce qui est méchant
je suis un gentil packet mais je me déguise quand même on n'est jamais trop sur
ha ha ha je t'ai reconnu!
et non c'est même pas vrai je suis un gentil packet j'ai le droit de passer
ranapété, access denied, NA! (ça servira de leçon aux autres)
En tous cas, ça risque de donner du boulot aux informaticiens pour encore un sacré bout de temps 8-)
[^] # Re: Happy birthday to you !
Posté par ufoot . En réponse à la dépêche Le Web a dix ans. Évalué à 1.
Par exemple, pourquoi faire du transfert de fichier par http plutôt que ftp? Ben imaginons que j'héberge un site web, avec des liens vers des fichiers ftp. Bon. Un jour un gars me dit "salut ch'suis emmerdé ch'peux pas charger ton fichier j'ai pas accès à ftp :-( ". Bon, bah comme je suis pas contrariant je vais installer la passerelle vers http, et hop voilà comment ftp est petit à petit bouffé par le web, alors que celui-ci n'est pas adapté.
Typiquement, j'ai très souvent eu des problèmes pour télécharger Emacs pour NT en http alors que c'est simple comme chou de le trouver en ftp. Je peux pas trop en vouloir à la FSF, ils proposent leurs fichiers en accès ftp, c'est très rationnel et ça colle bien à l'esprit "respectons les standards".
Et je me demande si l'incroyable succès du port 80 n'est pas simplement d'être autorisé par la plupart des firewalls. Aujourd'hui on voit de plus en plus de protocoles qui peuvent être "encapsulés" dans des requêtes HTTP. Alors voila, quelle est l'intérêt d'une telle manoeuvre?
A long terme, c'est nul, parce que tout va passer par le port 80, les autres ports seront désertés - trop ringard - et on sera ramené au cas précédent, à savoir qu'il faudra interpréter le contenu de ce qui passe sur le port 80 pour savoir quel type d'info c'est.
D'ailleurs dès aujourd'hui certains firewall savent reconnaître si on fait passer le bon protocole sur le bon port. Mais ça va pas être de la tarte pour faire le tri plus tard, une fois que tout pourra potentiellement passer n'importe où, et où il faudra faire le tri sur le contenu et pas seulement sur la forme.
D'un point de vue sécurité, la situtation "toutes les applications sont capables de se déguiser en HTML sur HTTP" est déplorable. C'est d'ailleurs un des aspects de la plate-forme .NET de Microsoft, tu peux appeler des "web services" un peu partout, et donc tu ne bénéficie plus de la protection des firewalls. OK c'est vrai un firewall ne se contente pas que de laisser passer tel ou tel port, il sait aussi analyser la provenance/destination des packets. Mais quand même, je pense pas que ça soit un bon choix de tout déguiser en HTTP.
L'eternelle course à l'armement:
En tous cas, ça risque de donner du boulot aux informaticiens pour encore un sacré bout de temps 8-)