Secondary Cert Authentication.

John Sarapata

unread,

Dec 14, 2016, 11:51:46 AM12/14/16

to Network Traffic Obfuscation

I have been tracking some of the objections to Domain fronting from the Chrome team. They have pretty compelling arguments that it a security hole and an abuse of the protocol.

Cloudflare has a proposal that seems to address a number of objections by allowing an in stream way for a CDN to prove it owns additional certs using some of the capabilities in HTTP2.

There is an overview here: https://youtu.be/8bnF78lEZGk

But Nick tells me he will be tweaking the idea after speaking to a few of the browser people. Has anybody given this a deeper look?

John

Adam Fisk

unread,

Dec 14, 2016, 2:52:14 PM12/14/16

to John Sarapata, Network Traffic Obfuscation

Very cool John thanks! Super promising for a more secure version of
domain fronting within HTTP/2.

Can you enumerate the security concerns of the Chrome team with
traditional domain fronting in more detail? Is any of that discussion
public? There's really no disputing it's an abuse of the protocol, and
clearly the fact that you're accessing a site that's different from
the site you're authenticated against is at the very least
interesting. I suppose if the destination site is the attacker, it
could theoretically serve whatever it wants (zero days and whatnot) as
if it's the authenticated site.

In practice domain fronting has been primarily used to access
proxies/relays living on specific CDNs, but all of that domain
fronting trickery happens within the client software, and the browser
ultimately gets all the correct certs that are all ultimately
tunneled. Maybe there are injection attacks with HTTP traffic on those
proxies depending on the destination? Still from the browser's
perspective it is actually the real site, however, so not sure how
that's any better an attack than just deploying a zero day on any
given random site you own out there. Just brainstorming here...

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
--
President
Brave New Software Project, Inc.
https://www.getlantern.org

Tom Ritter

unread,

Dec 14, 2016, 3:41:09 PM12/14/16

to Adam Fisk, John Sarapata, Network Traffic Obfuscation

On Dec 14, 2016 1:52 PM, "Adam Fisk" <af...@getlantern.org> wrote:

Can you enumerate the security concerns of the Chrome team with
traditional domain fronting in more detail? Is any of that discussion
public?

++

I'm confused why Chrome is so upset about it, since it doesn't affect them at all... (AFAICT). I could understand whomever runs AppEngine or other CDNs...

-tom

Lucas Dixon

unread,

Dec 14, 2016, 3:53:46 PM12/14/16

to Tom Ritter, Adam Fisk, John Sarapata, Network Traffic Obfuscation

I imagine the objection is that sharing certs widens the attack surface and breaks the chain of mechanisms that give you trust that you are connecting only to the site you want to. So I think the point is that it's bad for the internet as a whole if lots of sites share certs. I can think of lots of ways it can go wrong: e.g. a broken routing rule in the CDN, etc. Preserving end-to-end encryption makes browsers more secure. So I guess that's the kind of thing discussed... ?

--

Tom Ritter

unread,

Dec 14, 2016, 4:00:51 PM12/14/16

to Lucas Dixon, John Sarapata, Network Traffic Obfuscation, Adam Fisk

Ah okay. Similar concerns to the 2014 vhost confusion attacks, except domain fronting hasn't been shown to be exploitable in browsers (yet?).

To unsubscribe from this group and stop receiving emails from it, send an email to traffic-obf+unsubscribe@googlegroups.com.

John Sarapata

unread,

Dec 14, 2016, 4:20:17 PM12/14/16

to Tom Ritter, Lucas Dixon, Network Traffic Obfuscation, Adam Fisk

The team cares deeply about secure transfer, which shows in actions like forcing HTTPS, pushing certificate transparency, pushing back on sha1 certs and no longer trusting a big cert authority in China.

The overriding concern was that swapping the host header breaks the same origin model that is the basis of all their security assumptions. It isn't clear how much things will break.

I'm not convinced the browser will get both certs. In Chrome, both sites would share the same stream with the same ephemeral key. I don't think TLS is reinitialized when the host changes the way it did for domain fronting. There was also a concern about mixing streams because it is trivially easy to escape framing unless you are using HTTP 2.

I'm probably not doing the arguments justice, but this is my rough understanding. Another nice thing about the proposed spec is that it gives a solid performance argument to enable the type of stream sharing a technique like domain fronting needs. Some companies would benefit from a little plausible deniability.

John

To unsubscribe from this group and stop receiving emails from it, send an email to traffic-obf...@googlegroups.com.

