[feedhenry-dev] Self Signed Certs in Android

Mon Oct 9 12:54:46 UTC 2017

On Mon, Oct 9, 2017 at 8:45 AM, Summers Pittman <supittma at redhat.com> wrote:

>
>
> On Mon, Oct 9, 2017 at 6:12 AM, John Frizelle <jfrizell at redhat.com> wrote:
>
>> 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.
>>
>>
> Sure thing.
>
> Most Android Http libraries provide support for certificate pinning;
> OkHTTP has this for example  :
>
>      String hostname = "publicobject.com";
>      CertificatePinner certificatePinner = new CertificatePinner.Builder()
>          .add(hostname, "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
>          .build();
>      OkHttpClient client = OkHttpClient.Builder()
>          .certificatePinner(certificatePinner)
>          .build();
>
> We provide, in code, the certificate hashes and the host names that they
> are signed for.  If all of the MCP support libraries use OkHttp then, for
> example, we can provide an option for developers to pass in their own
> configured client to use instead of using one provided by MCP.  Another
> alternative would be providing this information in a configuration file and
> having our build time or run time tooling parse the file to build our HTTP
> client.  A benefit of the second approach is it doesn't bind our libraries
> to OkHttp.
>
>
> I'm actually starting to like it more.  If you only put your pinning
configurations in non release Android build flavors then they won't "leak"
into production.  The mcp plugin could take care of this automatically even.

>
>
>
>
>
>> @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
>>>
>>>
>>
>> _______________________________________________
>> 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/ee0ffa48/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/ee0ffa48/attachment.png>