Develop Reference

EAP-TTLS and CA certificates on Android when connecting to WPA2 Enterprise WiFi

I am setting up a WPA2 Enterprise-secured Wifi for my company. I set up a RADIUS server (FreeRadius) which talks to our Azure AD for authenticating our users. Because of the nature of the connection (RADIUS<-> AzureAD), EAP-TTLS is the only protocol that can be used.
Since EAP-TTLS does server validation via server certificate, but the client-side does not have to be validated via client certs, that makes it easy to deploy to employees connecting to our WiFi since I don't have to deploy client certs to all the client devices.
Problem is I don't understand the exact process of connecting the clients.
Example #1: When connecting an iOS device to the WiFi, I get the dummy CA and server certificates shown on my screen that were generated on my RADIUS server. I can choose to either trust them or not. This way server validation is done, which makes the connection secure and makes complete sense to me.
Example #2: When connecting an Android device, I don't get this prompt with the CA and server certificates. What I get is an option to either:
Select a CA cert -> This means I have to deploy the RADIUS-generated CA cert to EVERY client device. This does not make sense to me because in the end it's like I am deploying client certificates to devices which complicates the setup a lot and negates the main advantage of EAP-TTLS.
Don't validate -> This means that the device just connect to the network without validating the server at all. This way, I can connect to the WiFi too but that is not acceptable since the client does not verify the server at all which makes the network not secure.
Use system certificates -> Selecting this prompts the user to enter a domain. I suppose this option uses the already pre-installed CAs Android has by default, but I am not sure what to make of it. What domain is the device asking for? I can't connect this way if I enter my company's domain, the RADIUS server says that the client has an unknown CA cert. Makes sense since the device is not using it's generated CA cert.
All in all, I understand the way iOS does the connection and in my mind that is how EAP-TTLS is supposed to work, with server validation and all. Android makes things very confusing, since it is making me install the CA on the device manually instead of just getting it via the started connection (like iOS does).
Can someone point what I am missing here? Am I wrong in some assumptions or is this just an Android technicality that is supposed to work this way? What would be the easiest setup solution in this case?
Thanks in advance!

Using Wireshark on a rooted android device with ssl decryption

The question asked here is quite outdated and vague, especially considering the changes with android 7.0+ and ssl. I've primarily used burp proxy to see the traffic going in and out of my device. My android is rooted and I've exported and installed burp suites root ca certificate according to this tutorial. This allows me to see httpS and wsS traffic decrypted in clear text. The only issue with burp suite is http and websocket are the only protocols it natively supports. I have an android application that uses tcp socket and ssl. I want to use Wireshark to inspect that data. I've heard suggestions on how I might go about doing this. One of them is use something called tcpdump but I'm unfamilier and confused with that and other methods and I need to make sure I can decrypt the ssl.

You can redirect the traffic from the rooted android device to a transparent TLS proxy, which decrypts and re-encrypts the TLS traffic while leaving the WebSocket data untouched. Both PolarProxy (our tool) and SSLsplit can export the proxied traffic to a PCAP file in decrypted form. This allows you to inspect the decrypted WebSocket traffic in Wireshark without having to bother with key log files.

Is the Service serveo.net safe and private?

I created a reverse tcp payload for android on port 3333. and forwarded it with serveo. But the main Concern is anyone in the world can listen on this port and get the reverse connection. How can i make this connection private so only i can access it ?

Used serveo and ngrok and stuck with ngrok. I believe them when they say it's safe but I also added additional layers of security to my host machine that issues the SSH, by hardening the SSH config and opening up the minimum ports required in iptables. For example I limited inbound SSH traffic only from my local subnet. I did this because while learning about ngrok, I found on the net (forgot where) that there is a chance someone can determine the IP of the host machine.

Serveo is just using reverse proxy. He can see you from server as ssh client who allowed server to move traffic to local server.
I created my own server using nginx and Amazon ec2 instance, certbot for free ssl.

Packet capture app once started doesn't have internet connectivity for other apps anymore

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.

How to connect to microsoft VPN server with MSCHAPV2 authentication

Could you please give some guidance where to dig?
What I have:
I have a device (HTC One X) with ICS (Android 4.x) on board.
My Company has a corporate VPN server based on Microsoft VPN Services (RRAS and so on).
Microsoft VPN Server has a policy applied to it which tells it to accept only connections with MSCHAPV2 authentication.
What I need:
I need to make VPN connection from my device to my corporate VPN Server.
Questions:
Is it possible to get my need with ICS's onboard VPN client?
Is there any 3rd party VPN client which does it?
How to ask Google about my need?

Android supports MS-CHAP V2, but that is part of phase 2 authentication and is configured automatically during handshake. The question that needs to be answered first is what VPN protocol is being used?
PPTP? Check if you need to enable encryption (MPPE)
L2TP/IPSec? It's possible all of them are supported; you may also have to check whether it's PSK or RSA.
If it's RSA, you need to install the certificate for connecting.
SSTP? SSTP is only available on Windows.
You should also be aware that MSCHAPV2 on PPTP is considered broken (cryptographically unsafe). And SSTP is not supported on Android. I'm assuming SSTP is an option and OpenVPN isn't because the company is using MS VPN.
To answer your questions:
1. If the server enabled PPTP or (L2TP/)IPSec, Android 2.x+ should be able to connect, as long as the vendor didn't strip out the built-in VPN in stock Android.
2. Any 3rd party VPN client should support these two widely used protocols.
3. Google's android repository on Google Code should be consulted if there are issues with the VPN client: https://code.google.com/p/android/issues/advsearch

I don't have much idea about VPN in Android, but there are a couple of solutions you can try:
Install StrongSwan VPN client - https://play.google.com/store/apps/details?id=org.strongswan.android&hl=en_GB - but dunno if it would work or if it requires a server software. Best guess is to try it.
Install a custom ROM (CyanogenMod/AOKP/Pacman/Paranoid/etc) and then try. Usually, custom ROMs include such functionality that isn't present in the (crappy) stock ROMs.
Good luck :P