100% HTTPS in the internet? Non-Profit makes it possible!

HTTPS on 100% of websites in the internet? This just has gotten a lot easier! Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Research Group (ISRG), a Section 501(c)(3) Non-Profit entity dedicated to reduce financial, technological, and education barriers to secure communication over the Internet.

Let’s Encrypt offers free-of-cost certificates that can be used for HTTPS websites, even when these websites are ran for commercial purposes. Unlike traditional CA’s they don’t require cumbersome registration, paperwork, set-up and payment. The certificates are fetched in an automated way through an API (the ACME Protocol — Automatic Certificate Management Environment), which includes steps to prove that you have control over a domain.

Dedicated to transparency, generated certificates are registered and submitted to Certificate Transparency logs. Here is the generous legal Subscriber Agreement.

Automated API? This sounds too complicated! It is actually not. There are a number of API libraries and clients available that do the work for you. One of them is Certbot. It is a regular command-line program written in Python and the source code is available on Github.

After downloading the certbot-auto script (see their documentation), fetching certificates consists of just one command line (in this example certs for 3 domains are fetched in one command with the -d switch):

certbot-auto certonly --webroot -w /var/www/example -d example.com -d www.example.com -d blah.example.com

With the -w  flag you tell the script where to put temporary static files (a sub-folder .well-known  will be created) that, during the API control flow, serve as proof to the CA’s server that you have control over the domain. This is identical to Google’s method of verifying a domain for Google Analytics or Google Webmaster Tools by hosting a static text file.

Eventually, the (already chained, which is nice!) certificate and private key are copied into /etc/letsencrypt/live/example.com/ :

fullchain.pem
privkey.pem

Then it is only a matter of pointing your web server (Nginx, Apache, etc.) to these two files, and that’s trivial.

Let’s Encrypt certificates are valid for 90 days. The automatic renewal of ALL certificates that you have loaded to your machine is as easy as …

./certbot-auto renew

… which they suggest should be put into a Cron job, run twice daily. It will renew the certificates just in time. No longer do you have to set a reminder in your calendar to renew a certificate, and then copy-paste it manually!

A bit of a downside is that Let’s Encrypt unfortunately doesn’t support wildcard domain certificates. For these, you still have to pay money to some other CA’s who support them. But in above shown code example, you would generate only 1 certificate for the domains example.com and its two subdomains www.example.com and blah.example.com. The two subdomains are listed in the Subject Alternative Name field of the certificate, which is as close to wildcard subdomains as it gets. But except for SAAS providers and other specialized businesses, not having wildcard certificates should not be too big of an issue, especially when one can automate the certificate setup.

On the upside, they even made sure that their certificates work down to Windows XP!

Today, I set up 3 sites with Let’s Encrypt (one of them had several subdomains), and it was a matter of a few minutes. It literally took me longer to configure proper redirects in Nginx (no fault of Nginx, I just keep forgetting how it’s done properly) than to fetch all the certificates. And it even gave me time to write this blog post!

Honestly, I never agreed with the fact that for commercial certificate authorities, one has to pay 1000, 100 or even 30 bucks per certificate per year. Where’s the work invested into such a certificate that is worth so much? The generation of a certificate is automated, and is done in a fraction of a second on the CPU. Anyway, that now seems to be a thing of the past.

A big Thumbs-up and Thanks go to the Let’s Encrypt CA, the ISRG, and to Non-Profit enterprises in general! I believe that Non-Profits are the Magic Way of the Future!

Icon made by Freepik from www.flaticon.com 

Teamviewer alternative: How to get a Remote Desktop VNC connection via SSH over an intermediate server, avoiding firewalls

Note: This post is 7 years old. Some information may no longer be correct or even relevant. Please, keep this in mind while reading.

What to do when Teamviewer suddenly doesn’t connect or you can’t or don’t want to use it for other reasons? What if a friend needs urgent assistance and you need to see his screen to help out? Standard Open Source tools to the rescue! If you know how to use SSH from the command line and have access to an user account on a remote server running SSHD, then this article will save you!

Teamviewer-like products are so popular because they solve a real problem: To connect from one household computer to another is not straightforward because we all use regular modems/routers to connect to the internet. They are usually not set up for Port Forwarding. In laymans terms this means: You can initiate a connection to  the internet, but the internet never can initiate a connection to you. This quandary has only one solution: an intermediary is needed. Teamviewer-like products all offer such intermediary servers. Data is never directly sent from one computer to the other. Data is passed through a server (which allows for all kinds of spying by the way, if the encryption is not good enough!)

