Re: Fwd (TAG): Draft finding - "Transitioning the Web to HTTPS"

Chris Palmer wrote:
>
> Eric J. Bowman wrote:
> 
> > My problem with HTTPS, is the weakest link in the CA chain negates
> > any amount of money I pay Thawte for a cert, or get free from
> > anybody. The hoped-for trust model never materialized, although I
> > hear it's coming in Summer 2015 along with the latest blockbuster
> > superhero film...
> 
> For an attacker to get a publicly-trusted cert for a domain they do
> not own is not as hard as it should be, but it is also not trivial.
> 
> Certificate Transparency, and key pinning, make it difficult indeed.
> 

Not my point. A compromised or fraudulent CA breaks the system itself,
even for Thawte. Doesn't need to be a network attack, could be a
disgruntled employee, not that difficult.

Promoting a system to ubiquitous status just doesn't make sense when
the problems that system has, call for real solutions, not propagation
of those problems to become all-encompassing and that much harder to
solve down the road.

>
> You claim to be concerned about page integrity, but then advocate for
> a system that is guaranteed not to provide any.
> 

Not sure what you mean. What I advocated was a system that alerts both
content originators and content consumers, that said content has been
altered. Not guaranteed page integrity.

> > As to communicating with whom you're communicating, means exist to
> > detect content tampering from ISPs, Webhosts, black-hats, and even
> > end- users over HTTP:
> >
> > http://www.cs.washington.edu/research/security/web-tripwire/nsdi-2008.pdf
> 
> I hope you aren't seriously proposing that probabilistic weirdness
> detection system as a defense against a minimally sophisticated
> attacker.
> 

I proposed it as a basis for discussion, but yes, all I'm trying for is
a defense against minimally-sophisticated attackers (that's the bulk of
'em). I'm not suggesting it for my bank account, HTTPS is fine, there
(although I'd rather see authentication headers used than cookies).

>
> > Which also apply to HTTPS, because we aren't solving the content-
> > injection problem by going down that road, as the study shows.
> 
> It does not show that.
>

Yes, it does.

>
> Are you basing your claim on passages like this? :
> 

No, I'm not.

>
> """HTTPS encrypts web traffic to prevent in-flight modifications,
> though proxies that act as HTTPS endpoints may still alter pages
> without any indication to the server"""
> 
> Only HTTPS proxies that present certificates that the client trusts
> can do this. You may be reading it to mean that *any* HTTPS proxy,
> whether or not the client trusts it, can trivially alter page content?
> That is not the case.
> 

Users trust any old thing; real-world examples abound of how "security
gateways" knowingly installed by the end user (or their coporate IT
department) alter content. If those users knew their "trusted" devices
opened security holes, would they still install them? Or believe in
ubiquitous HTTPS as the solution if it simply means uninstalling those
devices?

>
> You appear to want a weak guarantee of non-authenticated integrity,
> and have no concern for strong integrity (which requires
> authentication), or confidentiality. Do I read you right?
> 

No. As I said, HTTPS will do for my bank account. But that's something
I don't want cached, even on my user-agent. What I want is a Content-
Md5 header that works with range requests, or some other solution to
the page integrity problem, whether or not I'm authenticated to the
server and vice-versa. Even for my HTTPS-protected bank account.

>
> If so, I'm sorry, but in 2015 we need more. We actually needed more a
> long time ago.
> 

Agreed.

>
> I encourage you to read more about cryptography and cryptographic
> network protocols, and to try your hand at subverting HTTP and HTTPS
> traffic (on your own systems and networks only, of course). I think
> you'll find that the available security guarantees and non-guarantees
> of HTTP and of HTTPS are very different from what you have expressed
> in this thread.
> 

Thanks, but I don't think you've understood what it is I'm trying to
express.

-Eric

Received on Tuesday, 30 December 2014 20:10:41 UTC