[jdev] https://github.com/stpeter/manifesto and additional ideas

[Ralf Skyper Kaiser]

On Thu, Nov 14, 2013 at 4:24 PM, Dave Cridland <dave at cridland.net> wrote:

> On Thu, Nov 14, 2013 at 4:09 PM, Matt Miller <linuxwolf at outer-planes.net>wrote:
>
>>
>> On Nov 14, 2013, at 8:33 AM, Ralf Skyper Kaiser <skyper at thc.org> wrote:
>>
> > Example: I'm running a private jabber server with around 200 users. I
>> have strict a security guideline and currently have to trust my users to
>> follow it. I trust the users to verify the server certificate against our
>> own ROOT CA certificate.
>>  >
>>
>> Adding a new trust anchor is just about impossible on some mobile
>> platforms, and could get more difficult on more traditional ones.
>>
>>
> DANE, of course, means that you can specify a particular private CA is
> used exclusively.
>

Pinning does not require a CA at all (private or public). Why use a feature
(DANE) that requires a CA if it is possible to have the same level of
security with Pinning; which requires no CA, works well with self-signed
certificates, requires no infrastructure upgrade and which puts the direct
trust into the hands of the server-admins?



>
>
>>  > Users are lazy (quote). I ran a test and invalidated our server's
>> certificate. No user should connect if he follows the security guidelines.
>> Yet more than half of them connected instantaneously (auto-reconnect).
>> >
>> > Those users configured their client not to verify the server
>> certificate at all. Because configuring the client this way is easier than
>> importing the ROOT CA certificate.
>> >
>> > The lazy option is to not verify the server's certificate. The lazy
>> option is the insecure option
>> >
>> > Yes, the user can hack the client and lie about if the client has
>> correctly verified the server cert. This would take more time and work than
>> importing the ROOT CA certificate.
>> >
>> > The lazy option becomes importing the ROOT CA certificate. Now the lazy
>> option is the secure option.
>> >
>>
>> All it takes is for *one* (or a small handful) of your users to hack
>> their client, and share that hacked client with other users.  If the
>> platform the client runs on prevents new trust anchors from being
>> installed, then getting the hacked client becomes the lazy option.
>>
>>
Works for tech-wizards (which make up <0.01% of the internet). Why does
nobody care about the normal user who can barely open a .zip file and
requires telephone support installing any kind of software?

The lazy option for the user is not to hack the client or download a patch.
The lazy option is to select 'lockdown'.


>
> Actually, the lazy option is to not upgrade the client to support whatever
> private extension that supports the particular variety of lockdown and so
> on that you want in the first place.
>


1. The server admin has the option to ban old clients.

regards,

ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20131114/2facc496/attachment.html>