Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact

[Eric Rescorla <[e-mail]>]

On Thu, Aug 20, 2020 at 7:01 AM Roelof DuToit <[e-mail]> wrote:

> As co-author I am not a proponent of passive TLS inspection - not least
> because of the ossification implications.  It cannot be labeled as
> ineffective though (see further comments below), even if the document
> strongly hints at not using passive TLS inspection in a post-TLS-1.2 world.
>
> > On Aug 19, 2020, at 6:43 PM, Nick Lamb <[e-mail]> wrote:
> >
> > The passive eavesdropper can indeed see the handshake in TLS 1.2, but
> > since they were not a participant they don't actually know what it
> > means even though it wasn't encrypted.
> >
> > For example, suppose an RSA certificate is sent and the handshake seems
> > to agree RSA key exchange and Client sends an EncryptedPreMasterSecret.
> > The passive eavesdropper has no idea if that's actually encrypted to the
> > RSA public key from the certificate, it's just an opaque blob.
> >
> >
> > Thus it's easily possible for an eavesdropper to witness a handshake in
> > which the eavesdropper believes what happened is:
> >
> > Client proposed to do RSA key exchange
> > Server showed a certificate for www.local-hospital.example
> > Client sent an EncryptedPreMasterSecret to the local hospital
> > both agreed this all worked fine and continue encrypted
> >
> > The eavesdropper's "Don't eavesdrop on people's medical stuff" policy
> > kicks in and it allows the connection unmolested. Unfortunately what
> > really happened is:
> >
> > Client proposed to do RSA key exchange
> > Server showed a certificate for www.local-hospital.example
> > Client sent an EncryptedPreMasterSecret for the GRU data exfiltration
> > server ignoring the bogus certificate
> > $5Bn of stolen commercial documents are uploaded to the server
>
>
> Advanced passive TLS inspection devices use a combination of techniques to
> defend against those attacks for TLS 1.2 (and below):
> 1. Policy-based control over the use of RSA key exchange.  It should not
> be allowed.
> 2. Checking the signature in the ServerKeyExchange message when (EC)DHE
> key exchange is used.
> 3. Not trusting the destination IP address.  The hostname from the SNI is
> resolved and compared.
>
> None of those techniques are perfect given an advanced adversary that
> controls the client + DNS in the enterprise + the flow of traffic on the
> server side of the TLS inspection device.
> (Side note: If I’m an attacker that has control over DNS then I would not
> bother with TLS-based attacks for data exfiltration).
> In other words, nation state attacks might succeed but it does not mean
> that passive TLS inspection devices are not effective against other attacks.
>

It seems to me that the conditions under which this kind of inspection
works and does not work are quite subtle. If you want to proceed with this
document, it would probably be good to document them,

-Ekr