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

Eric J. Bowman wrote:
>
> 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.
>

And that's what's truly scary about last week's Komodia kerfuffle. Lack
of imagination. I often get stuck fixing friend-n-family computers, so
I've been deleting "Window Shopper" Superfish root certs for 4-5 years,
now. Just never occurred to me to try some script-kiddie-level reverse-
engineering on that, or any other suspicious cert, I've ever removed.

D'oh.

I shudder to think how many years massively-stupid certs have been mass-
exploited by those imaginative hackers who know how to keep their mouths
shut. That being said, what I think is the "right" direction for the Web
(really just a starting point), which I've hinted at in the quoted post
and others, at least requires HTTPS to be end-to-end.

What I'm now trying to figure out, is how to protect Web (not computer)
users, such that CA issues are taken beyond the purview of end-users and
dropped squarely in the laps of sysadmins. At least on the Web. But I'm
still thinking about it in terms of securing Authentication headers, to
enable intermediary participation rather than forcing those developers
to break the entire CA system (or any band-aids on it, or its successor)
in order to stay in business.

Although I suspect Roy's already more-or-less figured this out in Waka.

With the aside, that PuTTY access to my server is more restricted than
ever, in that I now first launch a VMware instance with a total of two
root certs in its CA. My ssh login: prompt does nothing, and I don't
lose any sleep at night over its being secured by TLS, I'm no fanatic.
You'd still need to beat the 61-char key password out of me, plus have
physical access to the only IP address it'd be accepted from, if you
had that file. I'd rather have that level of security accesing my bank
account, than what my bank currently provides me.

SSL has its place, but not on every Web connection.

-Eric

>
> 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 Monday, 23 February 2015 01:52:37 UTC