We are creating a browser based HTML5 application targeted for Android devices through the Chrome browser. Security is a chief concern and beyond userid/password requirements, the company also desires to ensure each user has a proper SSL certificate installed before granting access.
Does this even make sense, and if so, can someone provide some resources where I can research this further?
I always thought the cert was stored on the server to secure a session between itself and a client. But I am not aware of the browser somehow providing an installed cert to a server that ensures it is a valid client.
SSL communications can involve certificates installed to both the client and server. An IIS website can be configured to require a client side certificate is installed.
Regarding Android, current versions do not support leveraging an installed client side certificate through the browser. This thread is tracking this particular feature.
http://code.google.com/p/android/issues/detail?id=11231#c107
Related
I have a VM instance running in Google compute engine. It has an external IP address. My only usage of the VM instance is for a REST api for an android app. I do not want to use it with any browsers. Only the android app is going to communicate with this.
I have installed a lamp stack and am able to use the REST apis that I have created with normal http and the external IP address. I want to secure the communication using TLS. I do not have a domain name. I don't require one. Is it possible to use HTTPS in this situation?
I can create add the self signed certificates in my android app as well. I'm not sure if this possible? after some research I found that lets encrypt doesn't issue certificates for IP addresses and various reasons for it, which mainly includes browsers. In my case browsers are of no use coz only my android app is going to access the server.
Any solution? work around?
My objective is to secure the http communication between my android app client and the GCE VM instance server.
Domain names are very cheap. Some are free. Since you do not care about a domain name, just purchase a cheap one and deploy a Let's Encrypt certificate. You will greatly minimize future problems.
Your other option is to generate a self-signed certificate with the IP address. I am not an Android developer so I cannot comment on self-signed certificate setup with a private root certificate.
I have installed packet capture on my android phone - Samsung Galaxy S7 edge running Android version 8.0. It is not rooted
I followed all the steps and installed the SSL cert as well.
Here is the app link
When i click on the start button to capture traffic internet connectivity for apps doesn't work. Chrome works on the phone though.
The apps that i tried which lost access to internet were Amazon, Owl Cam, Arlo
Any idea what setting or changes i am missing?
Looked up similar question on stackoverflow without any answers
1) Question1
Short answer:
There is no complete solution for your problem. And it is impossible to solve it. The reason why this problem occurs is the existence of "Certificate Pinning". Even simple rooting can not solve your problem.
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.
Long answer:
How a normal packet sniffer (that do not require root) works on Android.
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".
TSL/SLL and Ccertificate Authority
SSL (and HTTPS) is built almost entirely for the purpose of preventing any kind of "man-in-the-middle" attack. SSL runs over normal TCP connection. What it does is that it encrypt all traffic that is being sent between a client and server with a secrete key that is know only to the client and server. You may read more detailed and accurate information about how SSL works here
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.
How Packet Sniffing apps are normally able to sniff TLS/SSL packets?
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.
This way a Packet Sniffer app would normally able to capture and decrypt even those packets that are sent over an SSL connection.
Certificate Pinning
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.
So makers of some apps, particularly those which handle highly confidential data like credit card details, decided that they can no longer put trust on Android OS (or iOS, Ubuntu and Windows) in determining whether app is in fact connected the legitimate server or not.
So they started following the practice of certificate pinning.
What makers of those app do is that they may either embed a copy of server's SSL certificate itself with-in the app or embed a copy of SSL certificate of a Certificate Authority they use.
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.
Solution
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.
If they implement SSL on their wordpress site, will both the IOS and Android application automatically work through that SSL certificate or do we need to purchase another certificate. Please explain?
Apppresser creates a mobile wrapper around your site which means that any communication it has with the site will be over the protocol you have installed on the server. If you are using https:// when accessing the site when you create the app then it will be secure.
I'm using getUserMedia() in my web app which works fine when I test my app on localhost. But if I treat my laptop as server and launch app in Google Chrome browser of my android phone, it gives me the error:
getUserMedia() no longer works on insecure origins. To use this
feature, you should consider switching your application to a secure
origin, such as HTTPS. See https://goo.gl/rStTGz for more details.
When I checked [https://goo.gl/rStTGz][1] I got to know that getUserMedia() is deprecated on insecure origins. It is written that for development mode,
You can run chrome with the
--unsafely-treat-insecure-origin-as-secure="example.com" flag (replacing "example.com" with the origin you actually want to test)
How and where can I set this flag? Is there any other alternative?
This can be done from chrome://flags/ or about://flags.
Go to about://flags, search for unsafely-treat-insecure-origin-as-secure flag, and enable it. You will have to provide the origin which you want to be treated as secure.
Multiple origins can be entered as comma-separated values.
Relaunch your browser after making this change.
Note that the protocol part is also important, and specifying the IP address, or the domain name isn't enough. eg. http:// in http://192.168.43.45. If you are not using port 80, then you may have to specify that too.
The following is a screenshot from my mobile phone.
Mobile: Samsung Galaxy S10e
Android version: 10 (Android 10)
Google Chrome version: 79.0.3945.136
For local testing of a website I am building, geolocation was needed.
Geolocation is allowed in secure locations. I do have a production server with HTTPS certificate, but the development and the debugging process would become too slow if I have to upload content to it every time.
More info
https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
Move localhost to the device
One method is to run an HTTP server on your Android device. The consensus in answers to this question is that NanoHTTPD is worth trying. If you want a ready-made application, a web search for http server for android turned up Simple HTTP Server on Google Play Store. After copying the client side of your web application to the device and starting the server, you should be able to open http://localhost:12345 in Chrome for Android.
Or make your test server secure
You can test secure-context-only features without using --unsafely-treat-insecure-origin-as-secure by turning your existing test server into a potentially trustworthy origin. Follow these steps:
If you do not already own a domain at a registrar that bundles DNS hosting compatible with the dehydrated ACME client, register one. This incurs a fee, which recurs as long as you keep the domain active.
Point a subdomain at your test web server's internal IP address. It need not be reachable from the Internet.
Configure your test web server to respond to HTTPS on port 443 of this subdomain, using NameVirtualHost or the like.
Use the dehydrated ACME client with the appropriate dns-01 hook for your DNS host to obtain a certificate from Let's Encrypt for your test web server.
Install this certificate into your test web server.
I faced with this problem too, but in Chromium, Ubuntu. I solved the problem with running this command in console:
chromium-browser --unsafely-treat-insecure-origin-as-secure="http://localhost.dev:3000" --user-data-dir=~/.config/chromium/Profile 1
where localhost.dev:3000 is your website.
For other systems information there:
where is data directory
how to launch chrome and set keys
Short information about --unsafely-treat-insecure-origin-as-secure flag:
Treat given (insecure) origins as secure origins. Multiple origins can
be supplied. Has no effect unless --user-data-dir is also supplied.
Example:
--unsafely-treat-insecure-origin-as-secure=http://a.test,http://b.test --user-data-dir=/test/only/profile/dir
I didn't check, but for android you maybe can also set flags on chrome://flags page.
I have enabled HTTPS in Fiddler4 options, and it does can capture HTTPS communications from most Android Apps on my machine(With Android simulator, via WIFI proxy settings).
But for some Apps it always failed. e.g. Kayak.
It always says "Oops! There was a problem connecting to the internet. Please try again later.".
I notice Kayak App uses TLS 1.0(See following screenshot, it's from Microsoft Network Monitor 3.4), i think maybe this has something to do with it.
I also tried to set the protocols into "tls1.0"(See following screenshot), but has no effect.
Appreciate your ideas.
Update Further investigation revealed that some Android applications will not accept wildcards inside certificates' SubjectCN field if that field is encoded as BMPString. The makecert generator uses BMPString, so you can either untick the Use wildcards box or switch to the CertEnroll generator inside Tools > Fiddler Options > HTTPS > Certificates Generated By.
The text below is still applicable for apps which implement pinning.
TLS1.0 is perhaps the best-supported HTTPS protocol in Fiddler. You haven't shown what's in Fiddler's Web Sessions list or Log tab in the event of the failure, but my guess is that the Web Sessions list probably shows just a CONNECT and the Log tab has something like:
!SecureClientPipeDirect failed: System.IO.IOException Authentication
failed because the remote party has closed the transport stream. for
pipe (CN=*.kayak.com, O=DO_NOT_TRUST, OU=Created by
http://www.fiddler2.com)
Is that correct? If so, the most likely explanation is that the Android app in question has enabled certificate pinning.
From the Fiddler book:
Certificate Pinning
A very small number of HTTPS client applications support a feature
known as “Certificate Pinning” whereby the client application is
hardcoded to accept only one specific certificate. Even if the
connection uses a certificate that chains to a root that is otherwise
fully-trusted by the operating system, such applications will refuse
to accept an unexpected certificate.
To date, some Twitter and
Dropbox apps include this feature, and Windows 8 Metro apps may opt-in
to requiring specific certificates rather than relying upon the
system’s Trusted Root store. Firefox’s automatic browser update
feature will silently fail when Fiddler is decrypting its traffic. The
Microsoft Security toolkit named EMET can enable pinning in any
application for certain “high-value” sites (including Windows Live).
The Chrome browser supports pinning, but it exempts locally-trusted
roots like Fiddler’s.
When a Certificate-Pinned application performs a
HTTPS handshake through a CONNECT tunnel to Fiddler, it will examine
the response’s certificate and refuse to send any further requests
when it discovers the Fiddler-generated certificate. Unfortunately,
there is no general-purpose workaround to resolve this; the best you
can do is to exempt that application’s traffic from decryption using
the HTTPS tab or by setting the x-no-decrypt Session flag on the
CONNECT tunnel. The flag will prevent Fiddler from decrypting the
traffic in the tunnel and it will flow through Fiddler uninterrupted.
A very small number of HTTPS client applications support a feature
known as “Certificate Pinning” whereby the client application is
hardcoded to accept only one specific certificate. Even if the
connection uses a certificate that chains to a root that is otherwise
fully-trusted by the operating system, such applications will refuse
to accept an unexpected certificate. To date, some Twitter and
Dropbox apps include this feature, and Windows 8 Metro apps may opt-in
to requiring specific certificates rather than relying upon the
system’s Trusted Root store. Firefox’s automatic browser update
feature will silently fail when Fiddler is decrypting its traffic. The
Microsoft Security toolkit named EMET can enable pinning in any
application for certain “high-value” sites (including Windows Live).
The Chrome browser supports pinning, but it exempts locally-trusted
roots like Fiddler’s. When a Certificate-Pinned application performs a
HTTPS handshake through a CONNECT tunnel to Fiddler, it will examine
the response’s certificate and refuse to send any further requests
when it discovers the Fiddler-generated certificate.
Unfortunately,
there is no general-purpose workaround to resolve this; the best you
can do is to exempt that application’s traffic from decryption using
the HTTPS tab or by setting the x-no-decrypt Session flag on the
CONNECT tunnel. The flag will prevent Fiddler from decrypting the
traffic in the tunnel and it will flow through Fiddler uninterrupted.
If you're very serious about circumventing pinning, you can jailbreak the device and use any of a number of 3rd party toolkits to disable the pinning code.