Ox Cart

unread,

Dec 14, 2016, 4:27:37 PM12/14/16

to John Sarapata, Tom Ritter, Lucas Dixon, Network Traffic Obfuscation, Adam Fisk

Hi John,

Nice to meet you!

I'm not convinced the browser will get both certs. In Chrome, both sites would share the same stream with the same ephemeral key. I don't think TLS is reinitialized when the host changes the way it did for domain fronting. There was also a concern about mixing streams because it is trivially easy to escape framing unless you are using HTTP 2.

That depends on the implementation. In some implementations, the usual TLS tunnel still exists, it's just layered on top of another one.

1. Establish tunnel

Browser --HTTP CONNECT--> Local Proxy --domain front--> CDN --TCP or TLS--> Remote Proxy --> Origin

2. Establish TLS connection to origin using CONNECT tunnel from step 1

Browser --TLS--> Origin

The domain fronting stuff is only used for establishing the underlying CONNECT tunnel, the browser's connection to the origin is still encrypted end-to-end without any shenanigans.

Cheers,

Ox

PGP Key - https://pgp.mit.edu/pks/lookup?op=get&search=o...@getlantern.org

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

"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

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.

--

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.

John Sarapata

unread,

Dec 14, 2016, 4:46:59 PM12/14/16

to Ox Cart, Tom Ritter, Lucas Dixon, Network Traffic Obfuscation, Adam Fisk

Ox, nice to meet you. When you discuss implementations, are you taking about domain fronting implementations or browser implementations?

I also probably worded it badly. I think the engineers I was talking to don't have an issue with summation fronting. The issue is with allowing the header to differ from the SNI. They are probably worrying about how it would be possible to attack that behavior more than specific domain fronting issues.

But I should add to all of this that I'm not a TLS expert. I was just trying to pass along an interesting spec that could do something like domain fronting. Watching the talk, it also allows for encrypted SNI. The author suggests using an IP signed cert for the first connection, and then exchanging the SNI.

John

To unsubscribe from this group and stop receiving emails from it, send an email to traffic-obf...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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...@googlegroups.com.

Ox Cart

unread,

Dec 23, 2016, 9:09:05 AM12/23/16

to John Sarapata, Tom Ritter, Lucas Dixon, Network Traffic Obfuscation, Adam Fisk

Hi John,

Sorry for the slow reply. By implementations, I meant domain fronting implementations, like enproxy.

Thanks for passing along this very interesting info!

Cheers,

Ox

PGP Key - https://pgp.mit.edu/pks/lookup?op=get&search=o...@getlantern.org

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

"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

On Wed, Dec 14, 2016 at 3:46 PM, John Sarapata <jsar...@google.com> wrote:

Ox, nice to meet you. When you discuss implementations, are you taking about domain fronting implementations or browser implementations?

I also probably worded it badly. I think the engineers I was talking to don't have an issue with summation fronting. The issue is with allowing the header to differ from the SNI. They are probably worrying about how it would be possible to attack that behavior more than specific domain fronting issues.

But I should add to all of this that I'm not a TLS expert. I was just trying to pass along an interesting spec that could do something like domain fronting. Watching the talk, it also allows for encrypted SNI. The author suggests using an IP signed cert for the first connection, and then exchanging the SNI.

John

On Wed, Dec 14, 2016, 4:27 PM Ox Cart <o...@getlantern.org> wrote:

Hi John,

Nice to meet you!

I'm not convinced the browser will get both certs. In Chrome, both sites would share the same stream with the same ephemeral key. I don't think TLS is reinitialized when the host changes the way it did for domain fronting. There was also a concern about mixing streams because it is trivially easy to escape framing unless you are using HTTP 2.

That depends on the implementation. In some implementations, the usual TLS tunnel still exists, it's just layered on top of another one.

1. Establish tunnel

Browser --HTTP CONNECT--> Local Proxy --domain front--> CDN --TCP or TLS--> Remote Proxy --> Origin

2. Establish TLS connection to origin using CONNECT tunnel from step 1

Browser --TLS--> Origin

The domain fronting stuff is only used for establishing the underlying CONNECT tunnel, the browser's connection to the origin is still encrypted end-to-end without any shenanigans.

Cheers,
Ox

PGP Key - https://pgp.mit.edu/pks/lookup?op=get&search=ox@getlantern.org

- Marge Piercy

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.

--
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.

Reply all

Reply to author

Forward