Aller au contenu
  • Pas encore inscrit ?

    Pourquoi ne pas vous inscrire ? C'est simple, rapide et gratuit.
    Pour en savoir plus, lisez Les avantages de l'inscription... et la Charte de Zébulon.
    De plus, les messages que vous postez en tant qu'invité restent invisibles tant qu'un modérateur ne les a pas validés. Inscrivez-vous, ce sera un gain de temps pour tout le monde, vous, les helpeurs et les modérateurs ! :wink:

Messages recommandés

Posté(e)
Lorsque tu surfes, le navigateur envoie ses requêtes par le port 80 ( et 53 ), et la réponse également s'effectue par le port 80
Attention, les données sont "échangées" sur le lien que tu as établi entre toi et le port 80 du serveur : il n'y a pas de nouvel établissement de connexion entre le serveur et toi (ni sur le port 80 de ta machine ni ailleurs). Si c'est pour ça que tu réfutais "pas dans le même sens" je comprends mieux.

Ce dont il était question, c'était en rapport avec un blocage des trames entrantes à destination du port 80. Dans ce cadre-là on considérait qu'une connexion "entrante" à destination du port 80 (d'une machine distante vers le port 80 de ta machine) et une connexion "sortante" à destination du port 80 (de ta machine vers le port 80 d'un serveur web distant) ce n'était pas "le même sens".

Certes, il y a des données échangées dans les deux sens sur la connexion "ta machine vers port 80 du serveur" mais lors de la communication il n'y a aucune information qui part du serveur à destination du port 80 de ta machine.

 

Et inversement lorsque tu as un serveur Web sur ta machine et qu'une machine extérieure tente d'y accéder.

 

Donc, bloquer les trames entrantes qui ont comme port de destination le port 80 ne va pas impacter le comportement de ton navigateur Web.

 

Au passage, les requêtes vers le port 53 c'est à destination des serveurs DNS.

Posté(e)
Attention, les données sont "échangées" sur le lien que tu as établi entre toi et le port 80 du serveur : il n'y a pas de nouvel établissement de connexion entre le serveur et toi (ni sur le port 80 de ta machine ni ailleurs). Si c'est pour ça que tu réfutais "pas dans le même sens" je comprends mieux.

Ce dont il était question, c'était en rapport avec un blocage des trames entrantes à destination du port 80. Dans ce cadre-là on considérait qu'une connexion "entrante" à destination du port 80 (d'une machine distante vers le port 80 de ta machine) et une connexion "sortante" à destination du port 80 (de ta machine vers le port 80 d'un serveur web distant) ce n'était pas "le même sens".

Certes, il y a des données échangées dans les deux sens sur la connexion "ta machine vers port 80 du serveur" mais lors de la communication il n'y a aucune information qui part du serveur à destination du port 80 de ta machine.

 

Et inversement lorsque tu as un serveur Web sur ta machine et qu'une machine extérieure tente d'y accéder.

 

Donc, bloquer les trames entrantes qui ont comme port de destination le port 80 ne va pas impacter le comportement de ton navigateur Web.

 

Au passage, les requêtes vers le port 53 c'est à destination des serveurs DNS.

 

pour le port 53, je sais.

 

mais les "demandes" se font bien par le port 80, non ? ( juste les demandes, donc une établissement d'une connection entre le serveur et le client )

 

++

Posté(e)

Oui, les demandes se font sur le port 80 mais je te rappelle qu'il y a deux ports dans une trame TCP : un port source et un port destination. Quand tu envoies une requête HTTP à un serveur web le "80" se trouve dans le port destination (à côte de l'adresse IP du serveur), pas dans le port source (à côte de l'adresse IP de ta machine).

http://en.wikipedia.org/wiki/Transmission_...tocol#TCP_ports

Posté(e)
Oui, les demandes se font sur le port 80 mais je te rappelle qu'il y a deux ports dans une trame TCP : un port source et un port destination. Quand tu envoies une requête HTTP à un serveur web le "80" se trouve dans le port destination (à côte de l'adresse IP du serveur), pas dans le port source (à côte de l'adresse IP de ta machine).

http://en.wikipedia.org/wiki/Transmission_...tocol#TCP_ports

 

ah oui, j'avais mal compris !

 

donc dans un cas le port 80 est "destination", et dans l'autre cas, il est "source".

Posté(e)
donc dans un cas le port 80 est "destination", et dans l'autre cas, il est "source".

 

oui, à peu près.

Dans le cas du port 80 en port source, c'est la trame TCP de réponse du serveur à la requête initiée par le client (source > 1024 et destination 80). Comme les pare-feux actuels font du suivi de session TCP (Stateful Packet Inspection = SPI), la réponse du serveur web est automatiquement acceptée par le pare-feu/routeur si elle appartient à une session TCP établie. (complexité n+1)

 

En aucun cas, un serveur web initiera une nouvelle connection TCP avec seul le drapeau SYN de positionné et comme port source 80.

 

Dans le cas (ancien) de pare-feux ne gérant pas les états TCP, il fallait en effet accepter explicitement les réponses (complexité 2n)

Posté(e)
oui, à peu près.

Dans le cas du port 80 en port source, c'est la trame TCP de réponse du serveur à la requête initiée par le client (source > 1024 et destination 80). Comme les pare-feux actuels font du suivi de session TCP (Stateful Packet Inspection = SPI), la réponse du serveur web est automatiquement acceptée par le pare-feu/routeur si elle appartient à une session TCP établie. (complexité n+1)

 

En aucun cas, un serveur web initiera une nouvelle connection TCP avec seul le drapeau SYN de positionné et comme port source 80.

 

Dans le cas (ancien) de pare-feux ne gérant pas les états TCP, il fallait en effet accepter explicitement les réponses (complexité 2n)

 

donc un client demande à un serveur web d'afficher des pages ( ou autres ) avec comme port source un port aléatoire supérieur a 1024, et comme port de destination le port 80, et le serveur lui répond avec source port 80 et destination un port aléatoire supérieur a 1024, c'est ça ?

Posté(e)

la réponse du serveur web se fait sur le port client qui a initié la connexion; la session complète HTTP se fait comme suit

client				 serveur
port x (> 1024) -> port 80
port x (> 1024) <- port 80

Posté(e)
la réponse du serveur web se fait sur le port client qui a initié la connexion; la session complète HTTP se fait comme suit

client				 serveur
port x (> 1024) -> port 80
port x (> 1024) <- port 80

 

donc j'avais juste, sauf que le port supérieur à 1024 est le même, j'avais donc oublié de dire ça.

 

Merci.

Posté(e)
O_o

En excluant tout ce qu'on a été obligé de te rappeler, tu veux dire ?

 

donc un client demande à un serveur web d'afficher des pages ( ou autres ) avec comme port source un port aléatoire supérieur a 1024, et comme port de destination le port 80, et le serveur lui répond avec source port 80 et destination un port aléatoire supérieur a 1024, c'est ça ?

 

j'avais juste, il ne me manquait qu'à dire même port supérieur a 1024 ! :P :P

Rejoindre la conversation

Vous publiez en tant qu’invité. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.
Remarque : votre message nécessitera l’approbation d’un modérateur avant de pouvoir être visible.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...