chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florentine, George" <George.Florent...@flatironssolutions.com>
Subject RE: kCMISSessionAllowUntrustedSSLCertificate
Date Fri, 17 May 2013 15:55:10 GMT
I'd agree with Mike's assessment of the market drivers. We've seen the same kind of market
pressure in some work we've done in this space. Lots of developers and IT shops will use self
signed certs in dev environments. Any implementation that demands valid SSL certs will have
trouble getting deployed and adopted in the real world. At least, that's been our experience
for SDK level tooling we've done around remoting CMS capabilities to Android and iOS clients.


thx,

g


George Florentine 
VP, Engineering


Office:
+1.303.542.5173
Mobile:
+1.303.669.8628
Fax:
+1.303.544.0522





www.FlatironsSolutions.com
George.Florentine@FlatironsSolutions.com



-----Original Message-----
From: Mike Hatfield [mailto:mike.hatfield@alfresco.com] 
Sent: Friday, May 17, 2013 8:34 AM
To: dev@chemistry.apache.org
Cc: objective-cmis@googlegroups.com
Subject: Re: kCMISSessionAllowUntrustedSSLCertificate

Hi Peter,

The primary driver for this flag is to support app deployments for development environments
where the developers are building server-side applications (rather than mobile clients) and
using self-signed SSL certificates. The vast majority of these engineers just aren't skilled
in, nor tooled-up to implement *any* sort of iOS development, let alone to code and deploy
a new authentication provider in a library wrapped in a library wrapped in an app.

At Alfresco, we received many requests for our "Alfresco Mobile" app to support this scenario.
Whilst our app exposes this setting via user preferences, we were mindful that this is far
from ideal from a security standpoint - but had to weigh that against strong commercial drivers.
That's why this behaviour has been designed to be off by default and must very explicitly
be switched on during session creation; something app developers can choose to not expose
at all should they wish.

I believe not having this feature available at all would severely limit the usefulness of
any app built upon Objective-CMIS and, I fear, therefore similarly limit interest in the platform.

Regards,
Mike
-- 
Mike Hatfield
Lead Engineer, Mobile Apps
Alfresco Software, Inc.

On 17 May 2013, at 13:54, "Eberlein, Peter" <peter.eberlein@sap.com> wrote:

> Hi Peter,
> 
> I noticed the new session parameter, kCMISSessionAllowUntrustedSSLCertificate, that you
introduced. If set, server certificate validation is skipped so SSL connections to untrusted
servers can be established.
> 
> I don't think that we should have such a parameter. The world is already insecure enough
without encouraging people to deactivate essential security settings. If there is a need to
accept untrusted server certificates temporarily, like during development, than this can easily
be done by providing a custom authentication provider. This was already possible before this
change, without extending the standard implementation with insecure code. Or did I miss something?
I would feel a lot better if this whole "feature" was removed again and whoever needs to do
such messy things does them in own code in a custom authentication provider.
> 
> Or is it just me who is overly sensitive here? What does everyone else think?
> 
> Peter
> 
> 


Mime
View raw message