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

[Matt Miller]

On Nov 14, 2013, at 9:24 AM, 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.
>  

It also means that the particular trust anchor is limited to the service in question, which is very nice.  And this all assumes DANE is supported and deployed.

In the actual world, the lack of DANE means users have to install a new trust anchor.


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

This is certainly true.  I was assuming that somehow the original poster coerced all of his users onto "LockDown"-enabled clients, which is even less likely than getting them to add a new trust anchor.


- m&m

Matthew A. Miller
< http://goo.gl/LK55L >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://www.jabber.org/jdev/attachments/20131114/7e5fa313/attachment.pgp>