IETF draft: SNI Encryption in TLS Through Tunneling

49 views
Skip to first unread message

David Fifield

unread,
Jun 22, 2017, 3:10:18 PM6/22/17
to traff...@googlegroups.com
https://tools.ietf.org/html/draft-huitema-tls-sni-encryption-00
This draft describes the general problem of encryption of the
Server Name Identification (SNI) parameter. The proposed
solutions hide a Hidden Service behind a Fronting Service, only
disclosing the SNI of the Fronting Service to external
observers. The draft starts by listing known attacks against
SNI encryption, and then presents two potential solutions that
might mitigate these attacks. The first solution is based on
TLS in TLS "quasi tunneling", and the second solution is based
on "combined tickets". These solutions only require minimal
extensions to the TLS protocol.

As I understand it, this proposal would enable something like domain
fronting in TLS 1.3, except it wouldn't be limited only to HTTP-based
services. You still need a dummy, externally visible "front" SNI. The
"real" SNI would be carried either in a tunneled ClientHello (§3) or a
specially formatted session resumption ticket (§4).

Ox Cart

unread,
Jun 30, 2017, 4:09:13 PM6/30/17
to traff...@googlegroups.com
It's exciting to think that censorship resistance could start making its way into standard Internet protocols!

Cheers,
Ox


-----------------------------------------------------------------------------------------

"I love people who harness themselves, an ox to a heavy cart,
who pull like water buffalo, with massive patience,
who strain in the mud and the muck to move things forward,
who do what has to be done, again and again."

- Marge Piercy




--
You received this message because you are subscribed to the Google Groups "Network Traffic Obfuscation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to traffic-obf+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Vinicius Fortuna [vee-NEE-see.oos]

unread,
Jun 30, 2017, 5:53:32 PM6/30/17
to Ox Cart, traff...@googlegroups.com
It's exciting indeed!

By the way, there are a few more standards being discussed that can help against censorship:


   HTTP/2 [RFC7540] allows clients to coalesce different origins
   [RFC6454] onto the same connection when certain conditions are met.
   However, in certain cases, a connection is is not usable for a
   coalesced origin, so the 421 (Misdirected Request) status code
   ([RFC7540], Section 9.1.2) was defined.

   Using a status code in this manner allows clients to recover from
   misdirected requests, but at the penalty of adding latency.  To
   address that, this specification defines a new HTTP/2 frame type,
   "ORIGIN", to allow servers to indicate what origins a connection is
   usable for.

   Additionally, experience has shown that HTTP/2's requirement to
   establish server authority using both DNS and the server's
   certificate is onerous.  This specification relaxes the requirement
   to check DNS when the ORIGIN frame is in use.  Doing so has
   additional benefits, such as removing the latency associated with
   some DNS lookups, and improving DNS privacy.



   This document provides a way to authenticate one party of a Transport
   Layer Security (TLS) communication to another using a certificate
   after the session has been established.  This allows both the client
   and server to prove ownership of additional identities at any time
   after the handshake has completed.  This proof of authentication can
   be exported and transmitted out of band from one party to be
   validated by the other party.


There's also record padding in TLS 1.3, which helps against timing attacks:


On Fri, Jun 30, 2017 at 4:09 PM, Ox Cart <o...@getlantern.org> wrote:
It's exciting to think that censorship resistance could start making its way into standard Internet protocols!


- Marge Piercy


David Fifield

unread,
Jun 30, 2017, 6:46:51 PM6/30/17
to traff...@googlegroups.com
On Fri, Jun 30, 2017 at 05:53:10PM -0400, 'Vinicius Fortuna [vee-NEE-see.oos]' via Network Traffic Obfuscation wrote:
> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-02
>
>
> This document provides a way to authenticate one party of a Transport
> Layer Security (TLS) communication to another using a certificate
> after the session has been established. This allows both the client
> and server to prove ownership of additional identities at any time
> after the handshake has completed. This proof of authentication can
> be exported and transmitted out of band from one party to be
> validated by the other party.

Related to tls-exported-authenticator is Secondary Certificate
Authentication, which John Sarapata posted about in
https://groups.google.com/forum/#!topic/traffic-obf/bF61DndrA8I and
included a link to a talk by Nick Sullivan. The current version appears
to be

https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-04
Many HTTP servers host content from several origins. HTTP/2
[RFC7540] permits clients to reuse an existing HTTP connection to a
server provided that the secondary origin is also in the certificate
provided during the TLS [I-D.ietf-tls-tls13] handshake.
In many cases, servers will wish to maintain separate certificates
for different origins but still desire the benefits of a shared HTTP
connection. Similarly, servers may require clients to present
authentication, but have different requirements based on the content
the client is attempting to access.
This document describes a how TLS exported authenticators
[I-D.ietf-tls-exported-authenticator] can be used to provide proof of
ownership of additional certificates to the HTTP layer to support
both scenarios.
Reply all
Reply to author
Forward
0 new messages