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

On Sat, Dec 20, 2014 at 2:04 AM, Eric J. Bowman <eric@bisonsystems.net> 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.

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

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

> 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. Are you basing your claim on passages like this? :

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

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?

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

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.

Received on Monday, 22 December 2014 18:45:27 UTC