Permitting cleartext HTTP traffic from Android App in very limited circumstances












5














I have read Android 8: Cleartext HTTP traffic not permitted, but none of the answers appear to allow me to do what I want.



I have an Android application where another client can identify itself with a certificate. The application wants to verify that certificate. Part of verifying the certificate is fetching the certificate revocation list (CRL) from the certificate issuer. The distribution point(s) for the CRL is(are) listed in the certificate, and is inevitably an HTTP URL (the CRL itself is signed by the issuer so there is no security issue, and if it was an HTTPS URL, one would want to verify the certificate protecting the CRL distribution point, and check if it had been revoked ...)



Possible solutions, and why they don't work for me:




  • Don't worry about it - let the TLS library worry about validating the certificate. Unfortunately, there is no direct TLS connection between the two clients; it is all mediated through a server (which is connected to by TLS).

  • Create network_security_config.xml which lists the domains to which HTTP is allowed. Sadly, I don't know the URLs when I build the application - it depends on what the CA decides to put in their certificates.

  • Put android:usesCleartextTraffic="true" in the manifest. This means that any traffic can be HTTP, and I would rather avoid that if possible. (As an example, communication with the server absolutely must be HTTPS, and I would like an error if I do HTTP by accident.)


Is there any way for the code to say "this connection is allowed to be HTTP" (but default to HTTPS only)?










share|improve this question


















  • 1




    Note: I have added comments to the current answers indicating why they don't work for me, but I don't want to edit those restrictions into the question because a) they may be good answers for other people; b) editing the question to invalidate answers is rude.
    – Martin Bonner
    Nov 28 at 13:02










  • can you access any of those certificates before hand? if yes, then you might be able to set them as trust anchors. If you want your url to support https only then add it as sub-domain in domain-config and set cleartextTrafficPermitted="false"
    – Karan Mer
    Nov 29 at 7:08


















5














I have read Android 8: Cleartext HTTP traffic not permitted, but none of the answers appear to allow me to do what I want.



I have an Android application where another client can identify itself with a certificate. The application wants to verify that certificate. Part of verifying the certificate is fetching the certificate revocation list (CRL) from the certificate issuer. The distribution point(s) for the CRL is(are) listed in the certificate, and is inevitably an HTTP URL (the CRL itself is signed by the issuer so there is no security issue, and if it was an HTTPS URL, one would want to verify the certificate protecting the CRL distribution point, and check if it had been revoked ...)



Possible solutions, and why they don't work for me:




  • Don't worry about it - let the TLS library worry about validating the certificate. Unfortunately, there is no direct TLS connection between the two clients; it is all mediated through a server (which is connected to by TLS).

  • Create network_security_config.xml which lists the domains to which HTTP is allowed. Sadly, I don't know the URLs when I build the application - it depends on what the CA decides to put in their certificates.

  • Put android:usesCleartextTraffic="true" in the manifest. This means that any traffic can be HTTP, and I would rather avoid that if possible. (As an example, communication with the server absolutely must be HTTPS, and I would like an error if I do HTTP by accident.)


Is there any way for the code to say "this connection is allowed to be HTTP" (but default to HTTPS only)?










share|improve this question


















  • 1




    Note: I have added comments to the current answers indicating why they don't work for me, but I don't want to edit those restrictions into the question because a) they may be good answers for other people; b) editing the question to invalidate answers is rude.
    – Martin Bonner
    Nov 28 at 13:02










  • can you access any of those certificates before hand? if yes, then you might be able to set them as trust anchors. If you want your url to support https only then add it as sub-domain in domain-config and set cleartextTrafficPermitted="false"
    – Karan Mer
    Nov 29 at 7:08
















5












5








5


0





I have read Android 8: Cleartext HTTP traffic not permitted, but none of the answers appear to allow me to do what I want.



