From Newsgroup: comp.lang.mumps

I was trying to use Packet Capture app to find out some URLs used by an app. Packet Capture allows you to capture SSL packets by installing a VPN Gateway with its own root CA certificate and then channeling app requests through that gateway. However, when I try to generate the certificate from within the app (on my Galaxy Note 8), I just get the error "Cannot create certificate". I don't know why this is as the app doesn't give any further explanation, but this means I can't use SSL capture in the app.
What I did so far: I installed the app "Dory". Then I tried creating a public/private keypair, CSR and root CA certificate, all the time setting the passphrase and alias to "abc". But when I tried to import the p12 file to Packet Capture, it just said "java.lang.RuntimeException: Cannot load key. Password might be wrong." I must have done something wrong; what should I be doing next?
packet capture ca certificate download
DOWNLOAD https://pimlm.com/2xdWdu
I had some issues with this after the Android 11 update. Android 11 no longer allows you to add certificates from any app other than the settings app, so you will have to generate and set the certificate yourself.
Open packet capture > Setting > Tap "No CA certificate" > Import PKCS#12 file > find keyStore.p12. Enter password "test" and the "alias". Restart packet capture. If everything worked, the "Status" subtitle should say "Installed to trusted credentials"
Still there is a partial solution. Turn off 'SSL Capture'. Then all apps will start working. But you won't be able to decrypt the contents of packets sent over an SSL connection. But you will still be able to see the source and destination address of the packets. If your packet sniffer application does not have an option to turn off SSL packet sniffing, in that case uninstall the app, remove any custom CA certificate installed and then re-install the app.
Android allows an app to act as a 'VPN Gateway app'. When an app tells Android that it wants to provide a VPN connection, Android will forward all IP packets destined to internet from all other apps to the VPN App. The VPN app then usually encrypt those packets and send it to the VPN server, from where the packets would go to their original destination.
Packet Sniffer packets make use of the above mentioned feature. They appear like a VPN app to Android. So, once turned on, Android will send all IP traffic to this app. But in order to forward them to a VPN server, the Packet Sniffer app would simply sent them to their original destination. This way the Packet Sniffer apps simply act like a transparent proxy. The app is able to all incoming and outgoing traffic. Those apps are essentially acting like a "man-in-the-middle".
While setting up a TLS/SSL connection, a client device will ask the server to show it's digital signature certificate (AKA SSL certificate) proving that the server is whom it is claimed to be. That is when Amazon App tries to connect to amazon.com, it will ask the server to produce a digital signature certificate proving that the server is in fact amazon.com . When the server sends the certificate back, the app will ask Android Operating System if the certificate is digitally signed by someone the Android
trusts. If the certificate is in fact signed by a CA (Certificate Authority) that the Android Operating System trusts, the connection proceeds. Otherwise app will show an error that it is unable to connect.
Packet Sniffer apps will ask user to install a custom CA Certificate on the system on Android. That CA(Certificate Authority) certificate will make the Packet Sniffer app be treated as legitimate and trusted TSL/SSL certificate issuer authority on that device.
Now all apps by default will accept a TSL/SSL certificate signed by the Packet Sniffer app. So if an app like Amazon App tries to make an SSL/TLS/HTTPS connection while the Packet Sniffer app is running, the PacketSniffer app will establish to TLS/SSL/HTTPS connections - one between Amazon App and the Packet Sniffer, another between the Packet Sniffer app and the amazon.com server. The Packet Sniffer will show a fake SSL certificate claiming that it is in fact amazon.com server. Since Android now trust any SSL certificate that is signed by the Packet Sniffer app, the connection proceeds fooling the Amazon App.
If a packet sniffer app like the one described above can decrypt information sent over an SSL connection, then same thing can be done by a malicious person too. All he needs to do is somehow convince the user to install his CA certificate on Android. Then he will be able to read all WhatsApp messages, banking passwords from Bank apps, Credit Card information that Amazon app send to amazon.com .... and what not.
Those apps would then compare any certificate produced by the server with the certificates that is embedded with-in the app. If they do not match, the apps will simply refuse to connect. Those apps do not place the trust on Operating System. Hence the custom CA certificate that the Packet Sniffer app installed would have no effect on those apps.
There is no known way to easily bypass certificate pinning (other than decompiling each app and replace the embedded certificate, that too on a rooted device). Certificate pinning exist solely for the purpose of preventing exactly what you are trying to achieve. If you enable SSL sniffing on your Packet Sniffer app, all apps that uses certificate pinning will stop working.
Turn off SSL Capture. If your packet sniffer application does not have an option to turn off SSL packet sniffing, in that case uninstall the app, remove any custom CA certificate installed and then re-install the app.
that the certificate is installed well and its working fine. There is nothing wrong with the certificate and installation process and the web-site 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.I want to do the same way of what instagram did .
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
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).
First, ensure that your Wireshark is set to reassemble out-of-order TCP packets. Without this, it can sometimes be very difficult to complete this next step. You can verify that Wireshark is configured to do this by going to this page in the Wireshark GUI and ensuring that any reassembly related options are ticked.
That said, I could try whitelisting every IP I see in the packet capture... It's DEFINITELY possible that this validation thing is why it's failing, because it has been working for years and it just started failing this month. I'll check it out.
Turning off certificate inspection allowed everything to work, but I thought just plain certificate inspection (not deep inspection) wasn't supposed to cause a problem with Apple's certificate pinning?
With certificate-inspection, it should not cause any problems with Certificate Pinning since it is not replacing the SSL Certificate. Can you do a packet capture and look to see if there's any sessions that have the certificate replaced with FGT's certificate? I could check for you too if you can send me the pcap.
We have similar issue with App Store. You will need to do some packet captures to check. Usually is the communication to the Akamai cache that gives problem. Whitelist Akamai range from SSL inspeciton solve it for us but it is far from ideal.
In my case the problem turned out not to be certificate pinning, but instead that the FortiGate wasn't properly matching iPhone and iPad types. Instead of matching the policy for mobile devices it was matching a more generic policy for that subnet to the wan. The more generic policy didn't allow some of the services needed for the iOS devices.
Hi,I have been working with Wireshark for years particularly as I use the Riverbed trace analysis programs daily. I found ways on the Internet to extract certificates from an SSL session trace. All the info I found seems to speak about fields I don't find in my version of WS (I tried 2.4.0 and 2.6.3. Expanding the SSL details on my trace shows:
But I see that the packet I am analysing is maxed out in size and followed by another also maxed and a third half empty, so I think you are right: somehow the PC-to-Proxy message may not be re-assembled (maybe things work slightly different due to using the proxy). I will try tracing on the other side of the proxy to have a proxy-server trace. I'll let you know
In your example, the ChangeCipherSpec comes straight after the ServerHello. This means this is a resumed session (either cached on both client and server or there was a TLS ticket). In resumed sessions the authentication of the server certificate (and in case of mutual TLS, also the client certificate) has already taken place so the cetificate(s) will not be exchanged.
The wireshark trace I was using was not recording the entire length of each packet, so Wireshark was not interpreting the packet correctly and displaying 'Packet size limited during capture')I had not identified the error because the 'Server Hello' packet does not mention 'limited'The correct packet containing the certificates is, apparently the second one just after the one marked 'Server Hello' and, when interpreted correctly by WS, is marked 'Certificate' and has a Tls.handshake.type of 11, as grahamb pointed out. Thanks for your help
f448fe82f3
--- Synchronet 3.21d-Linux NewsLink 1.2