Date: Wed, 13 Apr 2016 22:05:51 +0200
From: Árpád Magosányi <mag@...was.rulez.org>
To: sebb@...b767.de
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] end of useable crypto in browsers?

On 04/13/2016 05:09 PM, Sebastian wrote:
> Hey,
>
>> This is not a security vulnerability in itself, "just" a trend
>> undermining the trust architecture of the whole internet :)
>> [...]
>> Any ideas on how to make them understand the scale of the doom we are
>> facing right now?
>
> to put it simply: No.
>
> The real problem is that no one is using it. Yes, it is pretty secure,
> but its too much trouble for most users (try to log in from your
> phone) and also a baseless PITA for most server operators. It's also
> not good for business (you need to be able to restore the certificate
> easily, have multiple devices, all your servers need https ...). To
> make matters worse many browser don't even bother supporting it
> (looking at you, internet explorer^W^Wedge).

No doubt keygen have its problems. But there should be a bit more reason
for entirely removing a technology which is needed than "it is not
mature enough yet".
One reason that the whole symmetric crypto technology could not mature
because getting key deployment right is not a straightforward task
(fscked up trust relationship did not help either, but that is an issue
which we can work around. With smart key management. Oh, wait...) . And
keygen was the easiest and most cross-platform way for key deployment.
Now we have window.crypto, which is nice and all, but it misses the
basics: no real support for key management.

>
> To be fully honest, I'd prefer to keep it. Yes, browser support is bad
> and hardly anyone uses it, but it doesn't hurt anyone and at least
> there are/were some users (i.e. StartSSL). But to truly convince them,
> you'd probably need
> a) support from at least a major browser. If the other "cool kids"
> don't do it, good luck getting this through.

I doubt Microsoft will drop its ActiveX based key management support in
the browser. So there will be one player who does not pull the feature.
I never thought I will depend on Microsoft for anything...

> b) an example of the "doom" we're facing, because neither them nor me
> sees it. The web would hardly be less secure, same as if we'd drop
> SQRL: Yes, it's pretty secure as far as I can tell, but who is using
> it and would therefore be less secure anyway?

The Doom:
The browser developers have just decided that the trust relationship
architecture of the virtual world will be driven by the copyright
dinosaurs  from now on, by pulling off platform support from under those
who were experimenting with building meaningful trust models with the
admittedly few tools we already had.
I do understand that I will shortly refer to soft and future things, and
use big words. However I not just mean it, but also able to reason it
right from the basics of communication theory:
The sociological and political fabric of society fundamentally depends
on our communication abilities(*). The future of our communication
abilities in turn depends on the communication platforms and the trust
relation models they support. And that not necessarily need to be
facebook and browsers with cryptographic support just enough to deny you
access to content you actually bought.

(*) See Elon Musk's reasoning when he was asked about future Martian
politics for an easily understandable pitch on the topic. And look up
Dunbar's number and Condorcet.

Who uses it: There are some well established services. Cacert.org uses
keygen (and ActiveX for Microsoft browsers). Just like a host of "old
school" CAs.
I am for one developing a community service, which aims to be the link
between IRL and virtual personality, by providing anonimity while making
sure that one person can have only one account. One of the features of
the platform is ssl authentication with in situ generated keys. My plan
was to drive this further to provide a CA, building on the already
existing assurance programme behind the platform. And others also
experiment with ways to transcend the X509 trust model.
There are a lot of works out there developing a) special purpose tools
using cryptography, and b) tools using the browser as UI platform, both
related to privacy, social and political collaboration and similar
purposes. This split is because a browser without plugins is b) the only
meaningful way to reach broader user population and a) does not provide
the necessary cryptographic primitives. This is a very tough and
honestly totally unnecessary design decision. With window.crypto, we at
last have the primitives, minus the key management ones. But their
infrastructure already exist in the browsers behind <keygen>. We should
just do a small step ahead to enable the key management for
window.crypto, thus the convergence of the above experiments.
It seems that browser developers now want to abandon <keygen>, and thus
also make all the work put into window.crypto meaningless. This seems to
be an extremely bad decision from where I stand.

>
> Here's a related discussion:
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/pAUG2VQ6xfQ/FKX63BwOIwAJ
> .
>

Thank you for the pointer. It is sad to see how highly intelligent
people fail to see the harm they cause.

> Greetings,
> Sebastian
>
> Am 2016-04-09 11:34, schrieb Árpád Magosányi:
>> Hi,
>>
>> This is not a security vulnerability in itself, "just" a trend
>> undermining the trust architecture of the whole internet :)
>>
>> I think it is very important, and wonder why I don't see any discussion
>> of it. If this is not the right forum to discuss it, please direct me to
>> the right place.
>>
>> The problem is:
>>
>> Browser developers are dropping support for X509 key generation.
>> Yes, <keygen> have its problems. But window.crypto - which is meant to
>> replace it - have no way to save keys in the browser's keystore.
>>
>> Instead of going to some cross-browser and cross-OS support for key
>> management, we are now in a state where there are browser/OS
>> combinations (stable chrome with non-windows OS), where there is no way
>> to generate and store a key to be later used for ssl authentication.
>>
>> Looking at the related bug reports it seems that browser developers do
>> not even understand the problem this creates.
>>
>> Any ideas on how to make them understand the scale of the doom we are
>> facing right now?
>>
>>
>> _______________________________________________
>> Sent through the Full Disclosure mailing list
>> https://nmap.org/mailman/listinfo/fulldisclosure
>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists