kCMISSessionAllowUntrustedSSLCertificate

["Eberlein, Peter" <pe...@sap.com>]

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

RE: kCMISSessionAllowUntrustedSSLCertificate

["Florentine, George" <Ge...@flatironssolutions.com>]

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" <pe...@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
> 
> 

Re: kCMISSessionAllowUntrustedSSLCertificate

[Mike Hatfield <mi...@alfresco.com>]

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" <pe...@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
> 
> 

Re: kCMISSessionAllowUntrustedSSLCertificate

[Peter Schmidt <pe...@alfresco.com>]

Hi Peter
many thanks for your comments. As I am about to leave Alfresco in less than
a week I would like to pass this question on to Mike Hatfield (cc'd)

Kind regards
Peter


On 17 May 2013 13:54, Eberlein, Peter <pe...@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
>
>
>


-- 
Kind regards
Peter

-----------
*Peter Schmidt*
*Alfresco Software Ltd.*
*UK: 07748 185496*
*Int.: +44 7748 185496*
*Skype: pweschmidt*

Re: kCMISSessionAllowUntrustedSSLCertificate

["Eberlein, Peter" <pe...@sap.com>]

There are certainly use cases for self-signed certificates (althoug no good ones from a security perspective). But as I said, the Objective-CMIs lib perfectly supports these use cases in the authentication provider, there is no need to extend the HTTPRequest classes by an additional parameter. So the right place to implement such a feature is in an authentication provider and if there is concern that developers might struggle doing so we could either provide sample code for this or enhance the default provider (which I obviously would not prefer, but this is still the better option as you can completely swap out this (dangerous) provider and get back to a secure system).

How about that for a proposal?

Peter