I have a client-server application for Android.
For security reasons it was decided to raise between client and server SSH tunnel to protect the information transmitted.
For SSH I used a application ConnectBot.
Is there any sense in raising SSH to sew in the app itself?
P.S. Sorry for my English.
Related
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.
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.
I want to connect with my MQTT broker and get some data from Android App.
The Mqtt server has implemented with SSH layer for security reasons.
I want connect Mqtt broker over SSH tunnel. How to achieve this? IS there any opensource library?
Note : I am able to connect by putty.exe -ssh -L 1883:ipaddress:22 username#ipaddress and username and password.
If you are limited to SSH you might be able to use the one of the libraries mentioned in this answer:
https://stackoverflow.com/a/1367997/6581384
Otherwise, If your requirements are flexible, it would be easier to reconfigure the MQTT broker and client to use SSL/TLS instead.
I've a droplet on DO in which there is a MONGODB instance. I can connect through the "ssh user#ip" command in OSX using the terminal, but if i want to connect it with Meteor(local) i need to do port forwarding with "ssh -L port:localhost:portserver user#ip -f -N" and use launch Meteor with --port. To access the MONGODB i removed the password so you can access only with the ssh and enabled a firewall as suggested on the DO guide.
My question is: Is there a way to connect Meteor(local) with MONGODB without using the ssh tunneling each time? Or make it run the command before the meteor starting?This app is going to be on the phone(Android) for personal use so it won't go on production.
Second question: Is the ssh tunneling + port forwarding slower than connecting with user#password to MONGODB?
Third question: I'm going to use the ssh also for another mongoDB that will go in production, is it better to use user#password and connect using MONGO_URL var?
Thanks for the help!
There are 2 things to consider here:
- authentication
- encryption
the ssh tunnel insures encryption, while the password ensures authentication.
You can open up your DB to the world, and be protected by password, but if you don't have encryption, it's pretty much vulnerable to all sorts of network sniffing attacks (whenever on an open network or if someone is listening in the middle)
So, you would need encryption, that is SSL (TLS really, but best knowns as SSL)
You should looks at the MongoDB docs for this:
https://docs.mongodb.org/manual/tutorial/configure-ssl/
TLS can also be used for authentication, using a client certificate and a setting the server certificate to only accept those clients with a valid certificate. That's a little more complex as you'd need to configure your certification authority (OpenSSL most likely) to generate the right certs.
You can use tools like :https://github.com/cloudflare/cfssl to make your life easier in generating certs.
Hope that helps.
I have an application on an Android phone(emulator) which sends a https request. How I can see that request?
That is easily possible with a software such as Fiddler or Charles. They have an inbuild SSL server that will position itself in between the app and the server. It is kind of a "Man-in-the-Middle" attack, just that you are only attacking yourself.
After installing the software on your PC you will have to set the IP adress of this PC as proxy server in Android. And secondly you will have to install the Root Certificate that the software is using on your Android device.
As you are not braking any encryption and not reverse engineering any application here, I don't think this will classify as illegal. And as you need to have physical access to the device, you also cannot spy on anyone else than yourself.
If you are communicating with your own server, and you have access to its private key, you can use Wireshark to capture packets and have it decrypt the HTTPS traffic. If you are trying to reverse engineer someone else's app, this may or may not be legal and generally cannot be done.