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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
