Friday, March 27, 2015

Cyanogenmod on Moto E Revisited

When I first installed Cyanogenmod 11 on the Moto E a few months ago, it was very unstable, with much further development needed. Mobile data did not work whatsoever, the Google apps kept crashing, and the general feel was... meh. After that I reverted back to stock Kitkat for a while before deciding on AndroidArea51's AR10 for the Moto E. Arearom is an always an excellent choice if it is supported on your device. They're a friendly, small, and apparently underfunded community that still manages to churn out brilliant ROMs. I stayed on AR10 for a while, was very happy with it, and would totally run it again.

However, recently I began to notice reports of a completely stable Cyanogen (KK) CM11 build for the Condor, with CM12 (L) in the alpha stages of development. Today I made the decision to give CM on the Condor another shot. There is nothing wrong with AR10, I simply wanted a change of scenery for my mobile. As it turns out, this ROM has come a long way.

Installation was the most painless out of any ROM I can remember installing. I simply downloaded the zip file along with the GAPPS zip (the Google applications) and verified the md5sums. Than I threw them on a fresh SD card, stuck it in the phone, and booted to TWRP. Once you get that far, simply factory reset (cache/dalvik/data wipe), and navigate to install zip from sdcard. It's a good idea to have the md5sum file on the card as well, so TWRP can verify it again before flashing. Once that was done, I was greeted by the nifty Cyanogen Droid boot animation, and than asked if I wanted to create a CM account. Sure, why not.

Due to license restrictions and CM's pure open source commitment, you need to flash the GAPPS zip after you install the ROM. So, log in to your Google account, reboot to recovery, flash GAPPS, wipe cache/dalvik to ensure everything goes smooth, and reboot. At this point you have a fully functional, and totally awesome phone. Cyanogenmod feels very snappy and stable. Apps load as smooth as butter, and there is barely any noticeable lag. App-ops is built in to the settings and thus does not require Xposed to enable. OpenVPN appears to be pre-installed to the system, and I had absolutely no trouble connecting to a VPN. I attribute that more to knowing how to configure it than to CM. Google's apps no longer are randomly crashing on me, mobile data finally works, and even the APN settings were configured for me. Root access is protected by SuperSU, which is also built into the settings menu.

I was able to easily get my purchased apps back. The Xposed framework installation was a cakewalk too. Themes are available for Cyanogen ROMs in the Play Store, and virtually anything you want to change is customizable. This is one hell of a ROM.

I've only been running it for 3 hours and I already love it. I may stick with this ROM until CM12 Lollipop matures into an equally stable ROM,  at which point I may run that. If you are thinking of installing a custom ROM on your Moto E or similar device, CyanogenMod and AreaRom10 both come highly recommended.