There are tons of (unfortunately for me) half-working instructions in the web about how the commands must look like. I took me several hours to wrap my mind around the problem. For this article, I’ve decided to make an image gallery so that you can see easier what is going on behind the scenes. Running just 4 commands will do the trick!

The following list and image shows the starting point of our situation:

  • We are sitting in front of the computer called “sittinghere”.
  • We want to see the screen of the computer called “overthere”.
  • There is a server called “hopper” which runs an ssh daemon (sshd) listening on the standard port 22. Our data will ‘hop’ though there, hence the name “hopper”.
The initial battlefield: Regular firewalls are installed for "sittinghere" and "overthere". "hopper" has a firewall with only port 22 open.
The initial situation: Regular firewalls are constrict “sittinghere” and “overthere”. “hopper” has a firewall with only port 22 open.

We instruct our friend, sitting in front of the computer “overthere”, to start any kind of VNC server. There are many products for Windows, Mac OS, and Linux available. I’m using Linux and decided for x11vnc because it allows access to the screen of the currently logged in user instead of starting a new user session. The command is:

x11vnc -nap -noxdamage -passwd PASSWORD -display :0 -forever -bg

After this command, our situation has changed. See the following image. The VNC server has started listening on port 5900 (see lower right corner):

A VNC server is started "overthere". It listens on port 5900.
A VNC server is started “overthere”. It listens on port 5900.

Now we have to instruct our friend, sitting on “overthere”, to run a ssh command to connect to “hopper”. You can make a little batch script for this to make it more convenient, but this is not the focus of this article. The command is:

ssh -R 7001:localhost:5900 hop@hopper.com

With this command, sshd on “hopper” is instructed to create a socket on port 7001. And when someone connects to this port, it will be as if the same connection had been made on “overthere” port 5900. In the code above, “localhost” refers to the computer “overthere” because the command is executed on this computer.

Let’s see how our situation now looks like:

An ssh client is started "overthere" with Remote Port Forwarding options. A connection is made to sshd, running on "hopper". sshd opens a port localhost:7001 and listens for incoming connections from localhost.
An ssh client is started “overthere” with Remote Port Forwarding options. A connection is made to sshd, running on “hopper”. sshd opens a port on localhost:7001 and listens for incoming connections.

Now that “overthere” has done its connection to “hopper”,  it is time for “sittinghere” to connect to “hopper” too. Here is the command:

ssh -L 7002:localhost:7001 hop@hopper.com

This means: A socket on port 7002 will be created on localhost (“sittinghere”). If someone connects to this port, it will be as if the same connection had been made on port 7001 on “hopper”. Here’s the new situation:

"sittinghere" starts ssh with Local Port Forwarding options. It connects to sshd running on port 22 of "hopper". It also creates port 7002 on localhost and listens for incoming connections.
“sittinghere” starts ssh with Local Port Forwarding options. It connects to sshd running on port 22 of “hopper”. It also creates port 7002 on localhost and listens for incoming connections.

Now, remember that a connection to port 7001 on “hopper” will have the same effect as if the same connection had been made on “overthere”. This means we will have a kind of ripple-through effect: As soon as we connect to port 7002 on “sittinghere”, the connection will ripple through until it connects to port 5900 of “overthere”. And this endpoint is our VNC server.

Now let’s connect with a VNC client from “sittinghere” to “overthere”. You will find lots of good VNC clients in the internet. Just connect to localhost:7002 which is equivalent to 127.0.0.1:7002.

This will start our connection cascade, and the final situation looks like this:

On "sittinghere", a VNC viewer is started and told to connect to localhost port 7002. This connection is detected by ssh which makes sshd running on "hopper" connect to port 7001, which causes ssh running on "overthere" connect to port 5900. Now the route is complete and we can see the remote screen!
On “sittinghere”, a VNC viewer is started and told to connect to localhost port 7002. This connection is detected by ssh which makes sshd running on “hopper” connect to port 7001, which causes ssh running on “overthere” to connect to port 5900. Now the route is complete and we can see the remote screen!

Congratulations, we’re now all connected through! If you have set a password (we’ve set it to “PASSWORD” in the above example), you now will see the remote screen. Note that we didn’t even have to execute a command on “hopper”, nor even reconfigure any firewall! My experience is that the quality and speed of the transmitted remote image is very good.

