Permitting cleartext HTTP traffic from Android App in very limited circumstances
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
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
add a comment |
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
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 '18 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 indomain-config
and setcleartextTrafficPermitted="false"
– Karan Mer
Nov 29 '18 at 7:08
add a comment |
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
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
android
asked Nov 22 '18 at 11:26
Martin BonnerMartin Bonner
23.8k33267
23.8k33267
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 '18 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 indomain-config
and setcleartextTrafficPermitted="false"
– Karan Mer
Nov 29 '18 at 7:08
add a comment |
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 '18 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 indomain-config
and setcleartextTrafficPermitted="false"
– Karan Mer
Nov 29 '18 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 '18 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 '18 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 '18 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 '18 at 7:08
add a comment |
3 Answers
3
active
oldest
votes
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();
}
Sadly, I'm not using OkHttp.
– Martin Bonner
Nov 28 '18 at 13:00
@MartinBonner I added an example for HttpUrlConnection, if you're using that.
– qualverse
Nov 29 '18 at 6:46
add a comment |
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
add a comment |
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.
Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
– Martin Bonner
Nov 28 '18 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 '18 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 '18 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 '18 at 14:35
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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();
}
Sadly, I'm not using OkHttp.
– Martin Bonner
Nov 28 '18 at 13:00
@MartinBonner I added an example for HttpUrlConnection, if you're using that.
– qualverse
Nov 29 '18 at 6:46
add a comment |
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();
}
Sadly, I'm not using OkHttp.
– Martin Bonner
Nov 28 '18 at 13:00
@MartinBonner I added an example for HttpUrlConnection, if you're using that.
– qualverse
Nov 29 '18 at 6:46
add a comment |
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();
}
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();
}
edited Nov 29 '18 at 6:46
answered Nov 27 '18 at 18:00
qualversequalverse
76139
76139
Sadly, I'm not using OkHttp.
– Martin Bonner
Nov 28 '18 at 13:00
@MartinBonner I added an example for HttpUrlConnection, if you're using that.
– qualverse
Nov 29 '18 at 6:46
add a comment |
Sadly, I'm not using OkHttp.
– Martin Bonner
Nov 28 '18 at 13:00
@MartinBonner I added an example for HttpUrlConnection, if you're using that.
– qualverse
Nov 29 '18 at 6:46
Sadly, I'm not using OkHttp.
– Martin Bonner
Nov 28 '18 at 13:00
Sadly, I'm not using OkHttp.
– Martin Bonner
Nov 28 '18 at 13:00
@MartinBonner I added an example for HttpUrlConnection, if you're using that.
– qualverse
Nov 29 '18 at 6:46
@MartinBonner I added an example for HttpUrlConnection, if you're using that.
– qualverse
Nov 29 '18 at 6:46
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Dec 2 '18 at 18:14
0X0nosugar0X0nosugar
7,77331944
7,77331944
add a comment |
add a comment |
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.
Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
– Martin Bonner
Nov 28 '18 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 '18 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 '18 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 '18 at 14:35
add a comment |
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.
Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
– Martin Bonner
Nov 28 '18 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 '18 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 '18 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 '18 at 14:35
add a comment |
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.
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.
answered Nov 27 '18 at 19:13
JuanJuan
4,53121019
4,53121019
Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
– Martin Bonner
Nov 28 '18 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 '18 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 '18 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 '18 at 14:35
add a comment |
Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
– Martin Bonner
Nov 28 '18 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 '18 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 '18 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 '18 at 14:35
Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
– Martin Bonner
Nov 28 '18 at 12:59
Hmm. I'd rather avoid trusting the server if I can. This is a secure comms application.
– Martin Bonner
Nov 28 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 at 14:35
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 '18 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 setcleartextTrafficPermitted="false"
– Karan Mer
Nov 29 '18 at 7:08