Of course, there are a few extra packages every Android enthusiast should have:

  • The Xposed Framework, with Xprivacy is a must have. It does an excellent job protecting your privacy while not breaking app functionality. I won't ever live without it. Gravitybox is nice, but I may not need it on this ROM.
  • AFWall+, the best firewall for rooted Android systems I know of. Smartphones need firewalls for obvious reasons. OpenVPN is also a must have for smartphones, as the security of mobile networks is laughable. GSM encryption is totally broken, in case you didn't know.
  • Textsecure for end to end SMS/MMS encryption
  •  APM for awesome power menus, ES file explorer cause it's awesome,
  •  AIMSID to avoid creepy stingrays & rogue LE run base stations (which are disturbingly prevalent these days. Yes, that is a real thing indeed. As of this very moment, I am connected to a cell tower that should not exist, according to the OpenCellID database. I'd say the chances are around 25% that you are too.

Wednesday, March 25, 2015

I Hate Cloudfront & Amazonaws

If you care about your privacy and your device's security, chances are you run a browser plugin such as NoScript to block malicious and unnecessary scripts. NoScript is a must have for your security arsenal. You'd be amazed at how many scripts are executed when you visit certain websites. Even more ridiculous is that these scripts often are sourced from dozens of different places. This adds for a lot of opportunity for cross site scripting attacks, and makes running a script blocking extension much more annoying than it ought to be. Not even a year ago, it was not too difficult to block the bad while still enjoying a descent browsing experience. Things have changed.

You may have noticed that many big websites now have scripts coming from obscure, random URLs, like "askjajgn2dsnfaf5ef89dsudsih3ur3.cloudfront.com". This makes it impossible to efficiently use a script blocker, because if you completely block cloudfront, or amazonaws, than you cannot access a lot of web content. These big content providers seem to serve no useful purpose other than making it difficult for the end user to block ads, scripts, and protect themselves. Because many different types of content are hosting under the same parent domain, and the subdomains are so random, if you simply block the parent domain, you loose a lot of web functionality. If you block the subdomain, it makes no difference because the provider will just shoot some more crap at you from a different random subdomain.

We need to come up a solution for this. Perhaps a proxy of sorts, that is intelligent enough to intercept and separate the  useless/malicious from the necessary content, and than reassemble the page before it reaches the end user. The only problem is that I have no idea where to even begin building a program that could do that. So, I am just putting the idea out there. If someone could pull that off, they'd be famous.

Saturday, March 21, 2015

DNSCrypt-Proxy + Unbound + OpenVPN

DNS is akin to 'the weakest link' on the internet. We have evolved from http to https, yet DNS queries are still sent in plain text, for anyone to see, and leaving users open to cache poisoning, man in the middle attacks, and other crappy stuff. Finally, there is a solution! And no, its not dnssec, but rather dnscrypt-proxy.

I've been doing a lot of VPN related stuff lately, and today I figured out how to run dnscrypt-proxy on a vpn server, and route all client dns queries through dnscrypt. It is a wonderful, but irritating program to install. I thought I'd share my configurations here, to help others, but also so that next time I have to do this I will have a reference.

First, install dnscrypt-proxy. If you are running something Debian based on the server, this auto-install script is great. (If you're on another system, or don't trust that code, grab it from the main site.) However, I did have to create the init scripts and configuration files myself. Never fear, the instructions are here.

First, install dnscrypt-proxy and unbound. I used this debian auto-installer I found on github.

git clone https://github.com/simonclausen/dnscrypt-autoinstall

chmod +x dnscrypt-autoinstall.sh
./dnscrypt-autoinstall.sh && sudo apt-get install unbound



Edit: If the compiler is complaining about a syntax error....

checking whether to enable maintainer-specific portions of Makefiles... no
./configure: line 3264: syntax error near unexpected token `SYSTEMD,'
./configure: line 3264: `  PKG_CHECK_MODULES(SYSTEMD, libsystemd, have_systemd=yes,'


Than try my dirty hack.

Now let's configure unbound. Unbound will act as our dns-cache, and also our dns server for the
local VPN network.

cd /etc/unbound
vi unbound.conf


Edit your configuration so that unbound is listening on the VPN server IP address, as well as the localhost.

# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.

server:
    # The following line will configure unbound to perform cryptographic
    # DNSSEC validation using the root trust anchor.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
server:
   # access-control: 10.8.0.0/24 allow
    logfile: "/var/log/unbound.log"
    log-time-ascii: yes
    module-config: "iterator"
    do-not-query-localhost: no
    interface: 127.0.0.1
    interface: 10.8.0.1
    access-control: 127.0.0.1 allow
    access-control: 10.8.0.1/24 allow
forward-zone:
   name: "."
   forward-addr: 127.0.0.1@40
   forward-first: no

remote-control:
       control-enable: no


Check to make sure that dnscrypt has it's own user:

cat /etc/shadow | grep dnscrypt

 dnscrypt:!:16516:0:99999:7:::

If not, add one:

adduser --system --home /run/dnscrypt --shell /bin/false --group --disabled-password --disabled-login dnscrypt

Next, let's try to start dnscrypt-proxy. You may get a variety of errors, which we will fix. If it's already running, close it. Depending on your installation, you may have a configuration file in

/etc/default/dnscrypt-proxy

If not, (as was the case on my debian server), we will simply create an init script with the desired settings. Dnscrypt is random with it's installs. Try starting it up:

service dnscrypt-proxy start
sudo netstat -taupean | grep dnscrypt


If you see dnscrypt running in the netstat output, great. Now just edit the /etc/default/dnscrypt-proxy config file so that it is listening on a port other than 53, as not to conflict with our caching service, Unbound (port 40 in this example). If you get an error, proceed to the next step:

cd /etc/init.d
vi dnscrypt

And paste in this script:

#! /bin/sh
### BEGIN INIT INFO
# Provides: dnscrypt-proxy
# Required-Start: $local_fs $network
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: dnscrypt-proxy
# Description: dnscrypt-proxy secure DNS client
### END INIT INFO
# Author: Simon Clausen <kontakt@simonclausen.dk>
# Edited by Chev Y.
PATH=/usr/sbin:/usr/bin:/sbin:/bin
DAEMON=/usr/local/sbin/dnscrypt-proxy
NAME=dnscrypt-proxy
case "$1" in
start)
echo "Starting $NAME"


#Edit: In most situations, this simple line of code will do the trick:

$DAEMON --daemonize --user=dnscrypt --local-address=127.0.0.1:40 -R opendns



#I had to do this the first time though:

#   /usr/local/sbin/dnscrypt-proxy --local-address=127.0.0.1:40 --edns-payload-size=4096 
# --pidfile=/run/dnscrypt/dnscrypt-proxy.pid --logfile=/var/log/dnscrypt-proxy.log
# --user=dnscrypt -R opendns --daemonize


;;
stop)
echo "Stopping $NAME"
pkill -f $DAEMON
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: /etc/init.d/dnscrypt-proxy {start|stop|restart}"
exit 1
;;
esac