The SSH connections will stay alive until you terminate them. So, just type “exit” in the ssh terminals opened at “sittinghere” and “overthere” that we have been opened previously (to “hopper”).

Debian Linux HowTo: Bridging WLAN to Ethernet for Access Point (Infrastructure Mode) for Android Phones

Note: This post is 8 years old. Some information may no longer be correct or even relevant. Please, keep this in mind while reading.

I am using the Wireless (WLAN) mainly to connect my mobile phone to the internet, for faster downloads and to test mobile apps. First, I only used Apple devices (such as iPad, iPod, iPhone, etc.), and those could connect without problems to a so-called Ad-Hoc network. However, many mobile devices, such as Android, unfortunately will NOT connect to an Ad-Hoc network, for reasons which are very well explained on this How-To Geek posting (it taught me about many things I didn’t know!).Since I’ve recently given up on Apple products and only use Android phones, I needed a definite answer to this problem. And I found it today.

As you may know, there are basically 2 modes to operate a wireless network: “Ad-Hoc” and “Infrastructure” (the latter one also called “Access Point” or shorter “AP”) mode. Cheaper Wireless cards only support the Ad-Hoc mode, but do NOT support the AP mode.

So, I thought: Let’s just buy a WLAN card which supports the AP mode. I bought the Intel Centrino Advanced-N 6235 (Link to official Intel product page). I found it here on Amazon: Intel Network 6235AN.HMWWB Centrino WiFi Card Half Mini PCI Express Advanced-N 6235 Dual Band Bluetooth

It is supported beginning with Kernel version 3.2. I mounted it, and was planning to use the Network Manager of Debian Wheezy / Gnome 3 to quickly set up an AP Hotspot. Easier said than done! Because even though there is an option to set “Infrastructure” mode, my Android phone still would not connect. It would simply write “Ad-Hoc Connecting” and stop there, even though I had set the Infrastructure mode.

Network Manager in Debian Wheezy / Gnome3
Network Manager in Debian Wheezy / Gnome3
Network Manager in Debian Wheezy / Gnome3 offering "Infrastructure" mode which is not recognized by an Android smartphone, even though the network card supports AP and is fully supported by the Kernel.
Network Manager in Debian Wheezy / Gnome3 offering “Infrastructure” mode which is not recognized by an Android smartphone, even though the network card supports AP and is fully supported by the Kernel.

I had to wade through a LOT of web postings, all suggesting not-really-working ‘solutions’ until I found a synthesis of all the collected information that worked for me.

It turns out that you need a dedicated user-space program for ‘driving’ the AP hardware contained in your network chip, and this is hostapd . It seems, you can’t do without.

I found this blog which offered a bash script to automate the job, but it only worked for Ubuntu, and not for Debian due to different configuration files. I also found this little Qt program that made the wireless connection work for my phone, but disconnected my laptop from all networks.(It could have been my fault due to misunderstandings though…)

This blog did a good job in explaining what hostapd  is and gives basic installation and configuration instructions. You should read the post in any event. However, the suggested final solution did not work for me. Yes, the phone would see the generated wireless network, would connect, but immediately disconnect. I have not found the reason for the failure, but it probably lies hidden in the complexity of the set-up which painstakingly involves

  • a locally run DHCP and DNS server,
  • configuration of same,
  • and manual calls to iptables  (masquerading, forwarding, etc.) to route between eth0 and wlan0 devices

The author of this blog wrote a second post to avoid the locally run DHCP server in favor of re-using the DHCP server of the network (e.g. the modem) by using dnsmasq , which is yet another locally run server, only a bit simpler, but has to be configured also. I tried it to no avail. Same problem: phone would disconnect immediately. Frustrated, I moved on.

Then I found ths blog which brought a new idea: the concept of bridging between network interfaces instead of using iptables, which, and this is the good news, is supported ‘natively’ by hostapd and the Linux networking system configured by /etc/network/interfaces . However, this solution still did not work for me. After modifying /etc/network/interfaces accordingly, I managed to mess my internet connection up. It turned out that setting up a bridge between Ethernet and Wireless is not that trivial! Even the highly official Debian Wiki BridgeNetworkConnections would not give working results for my case. So, I started crossreferencing between other solutions and finally came up with the following sequence of commands that work for me on my pretty standard Debian Wheezy laptop with one ethernet adapter (eth0) and the above mentioned Intel network adapter (wlan1). You only need to install 2 packages (bridge-utils and hostapd). With my method, there is no need for a locally installed DHCP or DNS server, and no need to modify the /etc/network/interfaces  file. There is no requirement to permanently make changes to your network configuration. In an emergency (if you are stuck somehow), a reboot will reset your network configuration to the defaults. Devices connected to your newly created wireless network will be served by the DHCP and DNS server specified in your router/modem. Your mobile phone will be a regular and equal member of your LAN.

