Dear Anonymous;

There's no doubt that you have made the right decision taking on ISIS after the Paris attacks. You are a powerful group, and one that has proven it's capabilities time and time again. From Hal Turner to Scientology, I have always enjoyed watching you kick ass. There's just a couple of things that I'd like you to consider as you go forward.

Right now we are seeing these terrorists turn to the dark web for communication, and I hate to say it, but that is an unintended consequence of your campaign-- although it's also an inevitable outcome. You may be thinking of intercepting traffic traversing tor exit nodes that you control to unmask them. As far as I am concerned, that's fair game because exit node traffic is sent in plain text, and unless encrypted, nobody can have a reasonable expectation of privacy at that point anyway. However, I heard talk on IRC of attempting to backdoor software that these groups use for encrypted communications. That is slippery slope. and this is why...

While I doubt the majority of anons think that's a good idea, I'd like to remind you not to forget to uphold the open internet's values of respecting privacy, freedom of speech, and equal access. Of course terrorists deserve no such graces, but lots of activists, journalists, refuges, and probably even some of your own members rely on that software to communicate securely as well. Be mindful of collateral damages...

If we start enabling surveillance and opening security holes in communication software in the name of fighting terrorism, than we are no better than the NSA. Don't forget why you're in this field to begin with. If we inadvertently erode away our own freedoms than we'll loose this war without firing a shot. After all, freedom is kind of what this is all about, right?

On the other hand, if you can slip some shellcode onto a server belonging to these mindless radicals and unmask them, than by all means, go for it. Think of it like hunting-- know your target, and beyond. Don't let them get the better of you. That's all I wanted to say. Good luck.

NO, 'Encryption Backdoors in Software' Won't do a Damn Thing to 'Stop Terrorists Before They Act'

And here is why... This is a little script I wrote using ncat to demonstrate just how easy it is to generate your own private keys and have a secure SSL session, immune from backdoors, NSA pricks, Interpol, and God: # generate some keys openssl genrsa -out $FILENAME.key 1024 openssl req -new -key $FILENAME.key -x509 -days 3653 -out \ $FILENAME.crt  # server: ncat --broker -- listen -- chat --ssl --ssl-cert $crt --ssl-key $key $host $port # client:  while true; do                 read -p ">> " message                 echo -e "[$name@$hostname:] $message "         done | ncat --ssl-verify --ssl-trustfile $crt $host $port The full scripts can be found here in case anyone is interested.  So this is just a very simple chat script using ncat, and good luck ever getting a 'backdoor' into ncat (lol), or openssl for that matter. All the source code for openssl can be found right here. All the ncat source can be found right here... so unless you plan on fundementally re...doing(?) the entire computer industry... good luck with that. Go do some real police work instead. I am getting sick of writing these blogs trying to explain why everything the government wants to do is not only a terrible idea, but makes no sense whatsoever. So I will end by linking you to Google and telling you to use your own damn brain.

Bypassing UDP/443 Blocks for Dnscrypt-Proxy

I've long been a fan of dnscrypt-proxy. It solves what is perhaps the internet's biggest security issue-- the domain name system. DNS requests are sent in plain text and are easily intercepted and altered. Cache poisoning, MITM attacks, and attacks from Nazi system administrators are all possible and quite simple thanks to the aging protocol. And that is why everyone ought to be encrypting their DNS requests via something like dnscrypt-proxy.

Recently, I've noticed a sick trend gaining traction. Dnscrypt uses UDP port 443 for resolution requests, and it seems that a lot of ISP's are blocking this port and/or forcing their customers to fall back to plain-text DNS. Although theoretically the program can operate over TCP as well, it's sort of a pain because I keep strict outbound iptables policies on my systems. I don't like giving dnscrypt more outgoing ports than it needs, not to mention TCP is slower.

What really ticked me was when I figured out why dnscrypt was not working on Digital Ocean's servers whatsoever... Yeah, you guessed it-- they're blocking outbound requests on UDP/443. Well done, D.O.! Rather than surrender to such insanity, I turned to Google for help, and found a post on twitter (can't find it at the moment) explaining that Digital Ocean is indeed doing what I suspected, and in response, a couple of the dnscrypt servers are now listening on UDP 5353 as well.

This hack worked perfectly, and within a few minutes I had an encrypted DNS server working on one of my D.O. nodes again! This is especially important to me because I am also administering some OpenVPN servers, and I like to provide security to the clients by serving DNS to them through dnscrypt-proxy combined with unbound for caching.

If you are experiencing similar issues from ISP blocks, than give this a try. Depending on how you installed dnscrpypt, you will have a configuration file somewhere that designates which nameservers you are using. I typically use this script for installation, so mine is located at /etc/init.d/dnscrypt-proxy .

Open the file and make a couple modifications, and you'll be back in buisiness:

#! /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

# Authors: https://github.com/simonclausen/dnscrypt-autoinstall/graphs/contributors
# Project site: https://github.com/simonclausen/dnscrypt-autoinstall

PATH=/usr/sbin:/usr/bin:/sbin:/bin
DAEMON=/usr/local/sbin/dnscrypt-proxy
NAME=dnscrypt-proxy
PORT=5353
ADDRESS1=77.66.84.233:$PORT
ADDRESS2=176.56.237.171:$PORT
PNAME1=2.dnscrypt-cert.resolver2.dnscrypt.eu
PNAME2=2.dnscrypt-cert.resolver1.dnscrypt.eu
PKEY1=3748:5585:E3B9:D088:FD25:AD36:B037:01F5:520C:D648:9E9A:DD52:1457:4955:9F0A:9955
PKEY2=67C0:0F2C:21C5:5481:45DD:7CB4:6A27:1AF2:EB96:9931:40A3:09B6:2B8D:1653:1185:9C66

case "$1" in
  start)
    echo "Starting $NAME"
    $DAEMON --daemonize --ephemeral-keys --user=dnscrypt --local-address=127.0.0.1 --resolver-address=$ADDRESS1 --provider-name=$PNAME1 --provider-key=$PKEY1
    $DAEMON --daemonize --ephemeral-keys --user=dnscrypt --local-address=127.0.0.2 --resolver-address=$ADDRESS2 --provider-name=$PNAME2 --provider-key=$PKEY2
    ;;
  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

exit 0

There are only a couple nameserves listening on port 5353, so make sure you use one that is, such as 'dnscrypt.eu' . Now just restart the daemon:

service dnscrypt-proxy restart

OR

 /etc/init.d/dnscrypt-proxy restart

... and enjoy encrypted, untamperable DNS again!

By the way,  this blog is sort of moving to my new website, https://chev.tech. That's it for today.