cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Axel Nennker <ignisvul...@gmail.com>
Subject Re: Support self-signed certs in FileTransfer
Date Wed, 11 Dec 2013 16:01:14 GMT
I think it is a good security practice to tie an app to the app's backend.


2013/12/11 Josh Soref <jsoref@blackberry.com>

> Ian wrote:
> > There was some talk on the list a couple months ago about this -- not for
> > file-transfer specifically,
> > but the general idea of supporting custom
> certificates, or CAs in Cordova.
>
> This came up yesterday in the office.
>
> > I think that, after a number of emails, we concluded that for users who
> > have legitimate custom certificate requirements, that there should be
> > os-policy-level mechanisms for adding custom certs, and that the
> individual
> > application was the wrong level to be managing them.
>
> I made the opposite argument. Users will not be able to do anything useful
> with global stores. The result is that unrelated applications will still /
> misappropriate certificates.
>
> Google is supporting zero trust:
>
> http://www.scmagazine.com.au/News/367057,googles-plan-to-kill-the-corporate-network.aspx
>
>
> http://www.darkreading.com/perimeter/forrester-pushes-zero-trust-model-for-se/227500145
>
> While you might be OK with a prompt to enter an RSA token, you could
> easily not recognize that the requesting party shouldn't be given it.
>
> Browser developers failed miserably the first time that client certificate
> UI was designed - Neither the "automatic selection" nor the "prompt user
> for certificate" choices work safely.
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message