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

Not saying not to pursue security or "more security than no security" What I'm saying is that both the choice of having security as well as the way in which it is achieved should not be a top down one-solution-fits-all decree by the W3C/TAG. I think web stack vendors should empower all kinds of solutions and approaches and the TAG/W3C should not promote just one model that it has determined to be the ultimate model but be all inclusive and give support and acknowledgement for other approaches (decentralized, hybrid, whatever) and  a chance of those models making it into the standards process upon maturing. I don't understand the fixation with TLS. 

DANE sounds good on the surface and so does the "certificate transparency" initiative (for CA auditing) 



Sent from my iPhone

> On Dec 30, 2014, at 1:57 PM, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote:
> 
> 
>> On 30 Dec 2014, at 21:19, Marc Fawzi <marc.fawzi@gmail.com> wrote:
>> 
>> 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 ...
> 
> Just as the philosophical skeptic argues from "there is no perfect knowledge" to 
> "there is no knowledge at all", your reasoning jumps from I am not "perfectly secure" 
> to there is no security to be had. Knowledge can always be overturned by new discoveries, but 
> one is a lot better off pursuing it than giving up. Similarly with any security measure
> you will always be able to find a way to imagine breaking it, and yet that does not
> stop it being a good idea to pursue security. 
> 
> Furthermore TLS is evolving, it is highly scrutinised, the issues of CAs is
> being taken into account with protocols such as IETF's DANE, which would allow
> one to put public keys in the DNS ( in addition to using CAs if one wishes to ),
> and there are many more things that can be done. TLS is not a static protocol.
> 
>> Security measures should be optional not enforced. If I wanted to live in a transparent tent then why not?
> 
> without TLS you may be in a tent but you have no idea if the people you are talking to
> are the ones you think they are, or if the communication has been altered along the way.
> So you are opening yourself to having beliefs about what people have said that are wrong,
> and since belief together with desires are constitutive of action, you may well come
> to do something that is rational to you but actually wrong, misguided and harmful to others.
> 
>> 
>> 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.
> 
> There are things being worked on such as DANE
> to help improve TLS and reduce even remove the reliance on CAs
> https://tools.ietf.org/html/rfc6698
> 
>>> 
>>>> 
>>>> 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.
> 
> How do you want to do that if everything along the way can be altered on
> an http connection, including headers, or any other information you want to
> put there?
> 
>>> 
>>>>> 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).
> 
> On the internet everyone is your neighbour, so the security intuitions you
> have in the real world don't apply anymore. In the real world you can count
> on their only being a certain amount of thieves in your neighborhood, and so
> little keys will do to keep a few people away. On the internet every thief
> is getting tools that are improving all the time to crack open your door,
> change your communication on route, etc... Small duck tape solutions won't do.
> 
>>> 
>>>> 
>>>>> 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?
> 
> The technological solutions don't exculde political, societla and educational
> ones. Clearly some issues need to be solved at other levels. The W3C is about
> protocols on the internet and it can work to make sure that part is secure.
> Of course others need to do their job too.
> 
>>> 
>>>> 
>>>> 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
> 
> Social Web Architect
> http://bblfish.net/
>

Received on Tuesday, 30 December 2014 22:27:59 UTC