Le problème est qu'il y a divergence fondamentale entre les besoins des utilisateurs et les impératifs des administrateurs d'un firewall.
L'administrateur veut une configuration qui fournisse une infrastucture sécurisée. Le principe est que par défaut ils interdisent tout ce qu'il n'est pas nécessaire comme protocol (ou plutôt interdire l'usage des ports associés aux services).
Ceci est complètement opposé au besoins de l'utilisateur. Qui peut varier avec le temps. Et nécessiter divers protocole non-autorisés par l'administrateur :(
Par exemple, il est courant de constater que les administrateurs interdisent tous les protocols vers l'extérieur sauf HTTP / HTTPS. En conséquence de quoi, les utilisateurs au lieu de pouvoir accéder aux différents services escomptés (FTP, POP, IMAP, ...) se retrouvent limités à des interfaces web. Et ne peuvent utiliser leurs logiciels habituels.
Pour palier à ces problèmes est arrivé la solution de tout encaspuler dans des trames HTTP, par exemple on peut citer : SOAP (le plus souvent utilisé sur HTTP), WebDAV, ou bien encore les tunnels HTTP.
Ceci est une réponse qui n'est pas satisfaisante car elle consiste à confiner une protocols au niveau de l'application, et à rajouter une couche dans la couche applicative qui sera la véritable couche applicative. En clair, on remet une couche inutile pour palier à une limitation des configuration.
Quelle est la solution ?
Il faudrait que les firewall et les applications puissent dialoguer ensemble. L'application devrait être sécurisée, et fournir son certificat d'autenticité ainsi que ça demande de "laisser-passer" au firewall. Le laisser-passer devrait définir les besois en terme de ressources résaux distantes (protocole utilisé, référence aux standards suivit, identificaiton formelle des resources) Suite à quoi, le firewall devrait laiser passer la communication si celle-ci est digne de confiance (possibilité de paramètrer dans le firewall).
Il appartiendra alors au firewall de vérifier (suivant sa capacité de ontrole du protocole) à tout moment que l'utilisation faite par l'application des resources allouées est bien conforme aux déclarations indiquées par le laisser-passer.
De plus il faudrait supprimer le concept de "proxy" et le remplacer par des "proxy transparents", le firewall étant une fonctionalité de ce proxy transparent.
L'utilisation en parallèle de plage IPv6 simplifierai aussi le paramètrage de firewall grâce à l'identification de bout en bout de la chaine d'appel au niveau IP.
Bref, comme tout ceci n'exite pas, les protocols sur HTTP ont un avenir radieu ;-)
[^] # Justement !
Posté par Hive Arc . En réponse à la dépêche Firefox 1.0 RC1 et autres nouvelles de Mozilla. Évalué à 9.
L'administrateur veut une configuration qui fournisse une infrastucture sécurisée. Le principe est que par défaut ils interdisent tout ce qu'il n'est pas nécessaire comme protocol (ou plutôt interdire l'usage des ports associés aux services).
Ceci est complètement opposé au besoins de l'utilisateur. Qui peut varier avec le temps. Et nécessiter divers protocole non-autorisés par l'administrateur :(
Par exemple, il est courant de constater que les administrateurs interdisent tous les protocols vers l'extérieur sauf HTTP / HTTPS. En conséquence de quoi, les utilisateurs au lieu de pouvoir accéder aux différents services escomptés (FTP, POP, IMAP, ...) se retrouvent limités à des interfaces web. Et ne peuvent utiliser leurs logiciels habituels.
Pour palier à ces problèmes est arrivé la solution de tout encaspuler dans des trames HTTP, par exemple on peut citer : SOAP (le plus souvent utilisé sur HTTP), WebDAV, ou bien encore les tunnels HTTP.
Ceci est une réponse qui n'est pas satisfaisante car elle consiste à confiner une protocols au niveau de l'application, et à rajouter une couche dans la couche applicative qui sera la véritable couche applicative. En clair, on remet une couche inutile pour palier à une limitation des configuration.
Quelle est la solution ?
Il faudrait que les firewall et les applications puissent dialoguer ensemble. L'application devrait être sécurisée, et fournir son certificat d'autenticité ainsi que ça demande de "laisser-passer" au firewall. Le laisser-passer devrait définir les besois en terme de ressources résaux distantes (protocole utilisé, référence aux standards suivit, identificaiton formelle des resources) Suite à quoi, le firewall devrait laiser passer la communication si celle-ci est digne de confiance (possibilité de paramètrer dans le firewall).
Il appartiendra alors au firewall de vérifier (suivant sa capacité de ontrole du protocole) à tout moment que l'utilisation faite par l'application des resources allouées est bien conforme aux déclarations indiquées par le laisser-passer.
De plus il faudrait supprimer le concept de "proxy" et le remplacer par des "proxy transparents", le firewall étant une fonctionalité de ce proxy transparent.
L'utilisation en parallèle de plage IPv6 simplifierai aussi le paramètrage de firewall grâce à l'identification de bout en bout de la chaine d'appel au niveau IP.
Bref, comme tout ceci n'exite pas, les protocols sur HTTP ont un avenir radieu ;-)