Message-ID: <a76a881cf244b8de2fda8aeef6a1d327@cetus.uberspace.de>
Date: Thu, 14 Apr 2016 00:54:19 +0200
From: Sebastian <sebb@...b767.de>
To: Árpád Magosányi <mag@...was.rulez.org>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] end of useable crypto in browsers?

Hey,

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

That's true. But the keygen element is flawed by the known-broken CA 
system(*) and you can't build a secure house on a broken foundation. You 
could check whether the certificate for your site is issued by your CA, 
but if the can issue certificates they could simply attack your browsers 
updater. Our only hope for truly secure communication are tools like pgp 
combined with anonymity through for example TOR or freenet (not the 
ISP).


(*) I'm not gonna expand on this since there's a lot about this already 
out there.

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

True, but this won't save <keygen>.


> Now we have window.crypto, which is nice and all, but it misses the
> basics: no real support for key management. [...] 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.

window.crypto is there to replace, not to assist <keygen>. It's truly 
saddening to see it dropped for a lesser alternative, but

TL;DR:
- hardly anyone uses it. Some are, but they obviously aren't enough as 
this argument has already been brought up. Ryan Sleevi (link below) 
said:
> Based on data seen from Google crawler (unfortunately, not public), the 
> number of sites believed to be affected is comically low.
- It doesn't reduce privacy that much since it relies on a broken system 
anyway and was hardly securing anything in the wild.
- Firefox and Chrome have the drop basically already in their nightlys, 
so the breaking point is not in front of us.

See this discussion about the support in chromium for a good write up 
about the drop motivations and above's quote: 
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/pX5NbX0Xack 
.


What I'm trying to say is that even though me, you and some others 
aren't happy about it, unless there is a really big con we all didn't 
see its time for a post mortem.

Greetings,
Sebastian


Am 2016-04-13 22:05, schrieb Árpád Magosányi:
> 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/
>> 

-- 

A great many of today's security technologies are "secure" only because 
no-one has ever bothered attacking them.
-- Peter Gutmann

_______________________________________________
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