###End Init script

Remember, you may already have an init script in that directory. If so, skip that step.

You can choose a different name server to use, after the -R flag. There is a list of them here: https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv

Now update the settings:

 update-rc.d dnscrypt-proxy defaults

Restart Unbound and Start Dnscrypt:

sudo service unbound restart && sudo service dnscrypt start

Update your /etc/resolv.conf file to that it reads

nameserver 127.0.0.1

Set iptables so that the vpn network may access unbound:

iptables -A INPUT -s 10.8.0.0/24 -p tcp -m tcp --dport 53 -j ACCEPT
iptables -A INPUT -s 10.8.0.0/24 -p udp -m udp --dport 53 -j ACCEPT


And finally, edit either your server.conf or ccd/client file(s) so that DNS is served by the VPN server:

push "dhcp-option DNS 10.8.0.1"


Make sure that worked. From a client, run:

dig @10.8.0.1 google.com

And check that the query was answered by the nameserver you selected for dnscrypt to use. Note: if you continue to have trouble starting dnscrypt, check that directory /run/dnscrypt is owned by the user dnscrypt:

ls -la /run/dnscrypt
In some cases user dnscrypt must own this directory or the program won't start.


That's it. Congraduations, your VPN server and all it's client's DNS queries are now fully encrypted! Kiss cache poisoning goodbye.
 

Better Way To Force Traffic Through a VPN

I have been looking for a simple way to allow traffic to local subnets and a VPN server, but nothing else, and in a way that utilizes UFW (uncomplicated firewall). The script from my last post worked, but only if the default policies were set to ACCEPT, which is not what we want. It appears that UFW messes up your custom rules if they are in unmanaged chains. After a little research, I found a better solution.

This script allows access to all private IP ranges, so you won't have to adjust the rules if you are on a network with a different subnet. It's basically the same things, except the default input, output, and forward chains may be set to DENY, and UFW manages everything, so there's no chance of things breaking.

An even better solution would be to only allow outgoing traffic on the VPN port and only to the VPN IP address. And an even better solution would be to do that, and also make sure the connection originates from OpenVPN. That's tricky because it runs as user 'nobody' or 'root'... so you'd have to run it as it's own user.

