Martin Rex wrote: > > There were a few issues with F5 loadbalancers (that were just forwarding > traffic, _not_ acting as reverse proxy) related to a borked F5 option called > "FastL4forward", which occasionally caused the F5 box to truncate TCP streams > (the box received&ACKed 5 MByte of TCP data towards the TLS Server, but > forwarded only 74 KBytes to the client before closing the connection with > a TCP FIN towards the TLS client. > > And once I saw another strange TCP-level data corruption caused by > some Riverbed WAN accellerator.
I forgot to mention how I analyzed the breakage created by the middleboxes: network capture (tcpdump) with a IP-address capture filter for a dedicated client machine was *perfectly* sufficient to determine the TCP-level breakage. For the F5 cockup, we used a concurrent tcpdump capture on the box in both directions, again with IP-address capture filter, in order to prove to the vendor that his box is corrupting/truncating the TCP stream between TLS client and TLS server. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
