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

[Stephen Farrell <[e-mail]>]

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
>