W3C home > Mailing lists > Public > www-tag@w3.org > December 2014

Re: Draft finding - "Transitioning the Web to HTTPS"

From: Marc Fawzi <marc.fawzi@gmail.com>
Date: Sun, 21 Dec 2014 10:14:16 -0800
Message-ID: <CACioZisQTfM+nux3W_yK3p_ekG_r=BwHWm8v1FYxLHeb2jNdag@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Domenic Denicola <d@domenic.me>, Tim Berners-Lee <timbl@w3.org>, "Eric J. Bowman" <eric@bisonsystems.net>, Chris Palmer <palmer@google.com>, Melvin Carvalho <melvincarvalho@gmail.com>, Public TAG List <www-tag@w3.org>
This should pass the giggle test, no?

(tiny text, zoom to read)

On Sun, Dec 21, 2014 at 9:56 AM, Marc Fawzi <marc.fawzi@gmail.com> wrote:

> I have actually been consulting with a friend who is the chief security
> expert at a famous public company (cloud infrastructure) and he thinks
> people on this list are narrow minded as there are plenty of opportunities
> to design a decentralized security model, not one that would necessarily
> replace https but could use it to download the script securely (as a
> browser extension) and then use it to implement a secure decentralized
> security model that would work over http.
>
> Neither of you have responded to the question of why browser extensions
> downloaded securely and relying on web crypto or native apps couldn't
> implement a decentralized security model. You say convergence.io suffers
> from lack of performance and you throw arbitrary statements like "giggle
> test" at a very similar idea.
>
> That friend, who had written books on the subject of network security and
> like I said is in higher regard in this field than most if not all "wanna
> be security experts" on this list, is willing to take to the blogosphere to
> write about this and to use this thread as a reference. I might take him up
> on his offer now that I see the resistance is not logical but ideological.
> I had more hopes in the "TAG" I honestly did, until the "giggle test" was
> thrown out there. How ridiculous and juvenile of you to demean rather than
> argue against each given point. I do admit that my argument was lacking but
> I kept refining it based on your input until it got to the point of "hey if
> convergence.io can do it with a plugin downloaded via https and used over
> http" then why couldn't everyone else do the same and experiment with the
> innovative and exciting models timbl mentioned? Why not? What is your
> security expert alter ego telling about it's a bad idea?
>
> Thank you.
>
> Marc
>
> On Sat, Dec 20, 2014 at 1:50 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> +1 here. This sort of approach isn’t likely to pass the giggle test in
>> any security community, not only because of bootstrapping, but also because
>> of the homemade crypto problem.
>>
>> WRT “blanket the whole web” — I want to emphasise that the goal here is
>> not to make everyone deploy TLS against their will; it’s to a) make sure
>> that TLS is used for features that expose powerful features, and b) reduce
>> the barrier to entry to using TLS. This gets us to a place where *more* of
>> the Web uses TLS, which means that more private data, behaviour, etc. is
>> protected — and it also means that there’s a stronger ecosystem of
>> crypto-using sites, making things like pervasive monitoring more difficult
>> as well. If a site really wants to use unprotected HTTP and don’t need to
>> use any new powerful features, they’ll still be able to.
>>
>> Cheers,
>>
>>
>> >
>> > Why are you so intent on reinventing secure transport with WebCrypto?
>> Is this some sort of everything-must-be-JavaScript thing?
>> >
>> > We have a system that works. Use it. Don't reinvent a new one, spend
>> ten years discovering the myriad of flaws, and then another twenty trying
>> to get wide adoption.
>> >
>> > I really see no reason to "help out" with this quixotic campaign.
>> >
>> > -----Original Message-----
>> > From: Marc Fawzi [mailto:marc.fawzi@gmail.com]
>> > Sent: Saturday, December 20, 2014 08:27
>> > To: Domenic Denicola
>> > Cc: Tim Berners-Lee; Eric J. Bowman; Chris Palmer; Melvin Carvalho;
>> Mark Nottingham; Public TAG List
>> > Subject: Re: Draft finding - "Transitioning the Web to HTTPS"
>> >
>> > Domenic
>> >
>> > What Tim laid out is exactly why I'm excited about web Crypto, but you
>> have a point about the initial download of whatever system implemented on
>> top of it.
>> >
>> > What if the system was built into a Chrome extension and downloaded via
>> https from the Chrome Web Store? I had a chat with the developer behind
>> AdBlock and he actually wrote a script to check periodically to make sure
>> his extension on the Chrome store hasn't been replaced with a non-official
>> version. He said its for potentially rogue employees. He had hired some
>> developer(s) to take over the development of the plugin. In the same way,
>> plugin developers can release sensitive plugins on the chrome web store and
>> users can be sure that they're downloading the valid version (via https)
>> After that, everything Tim said (which is inspiring btw) should be
>> implementable and can work over http.
>> >
>> > So can we just not go knee-jerk and blanket the web with https when it
>> may only be needed in a few places (assuming web crypto based systems will
>> be developed as built in browser functionality or as plugins downloaded
>> from browser vendor's store?)
>> >
>> > Help us out here!
>> >
>> > Sent from my iPhone
>> >
>> >> On Dec 19, 2014, at 7:51 PM, Domenic Denicola <d@domenic.me> wrote:
>> >>
>> >> From: Tim Berners-Lee [mailto:timbl@w3.org]
>> >>
>> >>> Yes, but once the webcrypto code is unpolyfilled into the browser
>> that attack will go away, and you will be able to use it to build new trust
>> systems, right?
>> >>
>> >> No, sad to say. Since the network attacker could modify whatever
>> JavaScript code you are using to implement those trust systems, or could
>> even simply insert something like
>> >>
>> >> Object.defineProperty(window.crypto, "subtle", {
>> >> get() {
>> >>   return new CompletelyFakeWebCryptoImplementation();
>> >> }
>> >> });
>> >>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>

monkey.jpg
(image/jpeg attachment: monkey.jpg)

Received on Sunday, 21 December 2014 18:15:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:08 UTC