I have an Android application where another client can identify itself with a certificate. The application wants to verify that certificate. Part of verifying the certificate is fetching the certificate revocation list (CRL) from the certificate issuer. The distribution point(s) for the CRL is(are) listed in the certificate, and is inevitably an HTTP URL (the CRL itself is signed by the issuer so there is no security issue, and if it was an HTTPS URL, one would want to verify the certificate protecting the CRL distribution point, and check if it had been revoked ...)



Possible solutions, and why they don't work for me:




  • Don't worry about it - let the TLS library worry about validating the certificate. Unfortunately, there is no direct TLS connection between the two clients; it is all mediated through a server (which is connected to by TLS).

  • Create network_security_config.xml which lists the domains to which HTTP is allowed. Sadly, I don't know the URLs when I build the application - it depends on what the CA decides to put in their certificates.

  • Put android:usesCleartextTraffic="true" in the manifest. This means that any traffic can be HTTP, and I would rather avoid that if possible. (As an example, communication with the server absolutely must be HTTPS, and I would like an error if I do HTTP by accident.)


Is there any way for the code to say "this connection is allowed to be HTTP" (but default to HTTPS only)?










share|improve this question













I have read Android 8: Cleartext HTTP traffic not permitted, but none of the answers appear to allow me to do what I want.



I have an Android application where another client can identify itself with a certificate. The application wants to verify that certificate. Part of verifying the certificate is fetching the certificate revocation list (CRL) from the certificate issuer. The distribution point(s) for the CRL is(are) listed in the certificate, and is inevitably an HTTP URL (the CRL itself is signed by the issuer so there is no security issue, and if it was an HTTPS URL, one would want to verify the certificate protecting the CRL distribution point, and check if it had been revoked ...)



Possible solutions, and why they don't work for me:




  • Don't worry about it - let the TLS library worry about validating the certificate. Unfortunately, there is no direct TLS connection between the two clients; it is all mediated through a server (which is connected to by TLS).

  • Create network_security_config.xml which lists the domains to which HTTP is allowed. Sadly, I don't know the URLs when I build the application - it depends on what the CA decides to put in their certificates.

  • Put android:usesCleartextTraffic="true" in the manifest. This means that any traffic can be HTTP, and I would rather avoid that if possible. (As an example, communication with the server absolutely must be HTTPS, and I would like an error if I do HTTP by accident.)


Is there any way for the code to say "this connection is allowed to be HTTP" (but default to HTTPS only)?







android






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 22 at 11:26









Martin Bonner

22.9k33161




22.9k33161








  • 1




    Note: I have added comments to the current answers indicating why they don't work for me, but I don't want to edit those restrictions into the question because a) they may be good answers for other people; b) editing the question to invalidate answers is rude.
    – Martin Bonner
    Nov 28 at 13:02










  • can you access any of those certificates before hand? if yes, then you might be able to set them as trust anchors. If you want your url to support https only then add it as sub-domain in domain-config and set cleartextTrafficPermitted="false"
    – Karan Mer
    Nov 29 at 7:08
















  • 1




    Note: I have added comments to the current answers indicating why they don't work for me, but I don't want to edit those restrictions into the question because a) they may be good answers for other people; b) editing the question to invalidate answers is rude.
    – Martin Bonner
    Nov 28 at 13:02










  • can you access any of those certificates before hand? if yes, then you might be able to set them as trust anchors. If you want your url to support https only then add it as sub-domain in domain-config and set cleartextTrafficPermitted="false"
    – Karan Mer
    Nov 29 at 7:08










1




1




Note: I have added comments to the current answers indicating why they don't work for me, but I don't want to edit those restrictions into the question because a) they may be good answers for other people; b) editing the question to invalidate answers is rude.
– Martin Bonner
Nov 28 at 13:02




Note: I have added comments to the current answers indicating why they don't work for me, but I don't want to edit those restrictions into the question because a) they may be good answers for other people; b) editing the question to invalidate answers is rude.
– Martin Bonner
Nov 28 at 13:02












