Just to note that Martin's mail contains specific examples and detailed argument. That should be the lowest bar that needs to be met in this discussion, not the arm-waving about "TLS as a DoS attack" or "what about grandma" nonsense that we heard today. The contrast between such non-argument and the care that has been taken, and continues to be taken, in the development of TLS1.3 is stark.
S. On 19/07/17 21:25, Martin Rex wrote: > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
