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

Well said Eric

It's all theatrics, emperor's new clothes and such ... 

There is no such thing as perfect security and yet we are supposed to incur the cost of https everywhere because it's "more" secure, only to be proven "Swiss Cheese" with the next big headline ... Security measures should be optional not enforced. If I wanted to live in a transparent tent then why not? 

Sent from my iPhone

> On Dec 30, 2014, at 12:10 PM, "Eric J. Bowman" <eric@bisonsystems.net> wrote:
> 
> 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 21:19:57 UTC