can you access any of those certificates before hand? if yes, then you might be able to set them as trust anchors. If you want your url to support https only then add it as sub-domain in domain-config and set cleartextTrafficPermitted="false"
– Karan Mer
Nov 29 at 7:08






can you access any of those certificates before hand? if yes, then you might be able to set them as trust anchors. If you want your url to support https only then add it as sub-domain in domain-config and set cleartextTrafficPermitted="false"
– Karan Mer
Nov 29 at 7:08














3 Answers
3






active

oldest

votes


















0





+500









If you're using OkHttp, you can construct a client as such:



OkHttpClient client = new OkHttpClient.Builder() 
.connectionSpecs(Arrays.asList(ConnectionSpec.MODERN_TLS, ConnectionSpec.COMPATIBLE_TLS))
.build();


This will only allow connections through HTTPS. So then, you can use your third option (android:usesCleartextTraffic="true") and when you make a cleartext connection through this client, it will fail.



Finally, you can create a standard OkHttp client:



OkHttpClient client = new OkHttpClient.Builder().build()


when you want to use the cleartext connection.



EDIT: Using HttpUrlConnection, you can simply check if the returned connection is a HttpsUrlConnection, like:



try {
URL my_url = new URL(path);
HttpUrlConnection urlConnection = (HttpURLConnection) my_url.openConnection();
if(!(urlConnection instanceof HttpsURLConnection)) {
// cleartext connection, throw error
throw new NotHttpsException();
}
// the connection is secure, do normal stuff here
urlConnection.setRequestMethod("POST");
urlConnection.setConnectTimeout(1500);
urlConnection.setReadTimeout(1500);
result = IOUtil.readFully(urlConnection.getInputStream());
} catch(Exception e) {
e.printStackTrace()
} finally {
if(urlConnection != null) urlConnection.disconnect();
}





share|improve this answer























  • Sadly, I'm not using OkHttp.
    – Martin Bonner
    Nov 28 at 13:00










  • @MartinBonner I added an example for HttpUrlConnection, if you're using that.
    – qualverse
    Nov 29 at 6:46





















1














The documentation on NetworkSecurityPolicy.isCleartextTrafficPermitted() says




This flag is honored on a best effort basis because it's impossible to prevent all cleartext traffic from Android applications given the level of access provided to them. For example, there's no expectation that the Socket API will honor this flag because it cannot determine whether its traffic is in cleartext.




So maybe this is an option for you: fetch the CRL using a Socket. There is a post by Daniel Nugent describing how to set up a simple TCP client






