-1

I have installed a SSL certificate (comodo PositiveSSL) for my domain and forced NGINX to only use HTTPS.

I run the test on SSL analyzer https://sslanalyzer.comodoca.com/?url=domain.com

Validation Type Domain Validated (DV)
Trusted by Microsoft?   Yes 
Trusted by Mozilla? Yes

enter image description here

enter image description here

We have our mobile app for Android and IOS getting some data from our https://example.com/api webservices. So i have installed Packet Capture mobile app on my android to verify whether the data transferred between the webservice api and our mobile app is secured.

First i tried with enabling the following in Packet capture mobile app :- enter image description here

enter image description here

I have contacted comodo ssl support, they said

that the certificate is installed well and its working fine. There is nothing wrong with the certificate and installation process and the web-site https://example.com/ is also completely secured with Green Pad lock on it.

I run the same test on instagram app, when open instagram , showing network error. Like instagram discovering by some way that i am trying to capture a network packets so their app network will be disabled. enter image description here I want to do the same way of what instagram did .

Please Advice.

Q8root
  • 1,243
  • 3
  • 25
  • 48
  • What is the problem? It is that you can be victim of "man in the middle" attack? – Mumrah81 Jan 19 '18 at 10:54
  • @Mumrah81 i am not expert on this , but as you can see, i am using a third party app to capture network packets , i am able to see the data sent by HTTP request and data received, when i tried the same with other apps installed , i am not able to see any data . How can i secure this ? – Q8root Jan 19 '18 at 10:57
  • 2
    You've explicitly enabled SSL decryption by doing an active man in the middle attack. In you've made your phone to trust the certificate created for the SSL interception. In this case it is the expected behavior that you can see the unencrypted traffic since it was decrypted by the packet capture application. I recommend that you first understand what you have configured in the packet capture application before you complain that SSL does not provide the protection you expected. – Steffen Ullrich Jan 19 '18 at 11:05
  • @SteffenUllrich how can i secure my data from being decrypted by the packet capture application ? – Q8root Jan 19 '18 at 11:07
  • @user2873860: I don't think you understand the problem. What you are doing with the packet capture application is not an attack by an untrusted attacker but an interception by an explicitly trusted person. This is not the bad attacker somewhere in the network but more like somebody sitting together with you and watching at the same screen as you while you are surfing and you've explicitly accepted this. – Steffen Ullrich Jan 19 '18 at 11:12
  • I am sure that Instagram uses another encryption technique rather than relying on ssl encryption like end to end encryption on whats app – Azmat Karim Khan Jan 21 '18 at 00:10

3 Answers3

1

Don't worry, if your certificate is valid and contains the right domain name then you've already done everything needed.

A "man in the middle attack" is an attack done on the client.

The client think the attacker is the website by compromising his DNS Then the attacker relay in and out traffic from/to the real server.

The server is secure but not the client.

Like RamKumar said the client need to trust the attacker certificate like you did

EDIT:

You can also use TLS with mutual authentication (mTLS). With this protocol the client AND the server exchange certificate public keys. It work as follow:

  1. A client requests access to a protected resource.
  2. The server presents its certificate to the client.
  3. The client verifies the server’s certificate.
  4. If successful, the client sends its certificate to the server.
  5. The server verifies the client’s credentials.
  6. If successful, the server grants access to the protected resource requested by the client.

Some sample: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/october/mutual-authentication-in-android-and-ios/

With this protocol the man in the middle attack is still possible but the attacker's certificates need to be trusted by both client and server

Another custom approach would be to add another layer of encryption using asymetric cipher.

Mumrah81
  • 2,034
  • 2
  • 16
  • 23
  • I have did the same test with other installed apps like instagram and others , and i have trusted the SSL certificate installed by Packet Capture app , but i won't able to see the data coming and sent from instagram app itself , – Q8root Jan 19 '18 at 11:18
  • I would say that Instagram use TLS with two way authentication but the monitoring app doesn't support it. – Mumrah81 Jan 19 '18 at 11:28
  • Can you please explain more about how to implement this way ? – Q8root Jan 19 '18 at 13:21
1

To remove that possibility you can use Certificate Pinning to make sure that only the specific Certificate you use can be used to prevent the device from using any other Certificate, even if it was signed from a trusted CA. This may still be circumvented by a user, but now he has to modify the application itself in order to disable the check, or change the pinned certificate

NoSkillDwnload
  • 56
  • 4
0

Have a look at how Certificate Authority (CA) works. In your case, what happens is that the Packet capture mobile app installs it's own CA. Now Packet capture becomes a trusted CA for your device and certificates signed by them are accepted. Then this app creates its own certificate saying example.com and signs it.

So when it performs man in the middle attack, the client (your app) communicates with Packet capture and not example.com, but your app believes it's communicating with the example.com, since the certificate provided by Packet capture is signed by a trusted CA (Packet capture CA itself).

Hence this works only when your install their CA. However a secured connection is made between Packet capture and example.com

ram
  • 483
  • 1
  • 4
  • 11