However, for those of us that just want a simple 'killswitch' of sorts, this will do that trick. Original author Thomas Butz, modified by me for portability, flexibility, and also removed ipv6 multicast support.

#!/bin/bash
# Need root. Not doing "sudo everything" makes script more portable
if [[ $EUID -ne 0 ]]; then
   echo "Got root?"
   exit 1
fi



#First, define your vpn's listening port:
vpnPORT=1194
#And interface (usually tun0 or tap0)
vpnITF=tun0
#Flush our current chains:
#
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

# Make sure UFW doesn't break anything
ufw reset

#Now for our UFW defaults:
ufw default deny incoming
ufw default deny outgoing

ufw default deny forward

# DNS Queries should pass to initiate the connection
ufw allow out 53

ufw allow out $vpnPORT
# Allow out on virtual NIC
ufw allow out on $vpnITF
#Note: If there are any private subnets you need to reach while you are
#connected to the VPN, add them here:
#Example: ufw allow out on eth0 to 192.168.1.0/24
#Ensure access to all private networks.
#You may want to restrict these to certain subnets, up to you.
ufw allow out to 192.168.0.0/16
ufw allow out to 172.16.0.0/12
ufw allow out to 10.0.0.0/8

#
# These rules may be ommitted, but for the sake of 'just work!':
#
# Allow ipv4 muticast

ufw allow out to 224.0.0.0/24
ufw allow out to 239.0.0.0/8
# Allow local ipv6

ufw allow out to ff01::/16

#Finally, turn it on


ufw enable

This time, (I promise) it really is idiot proof.

Sunday, March 15, 2015

My WebRTC VPN Vulnerability Research Findings & Other Security Related Revelations

Recently a VPN vulnerability was discovered that affects all VPN protocols, including OpenVPN. WebRTC is a protocol supported by almost all major browsers that allows the user to make video and voice calls via the browser, without additional plug-ins.

"The vulnerability in WebRTC lies in the method used to establish browser-to-browser connections when one or both machines are behind a NAT. This NAT “traversal” method requires both browsers to execute a bit of JavaScript that connects to a STUN (Session Traversal Utilities for NAT) server on the public Internet, which then facilitates the browser-to-browser connection when NAT is in use. When WebRTC makes the connection to the STUN server, rather than sending only the public IP you are appearing to connect from using the VPN, WebRTC also sends over your actual public IP, as well as your LAN IP."
[source]

Apparently, even the open source browsers like Firefox and Chromium are affected. Users running NoScript on Firefox are probably unaffected, but I suggest you check to be sure. I'm sure Internet Explorer is affected, because it's the worst browser in the world, and although I did not test it myself,  it's safe to assume that if Google overlooked this, Microsucks certainty did as well. I am not sure about systems running OSX, but I do know that (thankfully) mobile browsers are immune to (this) exploit. I did extensively test the problem on my Linux systems, however. It is claimed that Linux systems are not affected, but I can confirm that this incorrect, at least to an extent. After testing Google Chrome, Firefox, and the open source Chromium, I can confirm that Linux systems running Chrome or Chromium definitively do leak the local IP addresses of both the VPN, and your first hop router's local network address. Thankfully, the public IP address remains concealed on Linux, as opposed to Windows, which leaks everything (go figure).

Although there is a patch for Chrome & Chromium, it did not fix the leak, at least in my case. Even Firefox on Linux, which supposedly is not affected, actually did leak my local IP's, until I patched it. I run NoScript, and so should you. The IP's were only leaked after allowing javascript to run, so NoScript does provide some protection. Unfortunatly for Chrome users, Script-Block did not...

I recommend visiting http://ipleak.net to see for yourself. If your local or public IP's are being leaked, you can patch the problem on Firefox like this:

Navigate to  about:config and search for Then right click and click 'toggle'. This disables WebRTC support entirely, effectively protecting Firefox. To be safe, navigate back to http://ipleak.net and confirm that this method worked.

As of this moment, users of Google Chrome and Chromium are out of luck. Although there a patch available in Chrome Web Store, it did not work for me. After enabling the patch, my local IP addresses were leaked just the same when I tested the browser again at ipleak.net. For the time being, I would strongly suggest that users of Chrome based browsers switch to Firefox, until a working patch is available.

