[feedhenry-dev] Self Signed Certs in Android

[Summers Pittman]

On Fri, Oct 6, 2017 at 12:15 PM, Vojtech Sazel <vsazel at redhat.com> wrote:

> Hi,
>
> I think that MCP will be hosted on site like* openshift.io
> <http://openshift.io>*. Doesn't they have simple some container that does
> set up Letsencrypt <https://letsencrypt.org/> for the subdomain? However
> it's necessary to have access to public internet for Letsencrypt.
> I think that it would be ok to disable SSL certificate checks for debug
> mode apps.
>

If MCP is hosted on services with a robust SSL answer, yes. Getting MCP
into a service and hosting it for free is a pretty big ask from a host and
there will probably be people who want to run it "on site".

I'm of two minds on looser SSL in debug modes.  On the one hand it makes
development faster and moves hurdles down the road so users can evaluate
and learn without a lot of trouble.  On the other hand a lot of debug code
tends to find its way into production, and there are production situations
where you may be using a trusted but self signed certificate (ie internal
services) when an app is "released".


>
> Vojtech
>
> On Fri, Oct 6, 2017 at 4:14 PM, Julio Cesar Sanchez Hernandez <
> jusanche at redhat.com> wrote:
>
>> On Cordova Android apps, self signed certificates work in debug but fail
>> to connect in release.
>> On Cordova iOS and iOS native, self signed certificates don't work, even
>> configuring ATS to allow everything, self signed don't fall into the
>> "everything". There is some code you can add to allow connection despite
>> the self signed certificate, but it's not a good option. Apple might reject
>> the app if you forget to remove it before releasing the app.
>>
>> On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>> While I'm testing out MCP and some of the client sdk sync refactoring I
>>> regularly get hit with Android not liking self signed certificates.*
>>>
>>> There are several work around for development such as
>>>  * setting up and maintaining a CA infrastructure and signing everything
>>> in correct fashion
>>>  * setting up DNS for developer to host their own domains and distribute
>>> well signed keys**
>>>  * injecting a SSL Handler that just doesn't check anything
>>>
>>> These are impractical, tedious and/or dangerous.  I will leave it as an
>>> exercise to the reader to decide which is which.
>>>
>>> However, for development scenarios we have the option of certificate
>>> pinning.  This is a fancy word for "If you see the certificate at this URL
>>> you are golden, ignore the haters".***  There are two general ways to pin,
>>> but they each have drawbacks.
>>>
>>> First, Android N has support for defining pins in your AndroidManifest.
>>> Android handles all of the dirty work for you, but this is only in Android
>>> N and above.  There do seem to be some attempts at back porting, but I
>>> haven't researched them too far,
>>>
>>> The second choice is for us to design our API layers such that pins can
>>> be injected and used by our underlying HTTP mechanisms.  Many frameworks
>>> already support pinning so it shouldn't be too hard to expose, but it will
>>> require more coordination and thought.
>>>
>>> So wdyt?  For the next couple of sprints we should be fine just using
>>> Android N's pinning, and eventually it will be the default solution.
>>>
>>> Also, I don't know how self-signed certificates run on cordova, windows,
>>> iOS, etc.  I wouldn't mind if those platforms' experts chime in.
>>>
>>> Summers
>>>
>>> * Java and thus Android won't by default make a connection if the
>>> certificate can't be authenticated both by a chain of trust and matching
>>> the domain the certificate claims to be for.
>>>
>>> ** This is kind of what fhcap does.  It works great fro Android
>>> development in an emulator but isn't practical for testing on devices as
>>> the DNS magic has to be set up on the device which fhcap can't control.
>>>
>>> *** I may have not used the correct technical jargon here.
>>>
>>>
>>>
>>> _______________________________________________
>>> feedhenry-dev mailing list
>>> feedhenry-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>
>>>
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>
>
> --
>
> VOJTĚCH SÁZEL
>
> SENIOR QUALITY ENGINEER, MOBILE QE
>
> Red Hat
>
> <https://www.redhat.com/>
>
> Remote Czech Republic
>
> vsazel at redhat.com    IM: vsazel
> <https://red.ht/sig>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171009/4df38d84/attachment.htm>