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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
Merci de votre aide !
Valentin
Le 27 avril 2011 11:37, Valentin Surrel valentin@surrel.org 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-traffic-with-wireshark.html - http://blogs.sun.com/beuchelt/entry/decrypting_ssl_traffic_with_wireshark
Le 27/04/2011 11:47, Yohann Lepage a écrit :
Oui :
J'essaye actuellement cete piste, pour l'instant ca n'arrive pas à décoder correctement le SSL. Alors que la clé privée est bien chargée.
Je regarde un peu plus en détail ; mais je ne comprends pas le "no decoder available" alors que j'ai bien indiqué dans les prefs SSL sur port 443 avec cette IP => http
FYI le debug log du decodage SSL :
ssl_init keys string: 188.165.227.167,443,http,/home/valentin/Bureau/private.key ssl_init found host entry 188.165.227.167,443,http,/home/valentin/Bureau/private.key ssl_init addr '188.165.227.167' port '443' filename '/home/valentin/Bureau/private.key' password(only for p12 file) '(null)' Private key imported: KeyID c1:d1:24:7e:61:14:2c:7e:ee:de:01:1f:81:e6:49:09:... ssl_init private key file /home/valentin/Bureau/private.key successfully loaded association_add TCP port 443 protocol http handle 0x7fdfd8e72c50
dissect_ssl enter frame #15 (first time) ssl_session_init: initializing ptr 0x7fdfba3e0028 size 672 conversation = 0x7fdfba3de8b8, ssl_session = 0x7fdfba3e0028 record: offset = 0, reported_length_remaining = 419 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 414, ssl state 0x00 association_find: TCP port 46731 found (nil) packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 410 bytes, remaining 419 packet_from_server: is from server - FALSE ssl_find_private_key server 188.165.227.167:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01
dissect_ssl enter frame #17 (first time) conversation = 0x7fdfba3de8b8, ssl_session = 0x7fdfba3e0028 record: offset = 0, reported_length_remaining = 1448 dissect_ssl3_record found version 0x0301 -> state 0x11 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 81, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13 dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39 record: offset = 86, reported_length_remaining = 1362 need_desegmentation: offset = 86, reported_length_remaining = 1362
dissect_ssl enter frame #18 (first time) conversation = 0x7fdfba3de8b8, ssl_session = 0x7fdfba3e0028 record: offset = 0, reported_length_remaining = 2759 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 2343, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 11 offset 5 length 2339 bytes, remaining 2348 record: offset = 2348, reported_length_remaining = 411 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 397, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 12 offset 2353 length 393 bytes, remaining 2750 record: offset = 2750, reported_length_remaining = 9 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 4, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 14 offset 2755 length 0 bytes, remaining 2759
dissect_ssl enter frame #20 (first time) ssl_session_init: initializing ptr 0x7fdfba3e0790 size 672 conversation = 0x7fdfba3dec50, ssl_session = 0x7fdfba3e0790 record: offset = 0, reported_length_remaining = 419 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 414, ssl state 0x00 association_find: TCP port 46732 found (nil) packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 410 bytes, remaining 419 packet_from_server: is from server - FALSE ssl_find_private_key server 188.165.227.167:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01
dissect_ssl enter frame #22 (first time) conversation = 0x7fdfba3dec50, ssl_session = 0x7fdfba3e0790 record: offset = 0, reported_length_remaining = 1448 dissect_ssl3_record found version 0x0301 -> state 0x11 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 81, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13 dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39 record: offset = 86, reported_length_remaining = 1362 need_desegmentation: offset = 86, reported_length_remaining = 1362
dissect_ssl enter frame #23 (first time) conversation = 0x7fdfba3dec50, ssl_session = 0x7fdfba3e0790 record: offset = 0, reported_length_remaining = 2759 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 2343, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 11 offset 5 length 2339 bytes, remaining 2348 record: offset = 2348, reported_length_remaining = 411 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 397, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 12 offset 2353 length 393 bytes, remaining 2750 record: offset = 2750, reported_length_remaining = 9 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 4, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 14 offset 2755 length 0 bytes, remaining 2759
dissect_ssl enter frame #24 (first time) ssl_session_init: initializing ptr 0x7fdfba3e0e18 size 672 conversation = 0x7fdfba3defe8, ssl_session = 0x7fdfba3e0e18 record: offset = 0, reported_length_remaining = 419 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 414, ssl state 0x00 association_find: TCP port 46733 found (nil) packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 410 bytes, remaining 419 packet_from_server: is from server - FALSE ssl_find_private_key server 188.165.227.167:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01
dissect_ssl enter frame #28 (first time) conversation = 0x7fdfba3defe8, ssl_session = 0x7fdfba3e0e18 record: offset = 0, reported_length_remaining = 1448 dissect_ssl3_record found version 0x0301 -> state 0x11 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 81, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13 dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39 record: offset = 86, reported_length_remaining = 1362 need_desegmentation: offset = 86, reported_length_remaining = 1362
dissect_ssl enter frame #29 (first time) conversation = 0x7fdfba3defe8, ssl_session = 0x7fdfba3e0e18 record: offset = 0, reported_length_remaining = 2759 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 2343, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 11 offset 5 length 2339 bytes, remaining 2348 record: offset = 2348, reported_length_remaining = 411 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 397, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 12 offset 2353 length 393 bytes, remaining 2750 record: offset = 2750, reported_length_remaining = 9 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 4, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 14 offset 2755 length 0 bytes, remaining 2759
dissect_ssl enter frame #30 (first time) ssl_session_init: initializing ptr 0x7fdfba3e1660 size 672 conversation = 0x7fdfba3df718, ssl_session = 0x7fdfba3e1660 record: offset = 0, reported_length_remaining = 419 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 414, ssl state 0x00 association_find: TCP port 46735 found (nil) packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 410 bytes, remaining 419 packet_from_server: is from server - FALSE ssl_find_private_key server 188.165.227.167:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01
dissect_ssl enter frame #32 (first time) conversation = 0x7fdfba3df718, ssl_session = 0x7fdfba3e1660 record: offset = 0, reported_length_remaining = 1448 dissect_ssl3_record found version 0x0301 -> state 0x11 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 81, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13 dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39 record: offset = 86, reported_length_remaining = 1362 need_desegmentation: offset = 86, reported_length_remaining = 1362
dissect_ssl enter frame #33 (first time) conversation = 0x7fdfba3df718, ssl_session = 0x7fdfba3e1660 record: offset = 0, reported_length_remaining = 2759 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 2343, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 11 offset 5 length 2339 bytes, remaining 2348 record: offset = 2348, reported_length_remaining = 411 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 397, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 12 offset 2353 length 393 bytes, remaining 2750 record: offset = 2750, reported_length_remaining = 9 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 4, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 14 offset 2755 length 0 bytes, remaining 2759
dissect_ssl enter frame #35 (first time) ssl_session_init: initializing ptr 0x7fdfba3e1dc8 size 672 conversation = 0x7fdfba3df380, ssl_session = 0x7fdfba3e1dc8 record: offset = 0, reported_length_remaining = 419 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 414, ssl state 0x00 association_find: TCP port 46734 found (nil) packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 410 bytes, remaining 419 packet_from_server: is from server - FALSE ssl_find_private_key server 188.165.227.167:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01
dissect_ssl enter frame #37 (first time) conversation = 0x7fdfba3df380, ssl_session = 0x7fdfba3e1dc8 record: offset = 0, reported_length_remaining = 1448 dissect_ssl3_record found version 0x0301 -> state 0x11 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 81, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13 dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39 record: offset = 86, reported_length_remaining = 1362 need_desegmentation: offset = 86, reported_length_remaining = 1362
dissect_ssl enter frame #38 (first time) conversation = 0x7fdfba3df380, ssl_session = 0x7fdfba3e1dc8 record: offset = 0, reported_length_remaining = 2759 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 2343, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 11 offset 5 length 2339 bytes, remaining 2348 record: offset = 2348, reported_length_remaining = 411 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 397, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 12 offset 2353 length 393 bytes, remaining 2750 record: offset = 2750, reported_length_remaining = 9 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 4, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 14 offset 2755 length 0 bytes, remaining 2759
dissect_ssl enter frame #39 (first time) ssl_session_init: initializing ptr 0x7fdfba3e2450 size 672 conversation = 0x7fdfba3dfab0, ssl_session = 0x7fdfba3e2450 record: offset = 0, reported_length_remaining = 419 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 414, ssl state 0x00 association_find: TCP port 46736 found (nil) packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 410 bytes, remaining 419 packet_from_server: is from server - FALSE ssl_find_private_key server 188.165.227.167:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01
dissect_ssl enter frame #43 (first time) conversation = 0x7fdfba3dfab0, ssl_session = 0x7fdfba3e2450 record: offset = 0, reported_length_remaining = 1448 dissect_ssl3_record found version 0x0301 -> state 0x11 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 81, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13 dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39 record: offset = 86, reported_length_remaining = 1362 need_desegmentation: offset = 86, reported_length_remaining = 1362
dissect_ssl enter frame #44 (first time) conversation = 0x7fdfba3dfab0, ssl_session = 0x7fdfba3e2450 record: offset = 0, reported_length_remaining = 2759 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 2343, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 11 offset 5 length 2339 bytes, remaining 2348 record: offset = 2348, reported_length_remaining = 411 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 397, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 12 offset 2353 length 393 bytes, remaining 2750 record: offset = 2750, reported_length_remaining = 9 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 4, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 14 offset 2755 length 0 bytes, remaining 2759
dissect_ssl enter frame #45 (first time) conversation = 0x7fdfba3de8b8, ssl_session = 0x7fdfba3e0028 record: offset = 0, reported_length_remaining = 198 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 134, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 16 offset 5 length 130 bytes, remaining 139 ssl_decrypt_pre_master_secret key exchange 0 different from KEX_RSA (16) dissect_ssl3_handshake can't decrypt pre master secret record: offset = 139, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - FALSE ssl_change_cipher CLIENT record: offset = 145, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 192 offset 150 length 13768779 bytes, remaining 198
dissect_ssl enter frame #48 (first time) conversation = 0x7fdfba3de8b8, ssl_session = 0x7fdfba3e0028 record: offset = 0, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - TRUE ssl_change_cipher SERVER record: offset = 6, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 23 offset 11 length 12542631 bytes, remaining 59
dissect_ssl enter frame #49 (first time) conversation = 0x7fdfba3dec50, ssl_session = 0x7fdfba3e0790 record: offset = 0, reported_length_remaining = 198 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 134, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 16 offset 5 length 130 bytes, remaining 139 ssl_decrypt_pre_master_secret key exchange 0 different from KEX_RSA (16) dissect_ssl3_handshake can't decrypt pre master secret record: offset = 139, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - FALSE ssl_change_cipher CLIENT record: offset = 145, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 119 offset 150 length 8074366 bytes, remaining 198
dissect_ssl enter frame #52 (first time) conversation = 0x7fdfba3dec50, ssl_session = 0x7fdfba3e0790 record: offset = 0, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - TRUE ssl_change_cipher SERVER record: offset = 6, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 209 offset 11 length 14662272 bytes, remaining 59
dissect_ssl enter frame #54 (first time) conversation = 0x7fdfba3defe8, ssl_session = 0x7fdfba3e0e18 record: offset = 0, reported_length_remaining = 198 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 134, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 16 offset 5 length 130 bytes, remaining 139 ssl_decrypt_pre_master_secret key exchange 0 different from KEX_RSA (16) dissect_ssl3_handshake can't decrypt pre master secret record: offset = 139, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - FALSE ssl_change_cipher CLIENT record: offset = 145, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 93 offset 150 length 5956532 bytes, remaining 198
dissect_ssl enter frame #56 (first time) conversation = 0x7fdfba3defe8, ssl_session = 0x7fdfba3e0e18 record: offset = 0, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - TRUE ssl_change_cipher SERVER record: offset = 6, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 237 offset 11 length 3291872 bytes, remaining 59
dissect_ssl enter frame #57 (first time) conversation = 0x7fdfba3df718, ssl_session = 0x7fdfba3e1660 record: offset = 0, reported_length_remaining = 198 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 134, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 16 offset 5 length 130 bytes, remaining 139 ssl_decrypt_pre_master_secret key exchange 0 different from KEX_RSA (16) dissect_ssl3_handshake can't decrypt pre master secret record: offset = 139, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - FALSE ssl_change_cipher CLIENT record: offset = 145, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 71 offset 150 length 13889844 bytes, remaining 198
dissect_ssl enter frame #60 (first time) conversation = 0x7fdfba3df718, ssl_session = 0x7fdfba3e1660 record: offset = 0, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - TRUE ssl_change_cipher SERVER record: offset = 6, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 9 offset 11 length 2854628 bytes, remaining 59
dissect_ssl enter frame #61 (first time) conversation = 0x7fdfba3df380, ssl_session = 0x7fdfba3e1dc8 record: offset = 0, reported_length_remaining = 198 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 134, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 16 offset 5 length 130 bytes, remaining 139 ssl_decrypt_pre_master_secret key exchange 0 different from KEX_RSA (16) dissect_ssl3_handshake can't decrypt pre master secret record: offset = 139, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - FALSE ssl_change_cipher CLIENT record: offset = 145, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 163 offset 150 length 10485016 bytes, remaining 198
dissect_ssl enter frame #62 (first time) conversation = 0x7fdfba3df380, ssl_session = 0x7fdfba3e1dc8 record: offset = 0, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - TRUE ssl_change_cipher SERVER record: offset = 6, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 175 offset 11 length 3210904 bytes, remaining 59
dissect_ssl enter frame #65 (first time) conversation = 0x7fdfba3dfab0, ssl_session = 0x7fdfba3e2450 record: offset = 0, reported_length_remaining = 198 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 134, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 16 offset 5 length 130 bytes, remaining 139 ssl_decrypt_pre_master_secret key exchange 0 different from KEX_RSA (16) dissect_ssl3_handshake can't decrypt pre master secret record: offset = 139, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - FALSE ssl_change_cipher CLIENT record: offset = 145, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 124 offset 150 length 9835581 bytes, remaining 198
dissect_ssl enter frame #66 (first time) conversation = 0x7fdfba3dfab0, ssl_session = 0x7fdfba3e2450 record: offset = 0, reported_length_remaining = 59 dissect_ssl3_record: content_type 20 dissect_ssl3_change_cipher_spec packet_from_server: is from server - TRUE ssl_change_cipher SERVER record: offset = 6, reported_length_remaining = 53 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 48, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 107 offset 11 length 4787313 bytes, remaining 59
...
Valentin,
Le 27 avril 2011 11:37, Valentin Surrel valentin@surrel.org 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 d'application.
Donc tu as l'IP du client en amont du reverse proxy, puis tu as le marqueur entre le RP et le serveur, mais en retour du serveur, tu n'as aucun moyen de distinguer la destination de la réponse à part le fait que le retour se fasse sur la même session TCP que le paquet marqué en entrée, c'est bien ça ?
tcpdump sait filtrer de façon assez avancée, mais pas en statefull malheureusement. Donc à part un filtrage à posteriori d'un .pcap gigantesque, ça ne parait pas être une option.
Est ce que tu as un moyen d'altérer le code fonctionnant sur le serveur applicatif pour rendre le header persistant et l'inclure dans la réponse ?
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és à ce client là.
Je ne sais pas quelle techno tu as, mais tu peux aussi mettre le module rpxy en debug...
Quel est le bug déjà ?
2011/4/27 Valentin Surrel valentin@surrel.org:
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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
Merci de votre aide !
Valentin _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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 sinon ?
Hervé.
On Wed, 27 Apr 2011 11:37:53 +0200 Valentin Surrel valentin@surrel.org 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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
Merci de votre aide !
Valentin _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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 headers HTTP dans les deux sens pour voir si :
- le cookie de session est toujours bien retourné par le client (et son contenu) - si on aurait pas mis du delete cookie dans une réponse par erreur
En gros déjà isoler si c'est un problème coté client ou coté applicatif.
On n'a pas la main sur les clients, c'est du genre client lambda.
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 ajoute un X-Real-IP pour avoir simplement l'IP d'où vient la requête sans se prendre la tête.
Le frontal est un nginx, je vais voir s'il est possible de lui faire dumper les headers dans les deux sens, mais je vais aussi regarder en prioriter le tcpdump en amont du SSL et décrypter le flux.
Le 27/04/2011 12:04, Hervé COMMOWICK a écrit :
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 sinon ?
Hervé.
On Wed, 27 Apr 2011 11:37:53 +0200 Valentin Surrel valentin@surrel.org 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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
Merci de votre aide !
Valentin _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On Wed, 27 Apr 2011 12:14:14 +0200 Valentin Surrel valentin@surrel.org 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 ajoute un X-Real-IP pour avoir simplement l'IP d'où vient la requête sans se prendre la tête.
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 sien :)
Hervé.
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 sien:)
Je pensais probablement à tort que c'était le comportement adopté par nginx. Je vais tout de même faire des tests pour m'en assurer ! :)
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 valentin@surrel.org:
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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
Merci de votre aide !
Valentin _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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 valentin@surrel.org:
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. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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/2011 12:19, Steven Le Roux a écrit :
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 valentin@surrel.org:
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. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
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 ?
1. Est-il envisageable de faire sauter le SSL entre le reverse et le serveur applicatif ? Ce qui simplifierait l'écoute réseau.
2. Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le flux est bien en SSL, est-il envisageable de forcer l'utilisation du chiffrement null entre le reverse et le serveur applicatif ? Le flux circulerait alors en clair bien qu'en SSL (négo toussa) ce qui simplifierait l'écoute réseau.
3. Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement juste pour ces utilisateurs là.
4. Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un peu de ménage dans les headers, voire ajouterait ces propres cookies (de mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la requête pourrait être débarrassée du cookie de session.
5. Dérivé du précédent. Si les clients sont derrière un proxy, est-il possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé.
Mes 2 cents, JB
2011/4/27 Jean Baptiste FAVRE fr-sag@jbfavre.org:
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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
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 ?
- Est-il envisageable de faire sauter le SSL entre le reverse et le
serveur applicatif ? Ce qui simplifierait l'écoute réseau.
- Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le
flux est bien en SSL, est-il envisageable de forcer l'utilisation du chiffrement null entre le reverse et le serveur applicatif ? Le flux circulerait alors en clair bien qu'en SSL (négo toussa) ce qui simplifierait l'écoute réseau.
- Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement
juste pour ces utilisateurs là.
- Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un
peu de ménage dans les headers, voire ajouterait ces propres cookies (de mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la requête pourrait être débarrassée du cookie de session.
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 peut être derriere un proxy qui load balancent deux accès internet... du coup l'ip peut changer une requete sur deux pour ceux là.
- Dérivé du précédent. Si les clients sont derrière un proxy, est-il
possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé.
Mes 2 cents, JB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
+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 fr-sag@jbfavre.org:
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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
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 ?
- Est-il envisageable de faire sauter le SSL entre le reverse et le
serveur applicatif ? Ce qui simplifierait l'écoute réseau.
- Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le
flux est bien en SSL, est-il envisageable de forcer l'utilisation du chiffrement null entre le reverse et le serveur applicatif ? Le flux circulerait alors en clair bien qu'en SSL (négo toussa) ce qui simplifierait l'écoute réseau.
- Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement
juste pour ces utilisateurs là.
- Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un
peu de ménage dans les headers, voire ajouterait ces propres cookies (de mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la requête pourrait être débarrassée du cookie de session.
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 peut être derriere un proxy qui load balancent deux accès internet... du coup l'ip peut changer une requete sur deux pour ceux là.
- Dérivé du précédent. Si les clients sont derrière un proxy, est-il
possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé.
Mes 2 cents, JB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
2011/4/27 Jean Baptiste FAVRE fr-sag@jbfavre.org:
+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/04/2011 23:29, Steven Le Roux wrote:
2011/4/27 Jean Baptiste FAVRE fr-sag@jbfavre.org:
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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
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 ?
- Est-il envisageable de faire sauter le SSL entre le reverse et le
serveur applicatif ? Ce qui simplifierait l'écoute réseau.
- Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le
flux est bien en SSL, est-il envisageable de forcer l'utilisation du chiffrement null entre le reverse et le serveur applicatif ? Le flux circulerait alors en clair bien qu'en SSL (négo toussa) ce qui simplifierait l'écoute réseau.
- Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement
juste pour ces utilisateurs là.
- Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un
peu de ménage dans les headers, voire ajouterait ces propres cookies (de mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la requête pourrait être débarrassée du cookie de session.
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 peut être derriere un proxy qui load balancent deux accès internet... du coup l'ip peut changer une requete sur deux pour ceux là.
- Dérivé du précédent. Si les clients sont derrière un proxy, est-il
possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé.
Mes 2 cents, JB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
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 peut être derriere un proxy qui load balancent deux accès internet... du coup l'ip peut changer une requete sur deux pour ceux là.
Hum à tout hasard je vais demander aux dévelos de regarder :-) Ca serait pas la première connerie qu'on trouverait dans Rails.....
Mais le problème ne devrait pas venir de là, X-Real-Ip ne sert pas pour la session mais uniquement pour les logs des serveurs applicatifs.
Valentin
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 surtout avec des IP en sortie loadbalancée
Je suis également partisan d'ajouter son propre header pour suivre par où est passé un session. J'ai déjà vu des équipement insérer leurs IP au début, au milieu et à la fin du header X-forwarded-For.
Pour debuger tu peux également utiliser Charles Proxy ( http://www.charlesproxy.com/) que j'ai découvert récement et qui est très abouti
Question quel est le reverse utilisé ?
HTH
Le 27 avril 2011 21:59, Jean Baptiste FAVRE fr-sag@jbfavre.org a écrit :
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'application.
Un moyen de trouver les requêtes que fait le client est de faire ça :
ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541
1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep.
Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ?
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 ?)
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 ?
- Est-il envisageable de faire sauter le SSL entre le reverse et le
serveur applicatif ? Ce qui simplifierait l'écoute réseau.
- Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le
flux est bien en SSL, est-il envisageable de forcer l'utilisation du chiffrement null entre le reverse et le serveur applicatif ? Le flux circulerait alors en clair bien qu'en SSL (négo toussa) ce qui simplifierait l'écoute réseau.
- Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement
juste pour ces utilisateurs là.
- Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un
peu de ménage dans les headers, voire ajouterait ces propres cookies (de mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la requête pourrait être débarrassée du cookie de session.
- Dérivé du précédent. Si les clients sont derrière un proxy, est-il
possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé.
Mes 2 cents, JB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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 :
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 surtout avec des IP en sortie loadbalancée
Je suis également partisan d'ajouter son propre header pour suivre par où est passé un session. J'ai déjà vu des équipement insérer leurs IP au début, au milieu et à la fin du header X-forwarded-For.
Pour debuger tu peux également utiliser Charles Proxy (http://www.charlesproxy.com/) que j'ai découvert récement et qui est très abouti
Question quel est le reverse utilisé ?
HTH
Le 27 avril 2011 21:59, Jean Baptiste FAVRE <fr-sag@jbfavre.org mailto:fr-sag@jbfavre.org> a écrit :
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'application. > > Un moyen de trouver les requêtes que fait le client est de faire ça : > > ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 > > 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer > la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir > d'option pour ceci dans ngrep. > > Auriez-vous des pistes à me suggérer (on peut très difficilement tout > enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi > impossible du fait de sa taille) ? > > 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 ?) 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 ? 1. Est-il envisageable de faire sauter le SSL entre le reverse et le serveur applicatif ? Ce qui simplifierait l'écoute réseau. 2. Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le flux est bien en SSL, est-il envisageable de forcer l'utilisation du chiffrement null entre le reverse et le serveur applicatif ? Le flux circulerait alors en clair bien qu'en SSL (négo toussa) ce qui simplifierait l'écoute réseau. 3. Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement juste pour ces utilisateurs là. 4. Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un peu de ménage dans les headers, voire ajouterait ces propres cookies (de mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la requête pourrait être débarrassée du cookie de session. 5. Dérivé du précédent. Si les clients sont derrière un proxy, est-il possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé. Mes 2 cents, JB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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.
- Est-il envisageable de faire sauter le SSL entre le reverse et le
serveur applicatif ? Ce qui simplifierait l'écoute réseau.
Il n'y a pas de SSL entre le reverse et le serveur d'appli. L'écoute réseau ne se fait pas là pour isoler plus facilement le trafic des clients où ça pose problème.
(client) <---Internet/443/https--> (frontal ssl reverse) <---LAN/2501/http---> (serveur d'appli)
- Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le
flux est bien en SSL, est-il envisageable de forcer l'utilisation du chiffrement null entre le reverse et le serveur applicatif ? Le flux circulerait alors en clair bien qu'en SSL (négo toussa) ce qui simplifierait l'écoute réseau.
L'applicatif ne voit rien du SSL donc en pratique dans mon cas.
- Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement
juste pour ces utilisateurs là.
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.
- Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un
peu de ménage dans les headers, voire ajouterait ces propres cookies (de mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la requête pourrait être débarrassée du cookie de session.
A priori non, l'IP est de la simple collecte ADSL wanadoo. Ca semble être un mac perso à la maison en l'occurence. La personne a pas l'air très technique, on essaye d'en savoir un maximum avant de devoir la déranger plus pour essayer d'avoir des renseignements ! :p
- Dérivé du précédent. Si les clients sont derrière un proxy, est-il
possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé.
Le nom de notre cookie est complétement custom ; et le pb arrive chez deux clients complètement différents.
Je vous tiens au courant des avancées, au cas où... :) (et si c'est un gros fail de notre part aussi !)
A+
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.wireshark.org/SSL je n'arrive pas à le faire fonctionner.
Je dois être probablement trop con ! :)
Je vais essayer sur un autre PC... #Dream
regarde mon poste et essaie charles proxy :)
Le 28 avril 2011 11:19, Valentin Surrel valentin@surrel.org 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 sortie sur Internet afin de voir directement le problème.
Bon, même le SampleCapture sur http://wiki.wireshark.org/SSL je n'arrive pas à le faire fonctionner.
Je dois être probablement trop con ! :)
Je vais essayer sur un autre PC... #Dream _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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 expliquer que Wireshark n'arrive pas à décoder le flux ?
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, avec autorité intermédiaire. Est ce que cela pourrait expliquer que Wireshark n'arrive pas à décoder le flux ?
En théorie non: la clef privée du serveur (ici, le reverse proxy) est utilisée par Wiershark pour décoder la négotiation de la clef de session SSL.
L'autorité de certification, même intermédiaire, n'est là que pour que le client puisse vérifier l'authenticité du certificat via le chemin de certification: ton certificat -> CA Gandi -> CA qui a signé la CA de Gandi -> ... -> CA racine intégrée dans le navigateur.
Cordialement, JB
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'occurence, les requêtes POST des clients impactés ne comportent pas, de temps en temps uniquement, ce header.
C'est donc "workaroundable", en attendant de voir quelle est la cause de ce header HTTP qui disparaît... Savez-vous si les trucs du genre "Norton Internet Security" ou autres supers logiciels de ce genre ont pour habitude d'altérer les entêtes HTTP ?
A+ Valentin
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 exemple.
Cordialement Sebastien FOUTREL
Le 17 mai 2011 08:52, Valentin Surrel valentin@surrel.org a écrit :
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'occurence, les requêtes POST des clients impactés ne comportent pas, de temps en temps uniquement, ce header.
C'est donc "workaroundable", en attendant de voir quelle est la cause de ce header HTTP qui disparaît... Savez-vous si les trucs du genre "Norton Internet Security" ou autres supers logiciels de ce genre ont pour habitude d'altérer les entêtes HTTP ?
A+ Valentin _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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 les seuls à le constater, même si on n'est pas nombreux :
https://bugzilla.mozilla.org/show_bug.cgi?id=646378
Bref on a mis en place une autre solution pour contourner.
Je tenais quand même à partager le constat avec vous, c'est bon à savoir que parfois FF ne renvoi pas les headers attendus !
A+
Le 17/05/2011 11:58, Sébastien FOUTREL a écrit :
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 exemple.
Cordialement Sebastien FOUTREL
Le 17 mai 2011 08:52, Valentin Surrel valentin@surrel.org a écrit :
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'occurence, les requêtes POST des clients impactés ne comportent pas, de temps en temps uniquement, ce header.
C'est donc "workaroundable", en attendant de voir quelle est la cause de ce header HTTP qui disparaît... Savez-vous si les trucs du genre "Norton Internet Security" ou autres supers logiciels de ce genre ont pour habitude d'altérer les entêtes HTTP ?
A+ Valentin _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/