On Tue, Mar 20, 2012 at 9:15 PM, Robert Kaiser <ka...@kairo.at> wrote:
> David Chan schrieb:
>>
>> SSL doesn't protect us from a server compromise scenario. Though that
>> doesn't matter if the store is a permissions granter, since a
>> compromised store can just grant all permissions to rogue app X.
sorry, david, i missed this earlier. this is precisely why no store
should *ever* be a "permissions granter".
and it is precisely why i am advocating the use of the
(multi-layered) *people*-orientated PKI system known as "debian
package distribution".
when using such a people-orientated PKI system, the compromising of
an individual store is actually completely irrelevant.
> With real web apps, the server compromise scenario is probably the hardest
> to solve and I'm unsure how we could do it at all from our end.
yes. that's right. that's why i listed it as one of the (many)
problems with SSL that make SSL completely unworkable as a solution.
https://wiki.mozilla.org/Apps/Security#The_Problem_With_Using_SSL
using a host-based trust system (SSL) will simply make the hosts an
automatic target, as well as making the host(s) a
single-point-of-failure from either DDOS or simply sheer number of
downloads. even if if the private keys *can* be quickly distributed
across multiple hosts, in order to cope with an influx downloads, that
just increases the chances that the keys will be compromised.
in every way imaginable, SSL is without a shadow of doubt a complete
utter failure to help fulfil the requirements. i am finding it
difficult to comprehend why people even keep bringing it up.
> We should do some form of pinning at least, maybe revoking all permissions
> when the certificate (or just the issuer?) changes on an origin and asking
> those again from the user, with a notice that the issuer of the certificate
> is now X and was Y earlier, or something like that but less technical.
robert: i'm sorry, but i do have to laugh. please do not in the
slightest bit take this the wrong way. please do instead consider
this to be a funny joke, which i am sharing *with* you, rather than
being one who is laughing *at* you. i trust that you understand that
the difference is vital. one is a personal insult - tantamount to
technical bullying, which i have been on the receiving end of by many
"respected" free software community leaders who should know better, so
i would not dare EVER to do that which i myself find utterly
despicable.
i believe you are about the... maybe the 8th person since this
discussion began who has mentioned one or more aspects of SSL, who is
going through the exact same partial level of analysis, but hasn't yet
followed it all the way through. please don't take that in any way as
being insulting: it's just a statement of fact.
pinning is precisely what will make a particular host become a) a
target of attack b) a single-point-of-failure.
any further discussion of the use of host-based PKI security measures
are... well, they're not completely pointless, but... yes, they're
completely pointless *except* to highlight that the only safe
alternative is person-based PKI. as for example as implemented by the
debian distribution system.
i apologise to everyone who has to read this again and again, but
unfortunately again and again new people continue to advocate
host-based PKI security without comprehending that its use is
completely inappropriate and will result in endemic system failure and
expose both stores and the mozilla foundation to liability. and
ridicule.
> This all applies to permissions that can be granted to SSL-hosted apps only,
> others might be open to non-encrypted apps, e.g. geolocation in the current
> model.
>
> For the highly trusted permissions, like sending SMS, making calls, or
> managing permissions, I think trusted-store-only is a good idea (in addition
> to SSL, maybe even EV).
1) what are the reasons why you believe that a trusted-store-only
should be the sole allocator of "highly trusted permissions"?
2) could you please describe some of the high-level implementation
details and provide an analysis which shows that the implementation
fulfils the requirements ( as listed here -
https://wiki.mozilla.org/Apps/Security#Requirements )
3) please could you describe how the trusted-store-only model shows
resilience to attack and also recovery? in particular is one question
that needs answering: who - which person or organisation - will be
legally responsible, held accountable and pay the bill for taking out
massive indemnity and liability insurance to cover class-action
lawsuits should this trusted-store-only become compromised, given that
the consequences of compromise are so severe?
i am having some difficulty here. it is almost as if there is like a
parallel universe. one in which SSL is imagined to be the "absolute
solution". i cannot be the only person on these lists who can think
things through clearly enough to know that the use of SSL will be a
complete failure.
surely there must be _somebody_ on these lists who knows that SSL can
in no way be utilised to fulfil the requirements?
l.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