You may not think it's a big deal if you use Linux, because your public IP is still concealed, but my network security experience tells me otherwise. Your local IP addresses can tell an attacker quite a bit about how your network infrastructure is configured. Discovering these IP's may help an attacker obtain access to your network, albeit under rare circumstances. At the very least, it certainty would help the enemy build a security profile of you, and also allow them to map out your network(s). If you are connected directly to the internet, for instance by plugging your computer directly into a DSL modem, than it's very possible that your public IP could leak, even on a Linux system. This is purely my assumption, as I do not currently have a direct line to test it on. I suspect that what protected the Linux/Firefox community was the NAT of the routers firewall, but I can't say for sure. As soon as I get a chance I will report back with my findings.

Consequently, and ideally, you should be using a unique IP range on your routers and VPN, not only to avoid routing conflicts, but also to protect against certain IP spoof attacks. You should change your router and VPN subnet to something random (especailly if you discover you have leaked your local IPs) to avoid these scenarios. There are three ranges of IP's reserved for private networking; the 192.168.*.*, the 10.*.*.*, and the 172.16.*.* range. Most home routers default to either 192.168.0.1/24 or 192.168.1.1/24 out of the box. I suggest you change your subnet to something random, such as 192.168.223.0/26 or 10.66.23.0/13. The 10.*.*.* range offers the most amount of unique subnets available, although the 192.168.*.* range should be sufficient for most small networks. And of course, change your VPN subnet as well. OpenVPN defaults to the 10.8.0.0/24 subnet. I suggest changing it to something arbitrary in the 10.*.*.* range,  like the example noted above. Subnet conflicts can make routing a nightmare, take it from me.

If you have been using Windows in combination with any of these browsers and a VPN, perhaps you should release your IP from your ISP's DHCP server and try to obtain another one. This should be easily doable, unless you are connected via point-to-point (such as over DSL). And if  you have been using a VPN to conceal sensitive activities, I suggest you back up all of your file onto an encrypted drive, and reformat your computers hard drive, making sure to overwrite all free and used sectors with 0's to avoid the possibility of data recovery by a foe (such as the NSA or any other intelligence community seeking to take away your freedoms).

I was curious as to the extent that the WebRTC exploit is being used, so I turned to my old friend Wireshark. While running a dumpcap on my eth & tun interfaces, I fired up Chromium. I discovered that the STUN protocol is being used virtually everywhere on the internet, and most frequently from the very questionable (and confirmed CIA run) amazonaws servers that follow us around the net. If you want to see for yourself, simply fire up a Linux machine, start Wireshark, and open up Chrome, and you will notice that even the Chrome 'recent tabs' page is using the STUN protocol (for what, I have no idea). That's messed up, Google... If any of Google's staff is reading this post, I suggest you look into that, and make sure that at the very least, this is intentional, and not some cross-reference scripting attack perpetrated by the NSA.

