W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2014

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

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Tue, 30 Dec 2014 19:05:07 -0700
To: Chris Palmer <palmer@google.com>
Cc: Marc Fawzi <marc.fawzi@gmail.com>, "henry.story@bblfish.net" <henry.story@bblfish.net>, Nick Doty <npdoty@w3.org>, David Singer <singer@apple.com>, TAG List <www-tag@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-Id: <20141230190507.7045cd91cc01cae078be4b3b@bisonsystems.net>
Chris Palmer wrote:
> Eric J. Bowman wrote:
> >> TLS is the transport layer security protocol we have. It is widely
> >> supported and deployed.
> >
> > So is HTTP-Digest. Whether content is encrypted or not,
> > Authentication headers seem a better solution to me than
> > HTTPS-secured cookies.
> Please explain how HTTP-Digest is robust against active network
> attackers tampering with the HTTP requests and responses (including
> both headers and bodies).

Please explain how HTTPS is robust against same. A compromised CA or a
compromised "security device" allows attackers to tamper with HTTPS
requests and responses on a large scale, as easily as if it were HTTP.

What's needed is an integrity check; if we had one, HTTP Auth would be
no less effective than HTTPS for the bulk of traffic we're trying to
keep private.

Checking my bank account would still require HTTPS, but the same missing
mechanism for ensuring that's really an unadulterated page from my bank,
could also be used to mitigate most of the concerns regarding "brochure"
content that doesn't need TLS encryption.

Received on Wednesday, 31 December 2014 02:05:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:28 UTC