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

> On 23 Jan 2015, at 15:59, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
> 
> 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.

As TLS with no encryption is possible, it does seem like this should
in any case be visible in the User Interface of browsers. It would
be interesting to know if it would indeed help with large video files,
which seems like something that should be testable.

> 
>> 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.

I think TLS re-negotiation does not have that problem.
That is what I propose in step 4 of WebID-TLS
http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence


If there are further bugs they should be fixed. That goes for every
other technology.

> 
> 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.

There is no need with WebID-TLS to use the same certificate for each
client. Each client can using the html keygen element create a certificate
in one click in a form. This is explained in more detail here

http://www.w3.org/2005/Incubator/webid/spec/tls/#certificate-creation

There is a video of how it works on http://webid.info/

> 
> 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.)

That is solved by the previous problem. 

I can see a good place for keys using X509 certificates with WebIDs 
to open house doors and cars though.

Henry


> 
> -- 
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/

Social Web Architect
http://bblfish.net/

Received on Thursday, 29 January 2015 15:07:04 UTC