Re: Alt-Svc Privacy Concerns

On Sun, Apr 10, 2016 at 8:00 PM, Erik Nygren <erik@nygren.org> wrote:

> On Sat, Apr 9, 2016 at 1:41 PM, Phil Lello <phil@dunlop-lello.uk> wrote:
>
>> I'm concerned that Alt-Svc, especially used like this, is re-introducing
>> the sort of privacy issues people have been trying to eliminate with
>> cookies for years. Appologies if this has already been discussed and I
>> missed it.
>>
>
> I don't see the issue here really being with Alt-Svc. Rather, this is
> another issue/risk with consolidating requests for multiple origins onto a
> single TLS connection that has a valid cert for all of the origins. (I
> don't think this was on my list in the slides in B.A. in discussion of the
> ORIGIN frame and related topics, but is certainly in that class I'd
> issues.)
>
> I'm not sure I see how Alt-Svc actually makes this worse by itself.  I do
> agree that when we look at the proposal for adding additional allowed
> server certs to a connection that this will certainly be something we'll
> want to discuss in more detail (although that is also orthogonal from
> Alt-Svc).
>
> You may be right that the real issue is more widespread and affects
re-using the connection for multiple origins in general; I was thinking
about Alt-Svc when this attack vector occured to me. It's the stealth
factor of the Alt-Svc redirection that troubles me, but I suppose it's no
more inherently risky than aggregation when two or more servers resolve to
the same IP. That said, it's more complex to casually detect, as a quick
dig/nslookup will show if two server names are pointing to the same
destination; with Alt-Svc it becomes necessary to make an HTTPS request,
inspect headers, then check the IP addresses.

I have similar stealth concerns about the ORIGIN frame, since by
potentially eliminating DNS lookups it adds to the complexity of auditing
which services information is potentially shared across (e.g. if tabs to
a.com, b.com are open and using two connections, and a new tab opened to
c.com reuses a connection, is the data available to a.com or b.com?).


> A general point (which goes as much to UI behavior as anything) is that
> the Secure Connection Info tab in many browsers only shows the CN and
> buries the SANs below what users might normally see.  (And even in today's
> world, resources embedded in pages are also typically not something users
> see and provide many opportunities for active linking of users, such as
> through URIs.)
>

Yes, I agree we've already got lots of attack vectors for tracking users
without consent, and that's something the industry needs to work on
eliminating, both via the IETF and the W3C. However, UI/UX guidance for how
and when to display certificate chains and related warnings feels like the
IETF's domain to me, since it's the IETF providing the transport
protocol(s).