You can turn the following listed commands easily into a Bash script with ‘start’ and ‘stop’ arguments. But I’ll leave that up to you. It’s easy enough once you copy/past the following commands into a terminal window. So, without further ado, as superuser…

… install bridge-utils. These are helper programs.

apt-get install bridge-utils

Next, remove the attached IP address from the Ethernet card eth0. Bridging will not work when an IP address is set.

ip addr flush dev eth0

Next, turn on IPv4 networking for your wireless card. This is necessary, otherwhise one of the next steps will give the error “can’t add wlan1 to bridge br0: Operation not supported”.

iw dev wlan1 set 4addr on

Next, create the actual bridge br0 with the helper program brctl:

brctl addbr br0

Next, bridge between Ethernet and wireless. The order of the last two arguments is not important:

brctl addif br0 eth0 wlan1

Next, bring the newly created bridge up, as a virtual device:

ip link set dev br0 up

At this point, you will have lost your connection to your LAN/WAN. You have to set an IP address, net mask, router, etc. for the bridge. We do this via DHCP:

dhclient br0

Now you should be able to access the internet again. Test it! If it doesn’t work, just reboot your computer. We have not made permanent changes to your system (another advantage of this method!)

So far so good. Now we have to create our actual wireless network in AP mode and use our Android phone to test it. Install hostapd:

apt-get install hostapd

Create a configuration file somewhere on your drive. I chose the location /etc/hostapd/my-wlan.conf . Make sure you have the right driver set for your card (see above mentioned blog for more info. n180211 should work in most cases):

interface=wlan1
driver=nl80211
wmm_enabled=0
ssid=networkname
channel=6
bridge=br0

#sets the mode of wifi, depends upon the devices you will be using. It can be a,b,g,n. Setting to g ensures backward compatiblity.
hw_mode=g

#macaddr_acl sets options for mac address filtering. 0 means "accept unless in deny list"
macaddr_acl=0

#setting ignore_broadcast_ssid to 1 will disable the broadcasting of ssid
ignore_broadcast_ssid=0

#Sets authentication algorithm
#1 - only open system authentication
#2 - both open system authentication and shared key authentication
auth_algs=1

######Sets WPA and WPA2 authentication#####
#wpa option sets which wpa implementation to use
#1 - wpa only
#2 - wpa2 only
#3 - both
wpa=3

#sets wpa passphrase required by the clients to authenticate themselves on the network
wpa_passphrase=12345678

#sets wpa key management
wpa_key_mgmt=WPA-PSK

#sets encryption used by WPA
wpa_pairwise=TKIP

#sets encryption used by WPA2
rsn_pairwise=CCMP

(comments are thanks to above mentioned blog)

Now, simply start hostapd with this configuration file as the only argument:

hostapd /etc/hostapd/my-wlan.conf

You will see debug messages helping you to see what is going on behind the scenes. Now use your Android phone, enable WIFI, wait for the network “networkname” to appear, connect to it, enter the password “12345678”, open up a browser and see if it works. Make sure that Wireless is turned on in your Network Manager:

gnome network manager wlan

Otherwise you will get the following messages:

rfkill: WLAN soft blocked
Could not set interface mon.wlan1 flags: Operation not possible due to RF-kill
nl80211: Failed to set interface wlan1 into AP mode

To turn off wireless (you really don’t want to be grilled by microwaves 24 hours a day!), you cannot just turn Wireless off in your Network Manager since it seems to ‘damage’ the bridge (I have yet to confirm this a second time), and you won’t be able to access your network/internet. You have to ‘deconstruct’ the bridge in the following way:

ifconfig br0 down
brctl delbr br0
ifconfig eth0 down
ifconfig eth0 up

Only after that, you can turn of Wireless in your Network Manager. Again, if you are stuck, just reboot.

I hope this helps somebody, it worked for me, if not, write me a comment.