L'analyse touche à sa fin. J'ai finalement réussi à regarder le flux à
l'entrée de notre réseau, les headers étaient déjà bien manquants en
arrivant.
Il semblerait, aussi surprenant que cela puisse paraître, que FF dans
certains cas semble n'envoyer qu'une partie des headers (!!??!!). On
n'est pas
Il est possible que certains outils suppriment une partie des headers
considérés comme "en trop" :)
donc de temps en temps, la requete a pas trop de headers donc ton
header reste, et de temps en temps y'en a de trop alors on vire les
derniers. Et HOP. Varnish fait ça dans sa config par defaut par
e
On 27/04/2011 11:37, Valentin Surrel wrote:
Afin de pister un bug bien velu,
Bon ça y est, c'est isolé !
Chaque requête POST envoit un header X-CSRFToken (via le framework
utilisé) et nos serveurs d'applis sont configurés pour invalider la
session si le X-CSRFToken est manquant/faux. En l'oc
On 28/04/2011 13:56, Valentin Surrel wrote:
> Le 28/04/2011 11:19, Valentin Surrel a écrit :
>> Je vais essayer sur un autre PC... #Dream
>
> Ca y est, j'ai réussi avec le Sample fourni par wireshark sur un autre
> PC. Mais ma trace est toujours KO par contre.
>
> Mon certificat est un Gandi Pro,
Le 28/04/2011 11:19, Valentin Surrel a écrit :
> Je vais essayer sur un autre PC... #Dream
Ca y est, j'ai réussi avec le Sample fourni par wireshark sur un autre
PC. Mais ma trace est toujours KO par contre.
Mon certificat est un Gandi Pro, avec autorité intermédiaire. Est ce que
cela pourrait ex
Bonjour,
C'est nginx qui fait le SSL et le RP. Je tourne pour tous mes tests à un
seul serveur d'application, donc pas de soucis dans le load balancing,
tout le monde arrive sur le même serveur actuellement :)
Je vais regarder un peu Charles.
Valentin
Le 28/04/2011 10:22, J. Mardas a écrit :
>
regarde mon poste et essaie charles proxy :)
Le 28 avril 2011 11:19, Valentin Surrel a écrit :
> Le 28/04/2011 10:46, Valentin Surrel a écrit :
> > On va arriver à ça si j'arrive pas à m'en sortir avec Wireshark :)
> > Mais j'aimais bien la possibilité d'écouter au niveau de mon point de
> > so
Le 28/04/2011 10:46, Valentin Surrel a écrit :
> On va arriver à ça si j'arrive pas à m'en sortir avec Wireshark :)
> Mais j'aimais bien la possibilité d'écouter au niveau de mon point de
> sortie sur Internet afin de voir directement le problème.
Bon, même le SampleCapture sur http://wiki.wiresha
Le 27/04/2011 21:59, Jean Baptiste FAVRE a écrit :
> Je suppose que le cookie (de session ?) est généré (et donc géré) par
> le(s) serveur(s) applicatif(s) et non par le reverse ?
Tout à fait.
> 1. Est-il envisageable de faire sauter le SSL entre le reverse et le
> serveur applicatif ? Ce qui sim
Bonjour,
j'ajouterai à cela de vérifier que :
- le RP ne mets pas en cache des pages contenant un set-cookie (vérifier
les etag, cache-control, pragma, expire & co le cas échéant supprimer ces
entêtes).
- le critère de load balacing en amont effectivement l'IP source parfois
même le port source
2011/4/27 Jean Baptiste FAVRE :
> +1, j'avais pas pensé à celle-là tient ;)
> M'enfin, bloquer la session sur 1 IP (avec le roaming 3G toussa), faut
> être... enfin bon, bref :p
C'est encore une option dans certains forum (check ip ou comment
s'emmêler les couches OSI :) )...
>
> JB
>
>
> On 27/
On 27/04/2011 23:29, Steven Le Roux wrote:
Pour rebondir là dessus, même si leur proxy est niquel, puisque vous
récupéré l'ip par laquelle il vient, (X-REAL-IP), est-ce que ce n'est
pas votre serveur applicatif qui casse la session si l'ip change au
cours de la session ? Ces utilisateurs sont peu
On 28/04/2011 09:07, Hervé COMMOWICK wrote:
Et bien entendu, les pirates de l'Internet ne sont pas capable de
modifier le header X-Real-IP alors qu'ils sont capable de le faire pour
le X-Forwarded-For ? La seule manière pour ce genre de header est de le
supprimer si il existe avant d'insérer le s
On Wed, 27 Apr 2011 12:14:14 +0200
Valentin Surrel wrote:
> Pour la petite histoire du X-Forwarded-For, c'est pas toujours idéal
> parce qu'il est trafiqué à chaque étage des reverse-proxy et chacun
> rajoute sa merde (entre autre les proxys de sorties des grosses
> entreprises), notre frontal aj
+1, j'avais pas pensé à celle-là tient ;)
M'enfin, bloquer la session sur 1 IP (avec le roaming 3G toussa), faut
être... enfin bon, bref :p
JB
On 27/04/2011 23:29, Steven Le Roux wrote:
> 2011/4/27 Jean Baptiste FAVRE :
>> Bonsoir,
>>
>> On 27/04/2011 11:37, Valentin Surrel wrote:
>>> Bonjour la
2011/4/27 Jean Baptiste FAVRE :
> Bonsoir,
>
> On 27/04/2011 11:37, Valentin Surrel wrote:
>> Bonjour la liste,
>>
>> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau
>> entre un client et nous. Problème, on a un frontal qui fait du SSL et
>> rajoute un X-Real-IP header avant
Bonsoir,
On 27/04/2011 11:37, Valentin Surrel wrote:
> Bonjour la liste,
>
> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau
> entre un client et nous. Problème, on a un frontal qui fait du SSL et
> rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs
> d'app
Le 27/04/2011 11:47, Yohann Lepage a écrit :
> Oui :
> - http://wiki.wireshark.org/SSL
> - http://htluo.blogspot.com/2009/01/decrypt-https-traffic-with-wireshark.html
> - http://blogs.sun.com/beuchelt/entry/decrypting_ssl_traffic_with_wireshark
J'essaye actuellement cete piste, pour l'instant ca
Non je suis bien sur qu'il n'y a aucune indispo backend (d'autant plus
que ca n'arrive toujours qu'aux deux même clients et que pendant ce
temps là les autres clients n'ont aucun soucis).
Je vais préparer le tcpdump du ssl et attendre que les deux clients
problématiques se reconnectent.
Le 27/04/
Il y n'y a pas un nofailover à off (conf apache) en cas de non dispo
d'un backend ? (ce qui casserait effectivement volontairement la
session)
Ne vois-tu pas d'indipo des backend dans les logs ?
2011/4/27 Valentin Surrel :
> Le 27/04/2011 12:11, Steven Le Roux a écrit :
>> Je pense à un autre p
Le 27/04/2011 12:11, Steven Le Roux a écrit :
> Je pense à un autre point, avec un peu de chance, il y a un cookie
> dans l'histoire qui permette de suivre la session... ?
Oui et justement je cherche à trouver s'il est bien tout le temps là et
quel est son contenu.
Deux clients (utilisant les deux Firefox 3.6.16 ; un sous Mac un sous
Win) "perdent" leur session chez nous très régulièrement (au bout de
quelques requêtes, à moins de quelques secondes du login). Jamais sur le
même appel, cela semble relativement aléatoire.
Je cherche donc déjà à tracer tout les
Je pense à un autre point, avec un peu de chance, il y a un cookie
dans l'histoire qui permette de suivre la session... ?
2011/4/27 Valentin Surrel :
> Bonjour la liste,
>
> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau
> entre un client et nous. Problème, on a un frontal
A grand coup de tshark, tu dois pouvoir filtrer ca correctement :
http://www.wireshark.org/docs/dfref/h/http.html
Par contre il te faudra sans doute modifier le nom du header pour le
standard de facto X-Forwarded-For, car je ne vois pas comment le
spécifier autrement.
C'est quoi le bug bien velu
Si tu as la main sur le client, tu peux voir la réponse avec des
plugin comme live http headers pour firefox ou le bookmarklet headers
pour chrome.
Maintenant, si tu sais que l'IP du client est 1.2.3.4, tu peux filtrer dessus...
tcpdump -A -s2048 host 1.2.3.4 devrait te montrer les headers renvoyé
Valentin,
Le 27 avril 2011 11:37, Valentin Surrel a écrit :
> Bonjour la liste,
>
> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau
> entre un client et nous. Problème, on a un frontal qui fait du SSL et
> rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs
Le 27 avril 2011 11:37, Valentin Surrel a écrit :
> Bonjour la liste,
Salut,
> Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4
> et ensuite de décoder le HTTPS ? (avec wireshark ?)
Oui :
- http://wiki.wireshark.org/SSL
- http://htluo.blogspot.com/2009/01/decrypt-https-tra
27 matches
Mail list logo
