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

Sorry for interjecting, but this has been on my mind for a while and
thought I should share it, in hope of getting some clarity.

Could Web Crypto API be used in a symmetric way where the content provider
and user exchange public keys (e.g. upon user registration) and they simply
use each other's keys to encrypt NOT EVERY request and response but only
the parts of the content being exchanged in both directions that has
sensitive information? Is it conceivable that when Web Crypto is available
on all major browsers that we could see application-level security that is
less costly on the servers than encrypting every request and response? But
more importantly, would that be more secure than HTTPS in that it will be
immune to MITM attacks?





On Mon, Dec 8, 2014 at 11:03 PM, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
wrote:

> On 2014/12/09 13:09, Mark Nottingham wrote:
>
>>
>>  On 9 Dec 2014, at 11:57 am, Noah Mendelsohn <nrm@arcanedomain.com>
>>> wrote:
>>>
>>> II. Privacy
>>>
>>> I also have the vague impression that there is a loss of privacy that
>>> indirectly results from the reduced practicality of proxies, but I'm not
>>> sure that intuition is correct. If there are privacy issues with the HTTPs
>>> transition, that would be worth exploring too.
>>>
>>
>> Is the thought here that it's harder to view what's happening on the wire
>> between your browser and the server, and thus harder to verify that a site
>> isn't abusing your private data, etc.?
>>
>
> That's one aspect. Another is that if many of the requests don't go to the
> origin, the origin and the network at large knows less about browsing
> habits. That's a plus if the users can trust their local network (up to the
> proxy) more than the origin and the worldwide network. On the other hand,
> these days most pages come with all kinds of beacons and stuff embedded
> anyway, and in that case, page access leaks beyond the proxy anyway.
>
> Regards,   Martin.
>
>