I am developing an android Apps and using a SSL connection to connect to my server.
To connect to my web service, i use Volley Request to my server https' address.
But, when i tried to intercept my connection using Packet Capture that use man in the middle method to intercept my connection, it's looks like a non SSL connection. I can see the whole request and response. But, other apps like LINE, Facebook cannot be decrypted by Packet Capture. I want to protect my web service even from the same device like what LINE and Facebook does. How can i achieve that? I don't want someone to know any parameters that sent to my web service.
My backend server using google cloud platform compute engine.
Edit: I use Letsencrypt.org SSL Certificate.
Code :
My Custom Request
public class CustomRestRequest extends Request<JSONObject> implements Serializable {
private static final String SERVER_URL = "https://myapiurl.com/";
private Map<String, String> mHeaders = new HashMap<>();
private Response.Listener<JSONObject> listener;
private Map<String, String> params;
public UberGUARestRequest(String action, Map<String, String> params,
Response.Listener<JSONObject> responseListener, Response.ErrorListener errorListener) {
super(Method.POST, SERVER_URL + action, errorListener);
this.listener = responseListener;
this.params = params;
}
protected Map<String, String> getParams()
throws com.android.volley.AuthFailureError {
return params;
}
@Override
protected Response<JSONObject> parseNetworkResponse(NetworkResponse response) {
try {
String jsonString = new String(response.data,
HttpHeaderParser.parseCharset(response.headers));
return Response.success(new JSONObject(jsonString),
HttpHeaderParser.parseCacheHeaders(response));
} catch (UnsupportedEncodingException e) {
return Response.error(new ParseError(e));
} catch (JSONException je) {
return Response.error(new ParseError(je));
}
}
@Override
protected void deliverResponse(JSONObject response) {
listener.onResponse(response);
}
@Override
public Map<String, String> getHeaders() {
return mHeaders;
}
public void setBearerAuthorization(String token) {
mHeaders.put("Authorization", "Bearer " + token);
}
}
My Request Example:
Map<String, String> params = new HashMap<>();
params.put("message", message);
final CustomRestRequest request = new CustomRestRequest("user/support", params,
new Response.Listener<JSONObject>() {
@Override
public void onResponse(JSONObject response) {
try {
if (response.getString("status").equals("00")) {
result.status = "00";
mListener.onSupportTaskPostExecute(result);
} else {
result.status = "99";
isRunning = false;
mListener.onSupportTaskPostExecute(result);
}
} catch (Exception ex) {
result.status = "99";
isRunning = false;
mListener.onSupportTaskPostExecute(result);
}
}
},
new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {
result.status = "88";
isRunning = false;
mListener.onSupportTaskPostExecute(result);
error.printStackTrace();
}
});
request.setBearerAuthorization(AppHelper.getAuthCode(getContext()));
RequestQueue queue = Volley.newRequestQueue(getContext());
queue.add(request);
SSL is vulnerable to MitM attacks as long as the attacker has a certificate accepted by your device.*
Your device accepts mainly 2 types of certificates: those issued by trusted organization like Verisign or Thawte, and those installed by yourself.
I suspect that Packet Capture, if that is what you are using, is installing its own certificate on the device to make it trusted, being later able to spoof any certificate on outgoing connections.
The good news is that any mitm attack originating from the outside should not be as easily able to do the same thing. (It would still be possible under some circumstances, such as convincing you to install an app or a certificate for dubious reasons).
To completely prevent this, you can use certificate pinning to ensure your connexion cannot be re-encrypted with a different certificate.
You should also try a mitm attack from outside your device, such as using a proxy like Charles to effectively see that your connection is still secure.
*: SSL cannot guarantee the link between the certificate and the domain name. It only guarantees that whoever signs the connection is supposed to be trusted. (To be taken with a large chunk of salt. Anyone can buy a certificate with little to no verification.)