share|improve this answer





























    0














    Tha app has a TLS connection with the server.

    You can ask the server to hand off those CRL urls to you (It is handing off the certificate in the first place right?).

    It could even do it before hand and provide the Certificate together with the CRLs.
    In this way you get the CRLs without loosing the https lock nor having to make exceptions.






    share|improve this answer





















    • Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
      – Martin Bonner
      Nov 28 at 12:59






    • 1




      If you have no issues in getting the CRL over HTTP because it is signed by the CA (I think I understood that from the question) why would trusting the server be less secure?
      – Juan
      Nov 29 at 12:43










    • "The server" in this context is a server run specifically to provide services for this application. It is entirely distinct from the CA.
      – Martin Bonner
      Nov 29 at 13:33










    • I wasn't impying that. I actually understood what you are clarifying. In those terms, the server can fetch the CRLs and hand them over to the app. What I refferd to is that given that the connection you are trying to make using the app is over http (insecure), there is no additional risk if you have your server get the lists (from the issuer of the cerificate), and hand them over to you app. For your app it would be one service more it calls on your server. From the connecton point of view your server would be one more machine in the middle between the app and the CA Issuer providing the CRL.
      – Juan
      Nov 29 at 14:35











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53429933%2fpermitting-cleartext-http-traffic-from-android-app-in-very-limited-circumstances%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0





    +500









    If you're using OkHttp, you can construct a client as such:



    OkHttpClient client = new OkHttpClient.Builder() 
    .connectionSpecs(Arrays.asList(ConnectionSpec.MODERN_TLS, ConnectionSpec.COMPATIBLE_TLS))
    .build();


    This will only allow connections through HTTPS. So then, you can use your third option (android:usesCleartextTraffic="true") and when you make a cleartext connection through this client, it will fail.



    Finally, you can create a standard OkHttp client:



    OkHttpClient client = new OkHttpClient.Builder().build()


    when you want to use the cleartext connection.



    EDIT: Using HttpUrlConnection, you can simply check if the returned connection is a HttpsUrlConnection, like:



    try {
    URL my_url = new URL(path);
    HttpUrlConnection urlConnection = (HttpURLConnection) my_url.openConnection();
    if(!(urlConnection instanceof HttpsURLConnection)) {
    // cleartext connection, throw error
    throw new NotHttpsException();
    }
    // the connection is secure, do normal stuff here
    urlConnection.setRequestMethod("POST");
    urlConnection.setConnectTimeout(1500);
    urlConnection.setReadTimeout(1500);
    result = IOUtil.readFully(urlConnection.getInputStream());
    } catch(Exception e) {
    e.printStackTrace()
    } finally {
    if(urlConnection != null) urlConnection.disconnect();
    }





    share|improve this answer























    • Sadly, I'm not using OkHttp.
      – Martin Bonner
      Nov 28 at 13:00










    • @MartinBonner I added an example for HttpUrlConnection, if you're using that.
      – qualverse
      Nov 29 at 6:46


















    0





    +500









    If you're using OkHttp, you can construct a client as such:



    OkHttpClient client = new OkHttpClient.Builder() 
    .connectionSpecs(Arrays.asList(ConnectionSpec.MODERN_TLS, ConnectionSpec.COMPATIBLE_TLS))
    .build();


    This will only allow connections through HTTPS. So then, you can use your third option (android:usesCleartextTraffic="true") and when you make a cleartext connection through this client, it will fail.



    Finally, you can create a standard OkHttp client:



    OkHttpClient client = new OkHttpClient.Builder().build()


    when you want to use the cleartext connection.



    EDIT: Using HttpUrlConnection, you can simply check if the returned connection is a HttpsUrlConnection, like:



    try {
    URL my_url = new URL(path);
    HttpUrlConnection urlConnection = (HttpURLConnection) my_url.openConnection();
    if(!(urlConnection instanceof HttpsURLConnection)) {
    // cleartext connection, throw error
    throw new NotHttpsException();
    }
    // the connection is secure, do normal stuff here
    urlConnection.setRequestMethod("POST");
    urlConnection.setConnectTimeout(1500);
    urlConnection.setReadTimeout(1500);
    result = IOUtil.readFully(urlConnection.getInputStream());
    } catch(Exception e) {
    e.printStackTrace()
    } finally {
    if(urlConnection != null) urlConnection.disconnect();
    }





    share|improve this answer























    • Sadly, I'm not using OkHttp.
      – Martin Bonner
      Nov 28 at 13:00










    • @MartinBonner I added an example for HttpUrlConnection, if you're using that.
      – qualverse
      Nov 29 at 6:46
















    0





    +500







    0





    +500



    0




    +500




    If you're using OkHttp, you can construct a client as such:



    OkHttpClient client = new OkHttpClient.Builder() 
    .connectionSpecs(Arrays.asList(ConnectionSpec.MODERN_TLS, ConnectionSpec.COMPATIBLE_TLS))
    .build();


    This will only allow connections through HTTPS. So then, you can use your third option (android:usesCleartextTraffic="true") and when you make a cleartext connection through this client, it will fail.



    Finally, you can create a standard OkHttp client:



    OkHttpClient client = new OkHttpClient.Builder().build()


    when you want to use the cleartext connection.



    EDIT: Using HttpUrlConnection, you can simply check if the returned connection is a HttpsUrlConnection, like:



    try {
    URL my_url = new URL(path);
    HttpUrlConnection urlConnection = (HttpURLConnection) my_url.openConnection();
    if(!(urlConnection instanceof HttpsURLConnection)) {
    // cleartext connection, throw error
    throw new NotHttpsException();
    }
    // the connection is secure, do normal stuff here
    urlConnection.setRequestMethod("POST");
    urlConnection.setConnectTimeout(1500);
    urlConnection.setReadTimeout(1500);
    result = IOUtil.readFully(urlConnection.getInputStream());
    } catch(Exception e) {
    e.printStackTrace()
    } finally {
    if(urlConnection != null) urlConnection.disconnect();
    }





    share|improve this answer














    If you're using OkHttp, you can construct a client as such:



    OkHttpClient client = new OkHttpClient.Builder() 
    .connectionSpecs(Arrays.asList(ConnectionSpec.MODERN_TLS, ConnectionSpec.COMPATIBLE_TLS))
    .build();


    This will only allow connections through HTTPS. So then, you can use your third option (android:usesCleartextTraffic="true") and when you make a cleartext connection through this client, it will fail.



    Finally, you can create a standard OkHttp client:



    OkHttpClient client = new OkHttpClient.Builder().build()


    when you want to use the cleartext connection.



    EDIT: Using HttpUrlConnection, you can simply check if the returned connection is a HttpsUrlConnection, like:



    try {
    URL my_url = new URL(path);
    HttpUrlConnection urlConnection = (HttpURLConnection) my_url.openConnection();
    if(!(urlConnection instanceof HttpsURLConnection)) {
    // cleartext connection, throw error
    throw new NotHttpsException();
    }
    // the connection is secure, do normal stuff here
    urlConnection.setRequestMethod("POST");
    urlConnection.setConnectTimeout(1500);
    urlConnection.setReadTimeout(1500);
    result = IOUtil.readFully(urlConnection.getInputStream());
    } catch(Exception e) {
    e.printStackTrace()
    } finally {
    if(urlConnection != null) urlConnection.disconnect();
    }






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 29 at 6:46

























    answered Nov 27 at 18:00









    qualverse

    76139




    76139












    • Sadly, I'm not using OkHttp.
      – Martin Bonner
      Nov 28 at 13:00










    • @MartinBonner I added an example for HttpUrlConnection, if you're using that.
      – qualverse
      Nov 29 at 6:46




















    • Sadly, I'm not using OkHttp.
      – Martin Bonner
      Nov 28 at 13:00










    • @MartinBonner I added an example for HttpUrlConnection, if you're using that.
      – qualverse
      Nov 29 at 6:46


















    Sadly, I'm not using OkHttp.
    – Martin Bonner
    Nov 28 at 13:00




    Sadly, I'm not using OkHttp.
    – Martin Bonner
    Nov 28 at 13:00












    @MartinBonner I added an example for HttpUrlConnection, if you're using that.
    – qualverse
    Nov 29 at 6:46






    @MartinBonner I added an example for HttpUrlConnection, if you're using that.
    – qualverse
    Nov 29 at 6:46















    1














    The documentation on NetworkSecurityPolicy.isCleartextTrafficPermitted() says




    This flag is honored on a best effort basis because it's impossible to prevent all cleartext traffic from Android applications given the level of access provided to them. For example, there's no expectation that the Socket API will honor this flag because it cannot determine whether its traffic is in cleartext.




    So maybe this is an option for you: fetch the CRL using a Socket. There is a post by Daniel Nugent describing how to set up a simple TCP client






    share|improve this answer


























      1














      The documentation on NetworkSecurityPolicy.isCleartextTrafficPermitted() says




      This flag is honored on a best effort basis because it's impossible to prevent all cleartext traffic from Android applications given the level of access provided to them. For example, there's no expectation that the Socket API will honor this flag because it cannot determine whether its traffic is in cleartext.




      So maybe this is an option for you: fetch the CRL using a Socket. There is a post by Daniel Nugent describing how to set up a simple TCP client






      share|improve this answer
























        1












        1








        1






        The documentation on NetworkSecurityPolicy.isCleartextTrafficPermitted() says




        This flag is honored on a best effort basis because it's impossible to prevent all cleartext traffic from Android applications given the level of access provided to them. For example, there's no expectation that the Socket API will honor this flag because it cannot determine whether its traffic is in cleartext.




        So maybe this is an option for you: fetch the CRL using a Socket. There is a post by Daniel Nugent describing how to set up a simple TCP client






        share|improve this answer












        The documentation on NetworkSecurityPolicy.isCleartextTrafficPermitted() says




        This flag is honored on a best effort basis because it's impossible to prevent all cleartext traffic from Android applications given the level of access provided to them. For example, there's no expectation that the Socket API will honor this flag because it cannot determine whether its traffic is in cleartext.




        So maybe this is an option for you: fetch the CRL using a Socket. There is a post by Daniel Nugent describing how to set up a simple TCP client







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 2 at 18:14









        0X0nosugar

        7,09131842




        7,09131842























            0














            Tha app has a TLS connection with the server.

            You can ask the server to hand off those CRL urls to you (It is handing off the certificate in the first place right?).

            It could even do it before hand and provide the Certificate together with the CRLs.
            In this way you get the CRLs without loosing the https lock nor having to make exceptions.






            share|improve this answer





















            • Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
              – Martin Bonner
              Nov 28 at 12:59






            • 1




              If you have no issues in getting the CRL over HTTP because it is signed by the CA (I think I understood that from the question) why would trusting the server be less secure?
              – Juan
              Nov 29 at 12:43










            • "The server" in this context is a server run specifically to provide services for this application. It is entirely distinct from the CA.
              – Martin Bonner
              Nov 29 at 13:33










            • I wasn't impying that. I actually understood what you are clarifying. In those terms, the server can fetch the CRLs and hand them over to the app. What I refferd to is that given that the connection you are trying to make using the app is over http (insecure), there is no additional risk if you have your server get the lists (from the issuer of the cerificate), and hand them over to you app. For your app it would be one service more it calls on your server. From the connecton point of view your server would be one more machine in the middle between the app and the CA Issuer providing the CRL.
              – Juan
              Nov 29 at 14:35
















            0














            Tha app has a TLS connection with the server.

            You can ask the server to hand off those CRL urls to you (It is handing off the certificate in the first place right?).

            It could even do it before hand and provide the Certificate together with the CRLs.
            In this way you get the CRLs without loosing the https lock nor having to make exceptions.






            share|improve this answer





















            • Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
              – Martin Bonner
              Nov 28 at 12:59






            • 1




              If you have no issues in getting the CRL over HTTP because it is signed by the CA (I think I understood that from the question) why would trusting the server be less secure?
              – Juan
              Nov 29 at 12:43










            • "The server" in this context is a server run specifically to provide services for this application. It is entirely distinct from the CA.
              – Martin Bonner
              Nov 29 at 13:33










            • I wasn't impying that. I actually understood what you are clarifying. In those terms, the server can fetch the CRLs and hand them over to the app. What I refferd to is that given that the connection you are trying to make using the app is over http (insecure), there is no additional risk if you have your server get the lists (from the issuer of the cerificate), and hand them over to you app. For your app it would be one service more it calls on your server. From the connecton point of view your server would be one more machine in the middle between the app and the CA Issuer providing the CRL.
              – Juan
              Nov 29 at 14:35














            0












            0








            0






            Tha app has a TLS connection with the server.

            You can ask the server to hand off those CRL urls to you (It is handing off the certificate in the first place right?).

            It could even do it before hand and provide the Certificate together with the CRLs.
            In this way you get the CRLs without loosing the https lock nor having to make exceptions.






            share|improve this answer












            Tha app has a TLS connection with the server.

            You can ask the server to hand off those CRL urls to you (It is handing off the certificate in the first place right?).

            It could even do it before hand and provide the Certificate together with the CRLs.
            In this way you get the CRLs without loosing the https lock nor having to make exceptions.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 27 at 19:13









            Juan

            4,2772819




            4,2772819












            • Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
              – Martin Bonner
              Nov 28 at 12:59






            • 1




              If you have no issues in getting the CRL over HTTP because it is signed by the CA (I think I understood that from the question) why would trusting the server be less secure?
              – Juan
              Nov 29 at 12:43










            • "The server" in this context is a server run specifically to provide services for this application. It is entirely distinct from the CA.
              – Martin Bonner
              Nov 29 at 13:33










            • I wasn't impying that. I actually understood what you are clarifying. In those terms, the server can fetch the CRLs and hand them over to the app. What I refferd to is that given that the connection you are trying to make using the app is over http (insecure), there is no additional risk if you have your server get the lists (from the issuer of the cerificate), and hand them over to you app. For your app it would be one service more it calls on your server. From the connecton point of view your server would be one more machine in the middle between the app and the CA Issuer providing the CRL.
              – Juan
              Nov 29 at 14:35


















            • Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
              – Martin Bonner
              Nov 28 at 12:59






            • 1




              If you have no issues in getting the CRL over HTTP because it is signed by the CA (I think I understood that from the question) why would trusting the server be less secure?
              – Juan
              Nov 29 at 12:43










            • "The server" in this context is a server run specifically to provide services for this application. It is entirely distinct from the CA.
              – Martin Bonner
              Nov 29 at 13:33










            • I wasn't impying that. I actually understood what you are clarifying. In those terms, the server can fetch the CRLs and hand them over to the app. What I refferd to is that given that the connection you are trying to make using the app is over http (insecure), there is no additional risk if you have your server get the lists (from the issuer of the cerificate), and hand them over to you app. For your app it would be one service more it calls on your server. From the connecton point of view your server would be one more machine in the middle between the app and the CA Issuer providing the CRL.
              – Juan
              Nov 29 at 14:35
















            Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
            – Martin Bonner
            Nov 28 at 12:59




            Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
            – Martin Bonner
            Nov 28 at 12:59




            1




            1




            If you have no issues in getting the CRL over HTTP because it is signed by the CA (I think I understood that from the question) why would trusting the server be less secure?
            – Juan
            Nov 29 at 12:43




            If you have no issues in getting the CRL over HTTP because it is signed by the CA (I think I understood that from the question) why would trusting the server be less secure?
            – Juan
            Nov 29 at 12:43












            "The server" in this context is a server run specifically to provide services for this application. It is entirely distinct from the CA.
            – Martin Bonner
            Nov 29 at 13:33




            "The server" in this context is a server run specifically to provide services for this application. It is entirely distinct from the CA.
            – Martin Bonner
            Nov 29 at 13:33












            I wasn't impying that. I actually understood what you are clarifying. In those terms, the server can fetch the CRLs and hand them over to the app. What I refferd to is that given that the connection you are trying to make using the app is over http (insecure), there is no additional risk if you have your server get the lists (from the issuer of the cerificate), and hand them over to you app. For your app it would be one service more it calls on your server. From the connecton point of view your server would be one more machine in the middle between the app and the CA Issuer providing the CRL.
            – Juan
            Nov 29 at 14:35




            I wasn't impying that. I actually understood what you are clarifying. In those terms, the server can fetch the CRLs and hand them over to the app. What I refferd to is that given that the connection you are trying to make using the app is over http (insecure), there is no additional risk if you have your server get the lists (from the issuer of the cerificate), and hand them over to you app. For your app it would be one service more it calls on your server. From the connecton point of view your server would be one more machine in the middle between the app and the CA Issuer providing the CRL.
            – Juan
            Nov 29 at 14:35


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53429933%2fpermitting-cleartext-http-traffic-from-android-app-in-very-limited-circumstances%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Berounka

            Sphinx de Gizeh

            Different font size/position of beamer's navigation symbols template's content depending on regular/plain...