Am 19.07.2017 um 22:32 schrieb Martin Rex:
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.
In many companies the app is from one vendor and the loadbalancer from
another one. Both vendors are telling you the other is causing the
problem. Then you will have some fun to turn on undocumented app level
tracing. However the proposed solution will have the same problem when
the app doesn't support it.
One question to the company proponents, would you allow the end / home
users the same capabilities? E.g. some equipment at home/cellular is
phoning back to the vendor. The owner of the equipment can't see what is
transferred and need to trust the vendor, so should end users get the
keys? It can be a similar problem, e.g. the app doesn't work as expected
and the vendor says this must be the home / cellular network. How to
proof that it is the app fault and not the home network?
Regards,
Roland
P.S. Be careful as I think preparing for wiretapping and having tools
for it may already bring you behind bars in Germany, although I think
this law wasn't used so far.
-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
