[feedhenry-dev] Self Signed Certs in Android

Mon Oct 9 10:12:18 UTC 2017

This is going to be a challenge - not just for us, but for others who try
to run our software locally, so we should invest some time and headspace in
figuring it out.

@Summers - Re: "The second choice is for us to design our API layers such
that pins can be injected and used by our underlying HTTP mechanisms" - Can
you provide some more information here - it seems like the most robust
option from what you have outlined.

@Julio - Re: "There is some code you can add to allow connection despite
the self signed certificate, but it's not a good option." - Can you provide
some more information here please.

What are the options for running with just HTTP in development mode - in
terms of OpenShift, Android and iOS? I know that apple were planning to
mandate everything over https but have pulled back from it a bit...

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: *+353 87 290 1644 <//+353872901644>*
twitter:* @johnfriz*
skype: *john_frizelle*
mail: *jfrizell at redhat.com <jfrizell at redhat.com>*

On 6 October 2017 at 17:15, 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.
>
> 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>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171009/e3226fcb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171009/e3226fcb/attachment.png>