Subject: [TLS] ESNI padding the Certificate message

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2018 13:10:07 +0000

Hiya,

Was just adding code for this and I noticed that the draft says
a server: "SHOULD pad the Certificate message, via padding at
the record layer, such that its length equals the size of the
largest possible Certificate (message) covered by the same ESNI
key."

I think that ought also mention the CertificateVerify as that
could also tell you something about the ESNI being used if the
key lengths in the various certificates differ.

More specific to openssl though, there isn't really a terribly
easy way to do such fine-grained padding (that I've found so
far), so to cover the above, and as there are likely many
other ways that the ESNI could be exposed, it might be good to
add that clients and servers could reasonably decide to pad all
handshake messages or even all records. (That last being what
is currently easiest with openssl, and hence what I've done
for now with my proof-of-concept code:-)

Cheers,
S.

---

From: Matt Caswell <[email-masked]>
Date: Thu, 13 Dec 2018 13:36:12 +0000

On 13/12/2018 13:10, Stephen Farrell wrote:
> far),

You can set a padding callback using SSL_CTX_set_record_padding_callback() (or
SSL_set_record_padding_callback()). The callback can determine whether it is
padding a handshake message by examining its "type" parameter, and which message
it is by calling SSL_get_state(). From there you should be able to get the
callback to add padding only to the Certificate and/or CertificateVerify
messages as required.

Matt

> so to cover the above, and as there are likely many
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2018 13:54:47 +0000

> callback to add padding only to the Certificate and/or CertificateVerify

Thanks! I'll try that,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Dec 2018 07:09:32 -0800

> key lengths in the various certificates differ.

Sure. Send a PR.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Dec 2018 10:27:46 -0500

> On Dec 13, 2018, at 8:10 AM, Stephen Farrell <[email-masked]> wrote:
> 

"Largest possible" is not always a knowable target.  One often does
not know anything about the sizes of the other potential certificate
chains in advance of serving such a chain.  Far more sensible would
be to add random padding whose size is commensurate with the size of
the certificate message.

I would generate a random nibble, and count the first $k$
non-zero bits.  Then $1 + k$ times add independently
random([0, N/2]) bytes of padding to an $N$ byte message,
giving an additional $~N$ bytes on average, but occasionally
up to $2.5N$ additional bytes.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Dec 2018 07:51:17 -0800

On Thu, Dec 13, 2018 at 7:28 AM Viktor Dukhovni <[email-masked]>
wrote:

> chains in advance of serving such a chain.

You already need some of this information in order to specify the largest
possible SNI (so you can pad to it), so I don't think this is prohibitive.

Far more sensible would

> up to $2.5N$ additional bytes.

Random padding does poorly with repeated trials. So, for instance,
if I get to observe a large number of requests from the same client
to the same server, you can gradually infer the length of the cert
chain.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Dec 2018 11:02:54 -0500

> to the same server, you can gradually infer the length of the cert

Yes, I was aware of this.  But one might also note that may services
are not behind a CDN, and that data traffic patterns after the
handshake can also fingerprint the target service.

Session resumption helps to reduce the number of full handshakes
that leak some information about the certificate size.

Users who really want (better) protection against traffic analysis
should use Tor.  TLS traffic analysis protection from ESNI et. al.
is IMHO best-effort protection for casual use.

If a user visits just one site (and no others) at a particular CDN,
absent traffic flow obfuscation ala Tor, the user's TLS traffic
will eventually stand out from the noise.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Dec 2018 08:53:33 -0800

> handshake can also fingerprint the target service.

Yes. But the idea here is to gradually remove fingerprinting surface, and so
the mitigations we recommend should work.

-Ekr

---

From: David Fifield <[email-masked]>
Date: Thu, 13 Dec 2018 10:36:39 -0700

> will eventually stand out from the noise.

Tor does not really offer protection against traffic analysis, apart
from hiding the source and destination IP addresses. In fact a lot of
website fingerprinting research uses Tor as a carrier, *because* it
preserves features of the underlying flow. See for example Table 1 at
https://petsymposium.org/2018/files/papers/issue4/popets-2018-0039.pdf#page=3
Tor pads most of its cells to 514 bytes (https://spec.torproject.org/tor-spec §0.2 §3),
and fairly recently (Tor 0.3.1.7, 2017-09-18) it sends padding cells
during quiet periods in order to collapse long-term netflow records
(https://spec.torproject.org/padding-spec §2), but neither of these are
designed to defend against website fingerprinting attacks; on the
contrary, they introduce fingerprints that make it easier to detect the
use of Tor inside a tunnel.

Don't miss an important use case. Tor and ESNI are not mutually
exclusive. A user may want to use ESNI in order to *reach* Tor (or any
other service offering additional security properties). ESNI is not just
for HTTPS web pages; it's for any TLS service (or service that can be
tunnelled in TLS). But any such service is useless if an intermediary
can block the server hosting it. This is where ESNI can be of help.

I wouldn't put repeated trials to infer a randomized value, and analysis
of encrypted application-layer traffic characteristics, in the same
class of difficulty, and reason that if the latter is possible, there's
no reason to defend against the former. I think part of the reason that
Tor does not (yet) do traffic flow obfuscation is that it hasn't been
necessary. The networks that block Tor don't do it on that basis. That's
not to say it's not something to think about, just that empirically it
hasn't proven as pressing as other considerations. Things like Cisco ETA
(https://www.theregister.co.uk/2017/06/22/ciscos_encrypted_traffic_fingerprinting_turned_into_product/,
https://github.com/cisco/joy#relation-to-cisco-eta, https://arxiv.org/abs/1607.01639)
show the commercial world at least reaching for such capabilities, but
my understanding is that it's still far short of an operational
"identify this HTTPS site" feature.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2018 19:04:08 +0000

Hiya,

> Sure. Send a PR.

Just did that adding in CerticateVerify. [1]

That PR does also take out the "longest cert length" aspect
of the current text - I reckon Viktor's right that one might
not know that, and it could be error prone as new certs get
issued in some scenarios. I'd not yell much if you wanted to
keep that aspect but I'd equally argue we might be better off
with some more general "traffic analysis considerations"
text we can work on later (e.g. after the DNS stuff changes).

Cheers,
S

[1] https://github.com/tlswg/draft-ietf-tls-esni/pull/122