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

[Matt Miller]

On Nov 14, 2013, at 9:34 AM, Ralf Skyper Kaiser <skyper at thc.org> wrote:

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

I suggest you read [RFC6698], particularly on cert usage 3.

Second, certs are only as trustworthy as the person accepting them allows for.  Pinning only kicks in after the user somehow accepts the cert the first time.  If it's not a certificate issued by one of the trust anchors the user's client knows about (or more pedantically, that an unbroken chain of issuance from the end-entity certificate to an established trust anchor), then the user has to click a "Accept this Cert" (most likely) or install a new trust anchor (unlikely, and becoming more so).

To mean, this means that pinning doesn't put all the trust into the hands of server-admins, but rather in the hands of users.

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

In which case obtaining the hack becomes the lazy option.


- m&m

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

[RFC6698] DNS-based Authentication of Named Entities (DANE) < http://tools.ietf.org/html/rfc6698 >
-------------- 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/aaabbdd4/attachment-0001.pgp>