Subject: [TLS] The future devices that will break TLS 1.4

From: Hanno Böck <[email-masked]>
Date: Sat, 13 Jan 2018 00:02:06 +0100

Hi,

This working group just went through a painful process of realizing
that deploying a new TLS version on the Internet is a hard task due to
broken devices. If you're not aware David Benjamin just gave a great
talk summarizing the issues:
https://www.youtube.com/watch?v=_mE_JmwFi1Y

Today I found this article:
https://www.theregister.co.uk/2018/01/11/cisco_sniff_malware_inside_encrypted_traffic/

tl;dr Cisco now says they can identify malware in TLS traffic by
carefully looking at it.
(For context: devices from Cisco were responsible for many of the
issues that made deploying TLS 1.3 hard, e.g. version intolerance on
load balancers and recently by not correctly terminating TLS in a
firewall.)

I'll dare to have a look into the future and make this imho very
plausible claim:
Cisco won't be the only vendor selling such things. We will see more
products that magically can identify "bad things" in TLS traffic by
applying everything from AI to Blockchain.
We will almost certainly see a whole new generation of devices doing
weirdness with TLS and who will drop or manipulate packages that contain
things they don't know (like... a version negotiation field with TLS
1.4 or a large post quantum key exchange message).

The question I want to ask: What can we do *now* to stop this from
happening when TLS 1.4 will be deployed? I have the feeling GREASE
won't be enough...

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Dan Wing <[email-masked]>
Date: Fri, 12 Jan 2018 15:53:05 -0800

> load balancers and recently by not correctly terminating TLS in a

Those bugs that interfere with TLS handshakes are un-related to Cisco's Encrypted Traffic Analytics ("ETA").  Different technologies.

-d

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Hanno Böck <[email-masked]>
Date: Sat, 13 Jan 2018 01:11:15 +0100

On Fri, 12 Jan 2018 15:53:05 -0800
Dan Wing <[email-masked]> wrote:

> Those bugs that interfere with TLS handshakes are un-related to
> Cisco's Encrypted Traffic Analytics ("ETA").  Different technologies.

I haven't claimed that.

I just think it's very plausible to assume that a company that
already created two independent problems for TLS 1.3 will do the same in
future products that mess with TLS in "new and exciting ways".

And for the unlikely case that Cisco is able to learn from past mistakes
I'm absolutely sure there will be others creating similar products that
won't.

-- 
Hanno Böck
https://hboeck.de/

---

From: Yuhong Bao <[email-masked]>
Date: Sat, 13 Jan 2018 00:34:35 +0000

Is that arms race really worth fighting?

________________________________________
From: TLS <[email-masked]> on behalf of Hanno Böck <[email-masked]>
Sent: Friday, January 12, 2018 4:11:15 PM
To: Dan Wing
Cc: [email-masked]
Subject: Re: [TLS] The future devices that will break TLS 1.4

I haven't claimed that.

--
Hanno Böck
https://hboeck.de/

---

From: Yuhong Bao <[email-masked]>
Date: Sat, 13 Jan 2018 00:50:00 +0000

This also applies to TLS 1.3 BTW, not just a future TLS 1.4.

________________________________________
From: TLS <[email-masked]> on behalf of Yuhong Bao <[email-masked]>
Sent: Friday, January 12, 2018 4:34:35 PM
To: Hanno Böck; Dan Wing
Cc: [email-masked]
Subject: Re: [TLS] The future devices that will break TLS 1.4

I haven't claimed that.

--
Hanno Böck
https://hboeck.de/

---

From: Christian Huitema <[email-masked]>
Date: Fri, 12 Jan 2018 16:31:23 -1000

> applying everything from AI to Blockchain.

Well, of course we will see such products. We know that it is possible
to do a lot of pattern recognition based on properties of the encrypted
traffic, as well as clear text parts of the headers. And we also know
that there are lots of network managers that want to understand what's
happening in their networks. The kind of products shown here seems
rather preferable to the previous generation of products that required
breaking the encryption.

> 1.4 or a large post quantum key exchange message).

That's the general problem with machine learning. The attackers will be
learning too, and will try to tweak their traffic until it looks
innocuous. As attackers do that, filters will try to catch them, and the
chances for "false positive" are going to increase.

> happening when TLS 1.4 will be deployed? I have the feeling GREASE

Data sets. Machine learning algorithms are trained with data sets. If we
produce reference data sets showing what TLS 1.4 looks like, the vendors
can retrain their AI and start recognizing the new version for what it
is, rather than some unknown attack.

-- Christian Huitema

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 14 Jan 2018 14:34:22 +0100

> happening when TLS 1.4 will be deployed? I have the feeling GREASE

Sidebar: TLS 4 ;)

-- 
Tony Arcieri

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jan 2018 09:09:28 +1100

The research that this is built on isn't especially new:
https://arxiv.org/abs/1607.01639

The interesting observation in that paper is that the results are
obtained only from the subset of malware that uses its own TLS
configuration.  Those that used the Windows stack in a default
configuration were removed from consideration.  Now, it's possible
that things have improved since that paper, but it suggests the
presence of a gap that we might exploit.  So I'm not so down on
GREASE.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 15 Jan 2018 13:37:20 +0100

> is, rather than some unknown attack.

doesn't help with already deployed gear, and we really can't predict how TLS 
1.4 will look like to give examples of it to them right now
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic