Self Signed Certs in Android

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Self Signed Certs in Android

supittma
Administrator
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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Self Signed Certs in Android

Julio Cesar Sanchez Hernandez
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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Self Signed Certs in Android

Vojtech Sazel
Hi,

I think that MCP will be hosted on site like openshift.io. Doesn't they have simple some container that does set up Letsencrypt 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

VOJTĚCH SÁZEL

SENIOR QUALITY ENGINEER, MOBILE QE

Red Hat 

Remote Czech Republic

[hidden email]    IM: vsazel


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Self Signed Certs in Android

John Frizelle
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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 6 October 2017 at 17:15, Vojtech Sazel <[hidden email]> wrote:
Hi,

I think that MCP will be hosted on site like openshift.io. Doesn't they have simple some container that does set up Letsencrypt 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

VOJTĚCH SÁZEL

SENIOR QUALITY ENGINEER, MOBILE QE

Red Hat 

Remote Czech Republic

[hidden email]    IM: vsazel


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Self Signed Certs in Android

Julio Cesar Sanchez Hernandez
This is the code needed 

@implementation NSURLRequest(DataController)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
    return YES;
}
@end

Other option is to tell the users to install the certificate on the device and trust it.


I'm +1 on using HTTP in development mode if possible


On Mon, Oct 9, 2017 at 12:12 PM, John Frizelle <[hidden email]> 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.

@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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 6 October 2017 at 17:15, Vojtech Sazel <[hidden email]> wrote:
Hi,

I think that MCP will be hosted on site like openshift.io. Doesn't they have simple some container that does set up Letsencrypt 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

VOJTĚCH SÁZEL

SENIOR QUALITY ENGINEER, MOBILE QE

Red Hat 

Remote Czech Republic

[hidden email]    IM: vsazel


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Self Signed Certs in Android

supittma
Administrator
In reply to this post by John Frizelle


On Mon, Oct 9, 2017 at 6:12 AM, John Frizelle <[hidden email]> 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.





 
@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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 6 October 2017 at 17:15, Vojtech Sazel <[hidden email]> wrote:
Hi,

I think that MCP will be hosted on site like openshift.io. Doesn't they have simple some container that does set up Letsencrypt 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

VOJTĚCH SÁZEL

SENIOR QUALITY ENGINEER, MOBILE QE

Red Hat 

Remote Czech Republic

[hidden email]    IM: vsazel


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Self Signed Certs in Android

supittma
Administrator


On Mon, Oct 9, 2017 at 8:45 AM, Summers Pittman <[hidden email]> wrote:


On Mon, Oct 9, 2017 at 6:12 AM, John Frizelle <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 6 October 2017 at 17:15, Vojtech Sazel <[hidden email]> wrote:
Hi,

I think that MCP will be hosted on site like openshift.io. Doesn't they have simple some container that does set up Letsencrypt 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

VOJTĚCH SÁZEL

SENIOR QUALITY ENGINEER, MOBILE QE

Red Hat 

Remote Czech Republic

[hidden email]    IM: vsazel


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Self Signed Certs in Android

supittma
Administrator
In reply to this post by Vojtech Sazel


On Fri, Oct 6, 2017 at 12:15 PM, Vojtech Sazel <[hidden email]> wrote:
Hi,

I think that MCP will be hosted on site like openshift.io. Doesn't they have simple some container that does set up Letsencrypt 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

VOJTĚCH SÁZEL

SENIOR QUALITY ENGINEER, MOBILE QE

Red Hat 

Remote Czech Republic

[hidden email]    IM: vsazel



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev