Re: [TLS] datacenter TLS decryption as a three-party protocol

[[e-mail] (Martin Rex)]

I just watched the presentation on static DH / TLS decryption in Enterprise
settings of todays TLS session

  https://youtu.be/fv1AIgRdKkY?t=4473

and I'm seriously appalled by the amount of cluelessness in the
Networking & IT Departments on the one hand, and by what seems like
woefully inadequate apps on the other hand.

I've been doing middleware development and customer support of
SSL/TLS-protected communication for our company's (legacy) app
as well as maintenance & customer support for the TLS stack we're
shipping with it for the past 17 years, and I can't stop shaking
my head about the perceived problems, that *NEVER*EVER* occurred
to me, nor our IT & Hosting and neither any of our customers using our app
(and I would definitely know about it).

Although we do ship our own TLS implementation, we don't have any APIs
to export cryptographic keys, simply because it's completely unnecessary.


With extremely few exceptions, an API-level trace at the endpoints
is totally sufficient for finding app-level problems, such as
unexpected "expensive" requests.  App-level traces on *EITHER* side
should provide *ALL* information that is necessary to determine _which_
particular requests are taking longer than expected.  If your Apps do
not provide meaningful traces, then you have an *APPS* problem, and
should be fixing or replacing apps, rather than mess around with TLS.


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 remember exactly _two_ occasions during that 17 years when I produced
a special instrumented version of our library for the server endpoint,
which dumped stuff into a local trace file, but I never ever thought
about exporting crypto keys (because it wouldn't help, and those
weren't _my_ keys (but those of a customer):

   (1) it dumped the decrypted RSA block from the ClientKeyExchange
       handshake message when encountering a PKCS#1 BT02 padding
       encoding failure

   (2) it dumped the final decrypted block of a TLS record for
       when the CBC-padding-verification failed the check.

(1) was caused by a bug in the long integer arithmetic of an F5 load balancer
    which ocassionally produced bogus (un-decryptable) PreMasterSecrets

(2) was caused by a design flaw in JavaSE 1.6 by Java's SSL when it was used with GenericBlockCipher over native-IO interfaces.


I firmly believe that if you have a desire to decrypt TLS-protected
traffic to debug APPS issues, then your APPS must be crap, and seriously
lack capabilities to trace/analyze endpoint behaviour at the app level.


With respect to "monitoring" SSL/TLS-protected traffic in the
enterprise environment:

At least here in Germany, we're in the lucky position that wiretapping
network traffic has been made a criminal offense in 2004.  If IT/Networking
folks in the enterprise settings don't want to spend up to 4 years behind
bars, they don't even try to decrypt SSL/TLS-protected traffic.

 
-Martin