Re: Verizon Wireless ISP-injected tracking info used to reconstruct deleted cookies

Henri Sivonen wrote:
>
> Paul Libbrecht wrote:
>
> >
> > One thing that this practice, of providers transparently proxying
> > http traffic, bothers is when people try to use both http and https.
> 
> That's a bad idea. To have a secure site, http should only redirect to
> https and https should enable HSTS and the secure flag for cookies.
> 

Disagree. One can always eschew cookies in favor of Authentication
headers. In which case a digest obtained via HTTPS may be utilized for
HTTP traffic without disabling caching. Indeed, such a strategy enables
caching of both "you must login" messages _and_ member content, without
precluding the personalization of cached content for members.

If there's a security hole there, it isn't one I've imagined or seen
documented. What I can't say, is if that makes it inherently secure, or
obscurely secure -- but that does seem worthwhile to investigate. Unless
I'm the only one who thinks the anointing oil for ubiquitous HTTPS is
being rather hastily applied.

> 
> That's a bad idea. To have a secure site, http should only redirect to
> https and https should enable HSTS and the secure flag for cookies.
> 

Secure? Or confidential/private? If we're talking privacy, then I have
to point out that scientifically, other methods ought to be falsified
before assertions are made that HTTPS/HSTS are required, especially if
that requirement is based on an assumption that cookies are required.

>
> > On a website I develop for, users submit their login using https,
> > but
> otherwise http is used.
> 
> In this case, the attacker can capture the session cookie instead of
> the password, which makes this setup a bad idea.
> 

Assuming cookies are used, let alone required. IMHO, it seems ubiquitous
HTTPS is advocated mostly to secure those cookies. Which is irrelevant
to me as I use Authentication headers, as per the HTTP spec and not some
notion of extending it that's been borked for going on 20 years now. Of
course cookies aren't secure, but why does that lead anyone to believe
that band-aiding them with HTTPS is the solution? Sorry, I still just
don't get it.

>
> Since you have obtained a cert and configured https, why not go 100%
> https?
> 

The primary reason remains, to me, caching -- at least until Net Neut
is set in legal stone (and likely still, even then). If I obtain a
*digest* via HTTPS, not only are efforts to compromise it via HTTP
detectable, but traceable as well. Making it improbable, but not
impossible, to bypass as an attack vector -- which I see as "good
enough," since I don't find perfect to be obtainable.

If a browser can detect altered content and HTTP auth digests (and I
have no reason to believe they can't), then can't a UX be devised
accordingly, which doesn't condition end-users to opt in to the very
MitM attacks ubiquitous HTTPS is supposed to protect against?

>
> > Login fails on these networks, because the cookie is attached to
> > the IP. I am not sure we are alone doing this kind of ping-pong,
> > are we?
> 
> Using https for password submission and letting the cookie to travel
> over an channel that allows trivial intercept is a common
> anti-pattern, yes, unfortunately.
>

Which doesn't make it a bad pattern, per se. Only improperly implemented
by using cookies instead of Authentication: headers. Nobody's ever
explained to me why using this pattern to obtain an Authentication:
header instead of a cookie, for subsequent HTTP use, is a Bad Thing.

-Eric

Received on Thursday, 22 January 2015 01:42:50 UTC