I've also suffered several hack attempts on my Google account lately, probably because until recently I would route some of my email accounts through a Tor proxy. I honestly am not a criminal, so it's disturbing to think that our government (who else has the resources to hack Google's TLS encryption?) is arbitrarily hacking civilian email accounts, probably in some fruitless anti-terror effort. After all, in the eyes of our government, we are all potential terrorists. Even more chilling is the recent revelation that meta-data alone is being used to coordinate drone strikes! So yeah, you read that correctly, there really is some quantum computer that is deciding who shall live and who shall die, based on people's browsing habits. Obama's personal selection of targets to kill based on sketchy intel, and usually resulting in more civilian deaths than anything, is pretty bad as it is. To think some greasy machine is now making those decisions based on freaking meta-data is fucking terrifying, so say the least.

Sadly, due to recent experiences, I would not depend on the Tor Network alone for anonymity. Too many relays appear to running SSL-strip, and too many are run by our enemies at the NSA. The distributed trust seems to have fallen apart. I've also had to stop running TOR relays on any servers that I rely upon for security, because it seems every time I start running Tor, strange things start to happen on my server. It is really quite a shame, because I used to run three relays, one of which was an exit relay (and God knows we need more exits), but I can no longer do that and remain secure. I currently only run one middle node relay, and one bridge. I don't think I will ever even run the Tor Browser on the personal computer again, because I no longer trust the network. After all, it was invented by DARPA, and is still partially funded by the U.S. Government. To add insult to injury, American ISP's have began targeting users of Tor, while our government endorses use of the network by oppressed peoples in other countries. The hypocrisy is quite ironic. I am not saying that Tor is dead, useless, or broken, I am simply recommending that if you need to use it, you should boot to a live USB system, such as TAILS, to ensure that if there is a backdoor in the software, or an exploit we are unaware of (I am almost positive that there is), your personal system will not be compromised. Live systems leave no trace of what you do with them, because they never touch your hard disc (unless you mount it), and run strictly off your RAM.

When I find a working patch for Chrome based browsers, I will let you know. If you know of a method to patch Chrome, please leave me a comment so that I can update this post. Be safe, stay vigilant, and ditch Windows once and for all. You will wish you switched to Linux years ago. Peace.

Friday, March 13, 2015

OpenVPN on Android Over AT&T 3G Part 2.5

This is a follow up to my original post regarding connection to an OpenVPN server over AT&T's mobile networks. I have finally figured out what needs to happen for this to work. These are the configurations that work. I have highlighted the important Android specific options:

Server:

mode server # Neccessary if you are using TLS auth, regardless of network
tls-server # TLS is not mandatory, but I recommend you use it.
local 123.45.678.9 # Your servers IP
port 30333 # Pick a random port with no official usage. Port 443 never worked for me on  Android, not sure why. Just keep trying till you find one that works.


topology p2p # Force point-to-point tunneling (unless you have windows clients)

proto udp # TCP over TCP sucks, you should know that.
dev tun # TAP is not supported on Android.
ca ca.crt # Your certificates, of course.
cert server.crt
key server.key
dh dh.pem
server 10.8.0.0 255.255.255.0
# Server IP, you can change this
ifconfig-pool-persist ipp.txt # Useful if you need to remote access your device 


client-config-dir clients Allows different options for clients *
keepalive 7 80 # Default 10/120, I use a lower setting because mobile networks tend to drop  connections sometimes, so ping more frequently to keep track of your connnection.


tls-auth /etc/openvpn/.certs/ta.key 0 # HMAC firewall, protected me from heartbleed! 


cipher AES-128-CBC # This & Blowfish work well on embedded devices, no need for AES-256 yet. The government would love for to believe that they switched to AES-256 because  they know how to crack AES-128, but that's a load of horse shit. It would take about 10 billion years to try all of the possible combinations in a 128 bit key. Brute force attacks are a waste of time these days. If the NSA wants to decrypt your traffic, they will need to get your keys another way, for example by hiding malicious code in an app that you thought was safe because Google allowed it in the Play Store.





comp-lzo # Just do it...
max-clients 10 # Not needed, but limit it to the number of clients that will be connecting for securities sake.


user nobody # Always do this for security.
group nogroup # And that.
persist-key # And this.
persist-tun # And also that.
status openvpn-status.log # It's good to know who is logged in.
log openvpn.log # I choose this over 'log-append' because I keep no logs anyway.


verb 3 # Keep this low unless you are debugging, verbose logs are more overhead for your server.

auth SHA256 # SHA512 and certain other ciphers simply do NOT work over AT&T's 3G. SHA1 and SHA256 DO work, so go with SHA256, (if you can) because SHA1 is less secure.


tun-mtu 1500 # This is key! Without specifying the MTU, nothing works! Don't ask me why.

float # This should help you maintain your connection while switching networks.

* client-config-dir clients : In your devices configuration, you will need these options to force all traffic to route through the VPN rather than the normal route:

push "redirect-gateway local def1 bypass-dhcp" # The local flag may or may not be necessary. I am not sure what this does, I can't find descent explanation anywhere. It actually makes no sense to use the local flag, this is intended for clients and servers that are on the same network.

push "dhcp-option DNS 208.67.222.222" # Don't forget to push DNS. I may abandon OpenDNS, as apparently they keep logs of every query they ever get. I don't like that. 


push "dhcp-option DNS 208.67.220.220" # Make sure you have two at least
ifconfig-push 10.8.0.99 10.8.0.100 # This is not necessary, but its useful.


Client:

I am using OpenVPN for Android, available from the play store. Import your keys and certs, then delete them! Android SD card security has a ways to go, and most people are not running on rooted phones, so they can't effectively control what apps get access to what. Factor that in with the disgusting amount of ad networks found in Android apps these days, and if you don't delete those keys, your traffic will be decrypted. Ad companies don't usually bother to encrypt your stolen data before transmitting it, so the NSA will easily extract those keys. In fact, I recommend you not only delete them, but shred them. Use a linux computer with secure-delete installed and run

$ srm -R /path/to/certs

Configure the settings you used in your server configuration, and then go to Advanced > Custom Options. Type in the following two directives, with a return in between them (we need them on two lines in the generated client config):

tun-mtu 1500 # Don't forget this!
auth nocache # Make damn sure the passphrase to your key is not cached in your phones memory! This is important!!!

Here is the missing explanation of options I could never find...

https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage

Some other things to consider...

If your phone does not have a quad core processor, you may be better off leaving the auth cipher to SHA1, because it is less overhead for the CPU. Also, on 3G networks VPN's can be so slow that it's hardly worth the effort at times. It depends a lot on where your server is located. I can deal with a little speed drop, but the latency increase can be aggravating. I also suspect AT&T is throttling VPN users, as well as doing some other dirty things. Sometimes when I go to dnsleaktets.com, my phone will disconnect and then reconnect to the mobile network before the page loads... that spells FISHY to me. Make sure you are using a firewall because I have found Android disobeying the routing rules in the past.

In conclusion, VPN's on Android systems need more development. Wireless carriers need to stop being dicks. The entire process will be painful trial and error, every step of the way. Some things work and some things do not. For instance, switching from WiFi to mobile data works fine, but vice versa and you will need to reconnect to the VPN. I'll close by reminding you to use easyrsa3 and a separate machine to sign all of your certificates. As Cartman would say, "That's hella important."

Friday, March 6, 2015

Adventures in VoIP Land...

Once in a while something retarded may happen, something that causes you to temporarily loose your phone service. If your life seems to be governed by Murphy's Law, as mine does, than it does not hurt to have an extra phone number, and one that you can use over wifi networks. Preferably the VoIP app should allow unlimited texting and calling, and the app definitively must not contain any irritating banner ads. Ad networks are an inherent problem on Android, but there are ways to stop the privacy  mongers dead in there tracks.

Perhaps the most well known 'free' voice over IP app is Talkatone. But it sucks. First of all, the banner ads and ad networks are unacceptable. With Lucky Patcher, Ad-Away, and Ad-Free (with various settings and combinations) I was able to remove all but one of Talkatones banner ads. I thought I could live with that. But then today Talkatone informed me that I used up all my free minutes. I can't deal with that. I would totally buy the pro version, if I had any money... But that is why I am in this boat to begin with.

GrooveIP is an excellent, truly free VoIP app. But it does not support text messaging (yet). However, today I discovered RingTo. This app works alongside GrooveIP, and allows you to use your current GrooveIP number for SMS. Perfect. The installation process was pretty straight forward, and within 5 minutes I had a functional phone with no ads to drive me nuts.

Hopefully Google will bring back Google Voice. Until that day, GrooveIP with RingTo is probably the way to go. I tried Textfree, WhatsApp, Textra, and a bunch of other apps. Most had privacy issues up the ass, and if it were not for Xprivacy, God only knows what could have happened to my data. So save yourself the trouble, and give GrooveIP/Ringto a try, next time you find yourself without cell service.