--
Dans ce ng, c'est du tout à l'avenant, bref du tout à l'ego
La police charge les bacheliers à coup de flashball à Paris:
http://www.rue89.com/2008/06/21/a-paris-la-fete-de-la-fin-du-bac-vire-a-la-bataille-rangee
Loi antipiratage, un an de tractations secrètes
http://www.lepoint.fr/actualites-medias/exclusif-loi-antipiratage-un-an-de-tractations-secretes/1253/0/254615
Remember Haditha
http://fr.news.yahoo.com/afp/20080617/twl-usa-irak-armee-proces-prev-ba734b9.html
http://www.rue89.com/2008/05/18/television-tant-de-cerveaux-disponibles
.... sachant qu'une solution technique consiste justement à modifier le DNS du www.mondomaine.com pour qu'il pointe sur un proxy-web du FAI diposant des bonnes règles de redirection
C'est une très mauvaise solution, ça casse les accès à la machine en HTTPS et avec tous les autres protocoles hors HTTP.
C'est vrai que sur ce proxy on ne gère pas tous les protocoles.
Seulement les plus usités tels que HTTP, PROXY-HTTP, DNS, SMTP, POP3, IMAP et quelques autres en proxy-transparent pour des besoins particuliers.
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy transparent ?
Garfield Le Chat a écrit :
.... sachant qu'une solution technique consiste justement à modifier
le DNS du www.mondomaine.com pour qu'il pointe sur un proxy-web du
FAI diposant des bonnes règles de redirection
C'est une très mauvaise solution, ça casse les accès à la machine en
HTTPS et avec tous les autres protocoles hors HTTP.
C'est vrai que sur ce proxy on ne gère pas tous les protocoles.
Seulement les plus usités tels que HTTP, PROXY-HTTP, DNS, SMTP, POP3,
IMAP et quelques autres en proxy-transparent pour des besoins particuliers.
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy
transparent ?
.... sachant qu'une solution technique consiste justement à modifier le DNS du www.mondomaine.com pour qu'il pointe sur un proxy-web du FAI diposant des bonnes règles de redirection
C'est une très mauvaise solution, ça casse les accès à la machine en HTTPS et avec tous les autres protocoles hors HTTP.
C'est vrai que sur ce proxy on ne gère pas tous les protocoles.
Seulement les plus usités tels que HTTP, PROXY-HTTP, DNS, SMTP, POP3, IMAP et quelques autres en proxy-transparent pour des besoins particuliers.
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy transparent ?
Garfield Le Chat
Pascal Hambourg a écrit :
Garfield Le Chat a écrit :
.... sachant qu'une solution technique consiste justement à modifier le DNS du www.mondomaine.com pour qu'il pointe sur un proxy-web du FAI diposant des bonnes règles de redirection
C'est une très mauvaise solution, ça casse les accès à la machine en HTTPS et avec tous les autres protocoles hors HTTP.
C'est vrai que sur ce proxy on ne gère pas tous les protocoles.
Seulement les plus usités tels que HTTP, PROXY-HTTP, DNS, SMTP, POP3, IMAP et quelques autres en proxy-transparent pour des besoins particuliers.
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy transparent ?
Comment ? de manière imparfaite. De facto, on arrive très bien à gérer les protocoles cités (DNS de manière particulière) mais on "perd" une donnée importante : l'adresse source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP publique qui a été attribuée au requêteur) et que nous sommes contraints de natter pour avoir un flux de routage symétrique.
Totalement inapproprié donc dans le cas où les accès aux services de www.mondomaine.com font l'objet d'une access-list.
Doit-on s'en préoccuper ?
Et plus j'en parle et plus je me demande si cette solution pour les entreprises peut être adaptée aux architectures et contraintes des FAI.
Garfield
Pascal Hambourg a écrit :
Garfield Le Chat a écrit :
.... sachant qu'une solution technique consiste justement à modifier
le DNS du www.mondomaine.com pour qu'il pointe sur un proxy-web du
FAI diposant des bonnes règles de redirection
C'est une très mauvaise solution, ça casse les accès à la machine en
HTTPS et avec tous les autres protocoles hors HTTP.
C'est vrai que sur ce proxy on ne gère pas tous les protocoles.
Seulement les plus usités tels que HTTP, PROXY-HTTP, DNS, SMTP, POP3,
IMAP et quelques autres en proxy-transparent pour des besoins
particuliers.
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy
transparent ?
Comment ? de manière imparfaite.
De facto, on arrive très bien à gérer les protocoles cités (DNS de
manière particulière) mais on "perd" une donnée importante : l'adresse
source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP
publique qui a été attribuée au requêteur) et que nous sommes contraints
de natter pour avoir un flux de routage symétrique.
Totalement inapproprié donc dans le cas où les accès aux services de
www.mondomaine.com font l'objet d'une access-list.
Doit-on s'en préoccuper ?
Et plus j'en parle et plus je me demande si cette solution pour les
entreprises peut être adaptée aux architectures et contraintes des FAI.
.... sachant qu'une solution technique consiste justement à modifier le DNS du www.mondomaine.com pour qu'il pointe sur un proxy-web du FAI diposant des bonnes règles de redirection
C'est une très mauvaise solution, ça casse les accès à la machine en HTTPS et avec tous les autres protocoles hors HTTP.
C'est vrai que sur ce proxy on ne gère pas tous les protocoles.
Seulement les plus usités tels que HTTP, PROXY-HTTP, DNS, SMTP, POP3, IMAP et quelques autres en proxy-transparent pour des besoins particuliers.
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy transparent ?
Comment ? de manière imparfaite. De facto, on arrive très bien à gérer les protocoles cités (DNS de manière particulière) mais on "perd" une donnée importante : l'adresse source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP publique qui a été attribuée au requêteur) et que nous sommes contraints de natter pour avoir un flux de routage symétrique.
Totalement inapproprié donc dans le cas où les accès aux services de www.mondomaine.com font l'objet d'une access-list.
Doit-on s'en préoccuper ?
Et plus j'en parle et plus je me demande si cette solution pour les entreprises peut être adaptée aux architectures et contraintes des FAI.
Garfield
Pascal Hambourg
Garfield Le Chat a écrit :
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy transparent ?
Comment ? de manière imparfaite. De facto, on arrive très bien à gérer les protocoles cités (DNS de manière particulière) mais on "perd" une donnée importante : l'adresse source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP publique qui a été attribuée au requêteur) et que nous sommes contraints de natter pour avoir un flux de routage symétrique.
On perd une donnée encore plus importante que l'adresse source : l'adresse de destination "originale" qu'aurait fournie le serveur DNS en l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en passer grâce au champ "Host" dans l'en-tête de la requête qui contient le nom du site cible, mais comment fais-il pour la retrouver avec les autres protocoles ? A moins de définir une adresse IP de proxy différente par nom de domaine filtré, je ne vois pas.
On n'est pas dans le cas où le proxy est en coupure sur le réseau et peut connaître l'adresse IP de destination originale avant redirection.
Garfield Le Chat a écrit :
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy
transparent ?
Comment ? de manière imparfaite.
De facto, on arrive très bien à gérer les protocoles cités (DNS de
manière particulière) mais on "perd" une donnée importante : l'adresse
source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP
publique qui a été attribuée au requêteur) et que nous sommes contraints
de natter pour avoir un flux de routage symétrique.
On perd une donnée encore plus importante que l'adresse source :
l'adresse de destination "originale" qu'aurait fournie le serveur DNS en
l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en passer
grâce au champ "Host" dans l'en-tête de la requête qui contient le nom
du site cible, mais comment fais-il pour la retrouver avec les autres
protocoles ? A moins de définir une adresse IP de proxy différente par
nom de domaine filtré, je ne vois pas.
On n'est pas dans le cas où le proxy est en coupure sur le réseau et
peut connaître l'adresse IP de destination originale avant redirection.
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy transparent ?
Comment ? de manière imparfaite. De facto, on arrive très bien à gérer les protocoles cités (DNS de manière particulière) mais on "perd" une donnée importante : l'adresse source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP publique qui a été attribuée au requêteur) et que nous sommes contraints de natter pour avoir un flux de routage symétrique.
On perd une donnée encore plus importante que l'adresse source : l'adresse de destination "originale" qu'aurait fournie le serveur DNS en l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en passer grâce au champ "Host" dans l'en-tête de la requête qui contient le nom du site cible, mais comment fais-il pour la retrouver avec les autres protocoles ? A moins de définir une adresse IP de proxy différente par nom de domaine filtré, je ne vois pas.
On n'est pas dans le cas où le proxy est en coupure sur le réseau et peut connaître l'adresse IP de destination originale avant redirection.
Garfield Le Chat
Pascal Hambourg a écrit :
Garfield Le Chat a écrit :
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy transparent ?
Comment ? de manière imparfaite. De facto, on arrive très bien à gérer les protocoles cités (DNS de manière particulière) mais on "perd" une donnée importante : l'adresse source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP publique qui a été attribuée au requêteur) et que nous sommes contraints de natter pour avoir un flux de routage symétrique.
On perd une donnée encore plus importante que l'adresse source : l'adresse de destination "originale" qu'aurait fournie le serveur DNS en l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en passer grâce au champ "Host" dans l'en-tête de la requête qui contient le nom du site cible, mais comment fais-il pour la retrouver avec les autres protocoles ? A moins de définir une adresse IP de proxy différente par nom de domaine filtré, je ne vois pas.
On n'est pas dans le cas où le proxy est en coupure sur le réseau et peut connaître l'adresse IP de destination originale avant redirection.
Effectivement, une adresse IP privée par destination déroutée (le système fonctionne en IPV4 uniquement sur notre site) et c'est le service DNS qui indique pour chaque adresse IP Privée le IN PTR correspondant au nom DNS initialement dérouté, pour simplifier la programmation des proxys.
Par contre l'adresse source, elle, est définitivement "perdue" (c.à.d. inconnue du destinataire) car elle est remplacée par l'adresse nat publique du proxy.
Garfield
Pascal Hambourg a écrit :
Garfield Le Chat a écrit :
Hmm, comment tu prends en charge autre chose que HTTP sur un tel
proxy transparent ?
Comment ? de manière imparfaite.
De facto, on arrive très bien à gérer les protocoles cités (DNS de
manière particulière) mais on "perd" une donnée importante : l'adresse
source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP
publique qui a été attribuée au requêteur) et que nous sommes
contraints de natter pour avoir un flux de routage symétrique.
On perd une donnée encore plus importante que l'adresse source :
l'adresse de destination "originale" qu'aurait fournie le serveur DNS en
l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en passer
grâce au champ "Host" dans l'en-tête de la requête qui contient le nom
du site cible, mais comment fais-il pour la retrouver avec les autres
protocoles ? A moins de définir une adresse IP de proxy différente par
nom de domaine filtré, je ne vois pas.
On n'est pas dans le cas où le proxy est en coupure sur le réseau et
peut connaître l'adresse IP de destination originale avant redirection.
Effectivement, une adresse IP privée par destination déroutée (le
système fonctionne en IPV4 uniquement sur notre site) et c'est le
service DNS qui indique pour chaque adresse IP Privée le IN PTR
correspondant au nom DNS initialement dérouté, pour simplifier la
programmation des proxys.
Par contre l'adresse source, elle, est définitivement "perdue" (c.à.d.
inconnue du destinataire) car elle est remplacée par l'adresse nat
publique du proxy.
Hmm, comment tu prends en charge autre chose que HTTP sur un tel proxy transparent ?
Comment ? de manière imparfaite. De facto, on arrive très bien à gérer les protocoles cités (DNS de manière particulière) mais on "perd" une donnée importante : l'adresse source (je parle, dans le cas d'un opérateur FAI, de l'adresse IP publique qui a été attribuée au requêteur) et que nous sommes contraints de natter pour avoir un flux de routage symétrique.
On perd une donnée encore plus importante que l'adresse source : l'adresse de destination "originale" qu'aurait fournie le serveur DNS en l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en passer grâce au champ "Host" dans l'en-tête de la requête qui contient le nom du site cible, mais comment fais-il pour la retrouver avec les autres protocoles ? A moins de définir une adresse IP de proxy différente par nom de domaine filtré, je ne vois pas.
On n'est pas dans le cas où le proxy est en coupure sur le réseau et peut connaître l'adresse IP de destination originale avant redirection.
Effectivement, une adresse IP privée par destination déroutée (le système fonctionne en IPV4 uniquement sur notre site) et c'est le service DNS qui indique pour chaque adresse IP Privée le IN PTR correspondant au nom DNS initialement dérouté, pour simplifier la programmation des proxys.
Par contre l'adresse source, elle, est définitivement "perdue" (c.à.d. inconnue du destinataire) car elle est remplacée par l'adresse nat publique du proxy.
Garfield
Pascal Hambourg
Garfield Le Chat a écrit :
Pascal Hambourg a écrit :
On perd une donnée encore plus importante que l'adresse source : l'adresse de destination "originale" qu'aurait fournie le serveur DNS en l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en passer grâce au champ "Host" dans l'en-tête de la requête qui contient le nom du site cible, mais comment fais-il pour la retrouver avec les autres protocoles ? A moins de définir une adresse IP de proxy différente par nom de domaine filtré, je ne vois pas.
Effectivement, une adresse IP privée par destination déroutée (le système fonctionne en IPV4 uniquement sur notre site) et c'est le service DNS qui indique pour chaque adresse IP Privée le IN PTR correspondant au nom DNS initialement dérouté, pour simplifier la programmation des proxys.
L'emploi d'adresses privées pour cette fonction est inenvisageable chez un FAI, il devrait donc sacrifier des adresses publiques. Reste le problème du HTTPS, qu'on n'est pas censé pouvoir détourner sans que ça se voie.
Garfield Le Chat a écrit :
Pascal Hambourg a écrit :
On perd une donnée encore plus importante que l'adresse source :
l'adresse de destination "originale" qu'aurait fournie le serveur DNS
en l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en
passer grâce au champ "Host" dans l'en-tête de la requête qui contient
le nom du site cible, mais comment fais-il pour la retrouver avec les
autres protocoles ? A moins de définir une adresse IP de proxy
différente par nom de domaine filtré, je ne vois pas.
Effectivement, une adresse IP privée par destination déroutée (le
système fonctionne en IPV4 uniquement sur notre site) et c'est le
service DNS qui indique pour chaque adresse IP Privée le IN PTR
correspondant au nom DNS initialement dérouté, pour simplifier la
programmation des proxys.
L'emploi d'adresses privées pour cette fonction est inenvisageable chez
un FAI, il devrait donc sacrifier des adresses publiques.
Reste le problème du HTTPS, qu'on n'est pas censé pouvoir détourner sans
que ça se voie.
On perd une donnée encore plus importante que l'adresse source : l'adresse de destination "originale" qu'aurait fournie le serveur DNS en l'absence de filtrage. En HTTP 1.1 le proxy transparent peut s'en passer grâce au champ "Host" dans l'en-tête de la requête qui contient le nom du site cible, mais comment fais-il pour la retrouver avec les autres protocoles ? A moins de définir une adresse IP de proxy différente par nom de domaine filtré, je ne vois pas.
Effectivement, une adresse IP privée par destination déroutée (le système fonctionne en IPV4 uniquement sur notre site) et c'est le service DNS qui indique pour chaque adresse IP Privée le IN PTR correspondant au nom DNS initialement dérouté, pour simplifier la programmation des proxys.
L'emploi d'adresses privées pour cette fonction est inenvisageable chez un FAI, il devrait donc sacrifier des adresses publiques. Reste le problème du HTTPS, qu'on n'est pas censé pouvoir détourner sans que ça se voie.
Garfield Le Chat
Pascal Hambourg a écrit :
L'emploi d'adresses privées pour cette fonction est inenvisageable chez un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI. Soit le flux est prohibé et il s'arrête au niveau du proxy. Soit il est autorisé et dans ce cas le flux repart du proxy pour aller vers l'adresse IP publique du serveur internet correspondant à l'adresse IP privé (comme dans le cas d'un NAT).
Reste le problème du HTTPS, qu'on n'est pas censé pouvoir détourner sans que ça se voie.
Le problème du HTTPS n'est pas tant que le flux passe ou non par le proxy, mais plutôt que nous sommes dans l'incapacité de "voir" au niveau du proxy ce que qui transite par ce flux (chiffrement par clef de session de bout en bout => man in the middle is "blind").
Quelle solution technique dans ce cas pour faire du filtrage "sélectif" d'url en HTTPS ?
Garfield
Pascal Hambourg a écrit :
L'emploi d'adresses privées pour cette fonction est inenvisageable chez
un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI.
Soit le flux est prohibé et il s'arrête au niveau du proxy.
Soit il est autorisé et dans ce cas le flux repart du proxy pour aller
vers l'adresse IP publique du serveur internet correspondant à l'adresse
IP privé (comme dans le cas d'un NAT).
Reste le problème du HTTPS, qu'on n'est pas censé pouvoir détourner sans
que ça se voie.
Le problème du HTTPS n'est pas tant que le flux passe ou non par le
proxy, mais plutôt que nous sommes dans l'incapacité de "voir" au niveau
du proxy ce que qui transite par ce flux (chiffrement par clef de
session de bout en bout => man in the middle is "blind").
Quelle solution technique dans ce cas pour faire du filtrage "sélectif"
d'url en HTTPS ?
L'emploi d'adresses privées pour cette fonction est inenvisageable chez un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI. Soit le flux est prohibé et il s'arrête au niveau du proxy. Soit il est autorisé et dans ce cas le flux repart du proxy pour aller vers l'adresse IP publique du serveur internet correspondant à l'adresse IP privé (comme dans le cas d'un NAT).
Reste le problème du HTTPS, qu'on n'est pas censé pouvoir détourner sans que ça se voie.
Le problème du HTTPS n'est pas tant que le flux passe ou non par le proxy, mais plutôt que nous sommes dans l'incapacité de "voir" au niveau du proxy ce que qui transite par ce flux (chiffrement par clef de session de bout en bout => man in the middle is "blind").
Quelle solution technique dans ce cas pour faire du filtrage "sélectif" d'url en HTTPS ?
Garfield
Pascal Hambourg
Garfield Le Chat a écrit :
Pascal Hambourg a écrit :
L'emploi d'adresses privées pour cette fonction est inenvisageable chez un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI.
Il y a juste un léger défaut : c'est déconseillé - à raison - par les RFC, et si le client utilise déjà la même plage privée chez lui (il a le droit), ou bloque le trafic avec l'extérieur portant sur des adresses privées, ou bloque les réponses DNS contenant des adresses privées (c'est recommandé par les RFC), ça va beaucoup moins bien marcher. En bref c'est applicable dans un réseau d'entreprise où une entité contrôle tout, pas dans un environnement public où le FAI et le client sont deux entités distinctes.
Quelle solution technique dans ce cas pour faire du filtrage "sélectif" d'url en HTTPS ?
Mon idée est que ce n'est pas censé être possible par définition, car l'URL peut contenir des informations sensibles.
Garfield Le Chat a écrit :
Pascal Hambourg a écrit :
L'emploi d'adresses privées pour cette fonction est inenvisageable
chez un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI.
Il y a juste un léger défaut : c'est déconseillé - à raison - par les
RFC, et si le client utilise déjà la même plage privée chez lui (il a le
droit), ou bloque le trafic avec l'extérieur portant sur des adresses
privées, ou bloque les réponses DNS contenant des adresses privées
(c'est recommandé par les RFC), ça va beaucoup moins bien marcher. En
bref c'est applicable dans un réseau d'entreprise où une entité contrôle
tout, pas dans un environnement public où le FAI et le client sont deux
entités distinctes.
Quelle solution technique dans ce cas pour faire du filtrage "sélectif"
d'url en HTTPS ?
Mon idée est que ce n'est pas censé être possible par définition, car
l'URL peut contenir des informations sensibles.
L'emploi d'adresses privées pour cette fonction est inenvisageable chez un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI.
Il y a juste un léger défaut : c'est déconseillé - à raison - par les RFC, et si le client utilise déjà la même plage privée chez lui (il a le droit), ou bloque le trafic avec l'extérieur portant sur des adresses privées, ou bloque les réponses DNS contenant des adresses privées (c'est recommandé par les RFC), ça va beaucoup moins bien marcher. En bref c'est applicable dans un réseau d'entreprise où une entité contrôle tout, pas dans un environnement public où le FAI et le client sont deux entités distinctes.
Quelle solution technique dans ce cas pour faire du filtrage "sélectif" d'url en HTTPS ?
Mon idée est que ce n'est pas censé être possible par définition, car l'URL peut contenir des informations sensibles.
Garfield Le Chat
Pascal Hambourg a écrit :
Garfield Le Chat a écrit :
Pascal Hambourg a écrit :
L'emploi d'adresses privées pour cette fonction est inenvisageable chez un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI.
Il y a juste un léger défaut : c'est déconseillé - à raison - par les RFC, et si le client utilise déjà la même plage privée chez lui (il a le droit), ou bloque le trafic avec l'extérieur portant sur des adresses privées, ou bloque les réponses DNS contenant des adresses privées (c'est recommandé par les RFC), ça va beaucoup moins bien marcher. En bref c'est applicable dans un réseau d'entreprise où une entité contrôle tout, pas dans un environnement public où le FAI et le client sont deux entités distinctes.
Dans la pratique les FAI Grand Public que je connais utilisent des plages d'adresses privées (parfois en quantité) et s'arrange juste pour ne pas faire de recouvrement entre les adresses utilisées pour leurs besoins internes et les adresses attribuées aux clients.
et les deux mondes ne sont pas aussi cloisonnés que l'on pourrait l'espérer.
Mais là du coup, effectivement, les RFCs condamnent et à juste titre. Exit donc les adresses privées qui devront être remplacées par un pool d'adresses IP publiques ....
Quelle solution technique dans ce cas pour faire du filtrage "sélectif" d'url en HTTPS ?
Mon idée est que ce n'est pas censé être possible par définition, car l'URL peut contenir des informations sensibles.
C'est aussi mon avis.
Garfield
Pascal Hambourg a écrit :
Garfield Le Chat a écrit :
Pascal Hambourg a écrit :
L'emploi d'adresses privées pour cette fonction est inenvisageable
chez un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI.
Il y a juste un léger défaut : c'est déconseillé - à raison - par les
RFC, et si le client utilise déjà la même plage privée chez lui (il a le
droit), ou bloque le trafic avec l'extérieur portant sur des adresses
privées, ou bloque les réponses DNS contenant des adresses privées
(c'est recommandé par les RFC), ça va beaucoup moins bien marcher. En
bref c'est applicable dans un réseau d'entreprise où une entité contrôle
tout, pas dans un environnement public où le FAI et le client sont deux
entités distinctes.
Dans la pratique les FAI Grand Public que je connais utilisent des
plages d'adresses privées (parfois en quantité) et s'arrange juste pour
ne pas faire de recouvrement entre les adresses utilisées pour leurs
besoins internes et les adresses attribuées aux clients.
et les deux mondes ne sont pas aussi cloisonnés que l'on pourrait
l'espérer.
Mais là du coup, effectivement, les RFCs condamnent et à juste titre.
Exit donc les adresses privées qui devront être remplacées par un pool
d'adresses IP publiques ....
Quelle solution technique dans ce cas pour faire du filtrage
"sélectif" d'url en HTTPS ?
Mon idée est que ce n'est pas censé être possible par définition, car
l'URL peut contenir des informations sensibles.
L'emploi d'adresses privées pour cette fonction est inenvisageable chez un FAI, il devrait donc sacrifier des adresses publiques.
Si si, ce devrait pouvoir se faire. L'adresse pricée ne sort pas du FAI.
Il y a juste un léger défaut : c'est déconseillé - à raison - par les RFC, et si le client utilise déjà la même plage privée chez lui (il a le droit), ou bloque le trafic avec l'extérieur portant sur des adresses privées, ou bloque les réponses DNS contenant des adresses privées (c'est recommandé par les RFC), ça va beaucoup moins bien marcher. En bref c'est applicable dans un réseau d'entreprise où une entité contrôle tout, pas dans un environnement public où le FAI et le client sont deux entités distinctes.
Dans la pratique les FAI Grand Public que je connais utilisent des plages d'adresses privées (parfois en quantité) et s'arrange juste pour ne pas faire de recouvrement entre les adresses utilisées pour leurs besoins internes et les adresses attribuées aux clients.
et les deux mondes ne sont pas aussi cloisonnés que l'on pourrait l'espérer.
Mais là du coup, effectivement, les RFCs condamnent et à juste titre. Exit donc les adresses privées qui devront être remplacées par un pool d'adresses IP publiques ....
Quelle solution technique dans ce cas pour faire du filtrage "sélectif" d'url en HTTPS ?
Mon idée est que ce n'est pas censé être possible par définition, car l'URL peut contenir des informations sensibles.
C'est aussi mon avis.
Garfield
Pascal Hambourg
Garfield Le Chat a écrit :
Dans la pratique les FAI Grand Public que je connais utilisent des plages d'adresses privées (parfois en quantité) et s'arrange juste pour ne pas faire de recouvrement entre les adresses utilisées pour leurs besoins internes et les adresses attribuées aux clients.
Les adresses attribuées aux clients sont des adresses publiques, et le FAI n'a pas de contrôle sur les plages d'adresses privées que les clients peuvent utiliser par ailleurs sur leurs réseaux locaux, puisque justement c'est privé.
Garfield Le Chat a écrit :
Dans la pratique les FAI Grand Public que je connais utilisent des
plages d'adresses privées (parfois en quantité) et s'arrange juste pour
ne pas faire de recouvrement entre les adresses utilisées pour leurs
besoins internes et les adresses attribuées aux clients.
Les adresses attribuées aux clients sont des adresses publiques, et le
FAI n'a pas de contrôle sur les plages d'adresses privées que les
clients peuvent utiliser par ailleurs sur leurs réseaux locaux, puisque
justement c'est privé.
Dans la pratique les FAI Grand Public que je connais utilisent des plages d'adresses privées (parfois en quantité) et s'arrange juste pour ne pas faire de recouvrement entre les adresses utilisées pour leurs besoins internes et les adresses attribuées aux clients.
Les adresses attribuées aux clients sont des adresses publiques, et le FAI n'a pas de contrôle sur les plages d'adresses privées que les clients peuvent utiliser par ailleurs sur leurs réseaux locaux, puisque justement c'est privé.
Garfield Le Chat
Pascal Hambourg a écrit :
Garfield Le Chat a écrit :
Dans la pratique les FAI Grand Public que je connais utilisent des plages d'adresses privées (parfois en quantité) et s'arrange juste pour ne pas faire de recouvrement entre les adresses utilisées pour leurs besoins internes et les adresses attribuées aux clients.
Les adresses attribuées aux clients sont des adresses publiques, et le FAI n'a pas de contrôle sur les plages d'adresses privées que les clients peuvent utiliser par ailleurs sur leurs réseaux locaux, puisque justement c'est privé.
Le FAI "Grand Public" attribue une adresse IP publique et propose un paramétrage (et encore pas toujours) de la plage d'adressage privé utilisable par le client (par exemple 192.168.X.0/24 pour l'opérateur Free sur ses freebox).
S'il est toujours loisir au client d'utiliser des adresses privées en 10.0.x.y par exemple, il peut toujours (il fait ce qu'il veut sur son réseau local), mais dans ce cas à charge pour lui d'encapsuler (VPN par exemple, ou NAT en 192.168.x.0/24) cette adresse IP source avant qu'elle ne transite par la bobox à destination du réseau WAN.
Je ne crois pas (par exemple) que la livebox effectue un NAT automatique (sur l'adresse publique attribuée) des paquets IP émis depuis une adresse IP qui ne fait pas partie du pool privé configuré pour cette livebox.
Et (par ailleurs, pour ce qui concerne la notion "d'étanchéité") je serais curieux de connaitre les adresses IP utilisés sur les canaux TV et VoIP des livebox et les régles de routage (quand flux non bridgés) associés, sur la bobox.
On peut par contre s'attendre à plus de rigueur pour les FAI orientés "Entreprises" et non "Grand Public", parce que leurs clients ont plus de besoins dans ce domaine.
Garfield
Pascal Hambourg a écrit :
Garfield Le Chat a écrit :
Dans la pratique les FAI Grand Public que je connais utilisent des
plages d'adresses privées (parfois en quantité) et s'arrange juste
pour ne pas faire de recouvrement entre les adresses utilisées pour
leurs besoins internes et les adresses attribuées aux clients.
Les adresses attribuées aux clients sont des adresses publiques, et le
FAI n'a pas de contrôle sur les plages d'adresses privées que les
clients peuvent utiliser par ailleurs sur leurs réseaux locaux, puisque
justement c'est privé.
Le FAI "Grand Public" attribue une adresse IP publique et propose un
paramétrage (et encore pas toujours) de la plage d'adressage privé
utilisable par le client (par exemple 192.168.X.0/24 pour l'opérateur
Free sur ses freebox).
S'il est toujours loisir au client d'utiliser des adresses privées en
10.0.x.y par exemple, il peut toujours (il fait ce qu'il veut sur son
réseau local), mais dans ce cas à charge pour lui d'encapsuler (VPN par
exemple, ou NAT en 192.168.x.0/24) cette adresse IP source avant qu'elle
ne transite par la bobox à destination du réseau WAN.
Je ne crois pas (par exemple) que la livebox effectue un NAT automatique
(sur l'adresse publique attribuée) des paquets IP émis depuis une
adresse IP qui ne fait pas partie du pool privé configuré pour cette
livebox.
Et (par ailleurs, pour ce qui concerne la notion "d'étanchéité") je
serais curieux de connaitre les adresses IP utilisés sur les canaux TV
et VoIP des livebox et les régles de routage (quand flux non bridgés)
associés, sur la bobox.
On peut par contre s'attendre à plus de rigueur pour les FAI orientés
"Entreprises" et non "Grand Public", parce que leurs clients ont plus de
besoins dans ce domaine.
Dans la pratique les FAI Grand Public que je connais utilisent des plages d'adresses privées (parfois en quantité) et s'arrange juste pour ne pas faire de recouvrement entre les adresses utilisées pour leurs besoins internes et les adresses attribuées aux clients.
Les adresses attribuées aux clients sont des adresses publiques, et le FAI n'a pas de contrôle sur les plages d'adresses privées que les clients peuvent utiliser par ailleurs sur leurs réseaux locaux, puisque justement c'est privé.
Le FAI "Grand Public" attribue une adresse IP publique et propose un paramétrage (et encore pas toujours) de la plage d'adressage privé utilisable par le client (par exemple 192.168.X.0/24 pour l'opérateur Free sur ses freebox).
S'il est toujours loisir au client d'utiliser des adresses privées en 10.0.x.y par exemple, il peut toujours (il fait ce qu'il veut sur son réseau local), mais dans ce cas à charge pour lui d'encapsuler (VPN par exemple, ou NAT en 192.168.x.0/24) cette adresse IP source avant qu'elle ne transite par la bobox à destination du réseau WAN.
Je ne crois pas (par exemple) que la livebox effectue un NAT automatique (sur l'adresse publique attribuée) des paquets IP émis depuis une adresse IP qui ne fait pas partie du pool privé configuré pour cette livebox.
Et (par ailleurs, pour ce qui concerne la notion "d'étanchéité") je serais curieux de connaitre les adresses IP utilisés sur les canaux TV et VoIP des livebox et les régles de routage (quand flux non bridgés) associés, sur la bobox.
On peut par contre s'attendre à plus de rigueur pour les FAI orientés "Entreprises" et non "Grand Public", parce que leurs clients ont plus de besoins dans ce domaine.
