W3C home > Mailing lists > Public > www-tag@w3.org > January 2015

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

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Fri, 23 Jan 2015 16:59:00 +0200
Message-ID: <CAJQvAucovpTHSt4vXfTk+6AwdK2F3MegYXsYSteOquZbozajvg@mail.gmail.com>
To: "henry.story@bblfish.net" <henry.story@bblfish.net>
Cc: Public TAG List <www-tag@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Henry Thomson <ht@inf.ed.ac.uk>, Mark Nottingham <mnot@mnot.net>, Chris Palmer <palmer@google.com>, Noah Mendelsohn <nrm@arcanedomain.com>, "Michael[tm] Smith" <mike@w3.org>, Tim Berners-Lee <timbl@w3.org>, Paul Libbrecht <paul@hoplahup.net>
On Mon, Jan 19, 2015 at 3:44 PM, henry.story@bblfish.net
<henry.story@bblfish.net> wrote:
> 3. Unneeded cryptography
>
> First I think TLS has a mode with 0 encryption. This should of course be
> visible in the UI.
> ( just verification that the content has not been changed en route)
> This may cover some of the issues brought up, such as those related to
> encrypting large
> video files.

Large video files in quantities where the overhead of the symmetric
cipher in the straw that breaks the camel's back is very much a
special case. I think it doesn't make sense to enable more opportunity
for TLS misconfiguration to cater to that case.

For pretty much all other cases, blaming the symmetric cipher on
performance grounds doesn't make practical sense.

> 5. Client side certificates

I think this TAG finding should not get side-tracked into
https-related fringe features like client-side certs. In particular,
client-side certs are far worse a piece of technology for endorsement
than the parts of https that the draft finding currently endorses.
Specific problems include (not necessarily an exhaustive list):

 1) In currently-deployed versions of TLS, the most obvious way to
request a client cert results in the client cert being sent in the
clear, which exposes information that identifies the user to
eavesdroppers who can use this for surveillance or for targeting
malware injections. It's non-obvious to users that accessing an https
site leaks info like this when people have been taught that https
means that the connection is encrypted. I think this will remain a
major problem until server-side support for encrypted transfer of
client certs is so commonplace that browsers can start refusing to
send client certs in the clear.

 2) In the case of associated private keys stored on disk, syncing the
certs to all browsers that the user wants to use on all devices that
the user wants to use is a usability problem.

 3) Trying to fix that problem by storing the private keys on a
hardware device leads to driver problems and a ball-and-chain that (if
client certs were use more; fortunately they aren't) would limit the
progress of technology. (You can't stick a credit card-sized smart
card in a phone, for example. Good thing most people don't need to and
the mobile Web was able to take off. And, before you say "SIM",
consider wifi-only tablets, etc.)

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/
Received on Friday, 23 January 2015 14:59:27 UTC

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