Hi, thanks very much, I went a little deeper about Cipher Suite.
Now I changed the ciphers list supported by our haproxy LBs and increased the security level (always trying to keep ciphers that support old clients that still use our services - like XP/IE8). I tried successfully Decrypting a trace file with Wireshark, taken with tcpdump. Setting NOT-Ephemeral Ciphers on haproxy LBs (temporary disabling DHE, EDH chippers on haproxy LBs). At least for the most part the trace file was Decrypted an shown correctly, but we see some parts that appear as TCP or TLSv1.2 or SSL type “XXX Segment of a reassembled PDU”: [cid:image002.png@01D1C1A9.2BA67CA0] apparently of only few bytes, but if we point on the SSL/TLS layer field “Encrypted Application Data” we see lot of data. [cid:image003.png@01D1C1AB.04BE6510] We can see also 3 tabs for that line: Frame, Reasembled TCP and Decrypted SSL Data, so we can see Decrypted Data, and also show as HTTP if we Follow TCP traffic. [cid:image001.png@01D1C1AC.AE248660] I discovered that in Wireshark TCP protocol preference “Allow Subdissector to reassemble TCP streams” allow me to see Decrypted Traffic, do you know about some other Wireshark configuration about these SSL / TCP reassembled PDU so these can be seen differently in the Wireshark ? As soon as possible I'll try the Ephemeral case Decryption using client session keys (as Igor suggested), also if it is more difficult as I see there are different ssl handshake so it is not so clear if Browser append or overwrite session key files and if it is simple to put in relationship and to correctly analyze with wireshark these different SSL/HTTP stream, I think. Probably in HAproxy it could be implemented a kind of virtual network interface mechanism that tcpdump could connect to retrieve the Decrypted Traffic, so achieve less dependency from external tools and less original environment “contamination / manipulation”. For haproxy "option http-ignore-probes" I think this is a solution to test before, to evaluate what client see. In my experience for Browsers that have problems correctly managing pre-connect and graceful TCP session closing, not emitting 408 can totally hide problems that need to be analyzer and explained to avoid strange and hidden behavior. Also if 408 is not an infrastructure problem, the customer perception can be different... I know also that these 408/400 can distort the statistics, but is not a simple choice. Roberto -----Original Message----- From: Lukas Tribus [mailto:lu...@gmx.net] Sent: domenica 5 giugno 2016 12.16 To: Igor Cicimov <ig...@encompasscorporation.com>; mlist <ml...@apsystems.it> Cc: HAProxy <haproxy@formilux.org> Subject: Re: tcpdump and Haproxy SSL Offloading Hi, Am 05.06.2016 um 02:19 schrieb Igor Cicimov: > > > In haproxy.cfg I used these cipher I found recommended: > > ciphers ECDHE-RSA-AES256-SHA:RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM > I would not recommend this. Check [1] and [2] for some uptodate recommendations. Yes, removing ECDHE-RSA-AES256-SHA will force the server to use the non-FS RC4 cipher. Regarding the 408 problem, please have a look at the http-ignore-probes option [3]. Regards, Lukas [1] https://wiki.mozilla.org/Security/Server_Side_TLS [2] https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy-1.6&openssl=1.0.2&hsts=no&profile=intermediate [3] http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#4-option%20http-ignore-probes -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto.
