Install TeamViewer 11 on Debian Stretch amd64

On Thu, 27 Oct 2016 19:19:31 +0200 by Falco Nordmann - Write a comment

To install the TeamViewer Debian package on a 64 bit Debian Stretch system and encounter the problems of a missing libpng12-0 and the error architecture (i386) does not match system (amd64) run the following commands in order:

root@host:~# wget
root@host:~# dpkg -i libpng12-0_1.2.50-2+deb8u2_i386.deb
root@host:~# dpkg --add-architecture i386
root@host:~# apt-get update
root@host:~# dpkg -i teamviewer_11.0.67687_i386.deb # The errors and warnings can be ignored for now
root@host:~# apt-get install -f

If the last command was executed without any errors you should be able to launch TeamViewer by running

user@host:~$ teamviewer

Set up an onion address for your website

On Tue, 25 Oct 2016 15:58:58 +0200 by Falco Nordmann - Write a comment

I finally managed to connect this page properly to the Tor network by setting up a Tor hidden service that redirects to this site. To use it download the Tor browser bundle and connect to the onion address http://seodnwkezyf3msbj.onion.

If you want to know about my motivation to set this up, please read this article on the Tor blog and watch this video recorded at the 32c3 explaining why hidden service are useful.

For now there is only a http version available for my onion address since the only CA issuing TLS certificates for onion addresses is DigiCert who wants to be paid for it. There is some hope that Let's Encrypt will issue certificates for onion addresses in the future. Anyway it is not a real security risk if you care for transport encryption between Tor terminating the connection to the onion address and your endpoint (e.g. web server) since connections to onion sites are encrypted and authenticated by the onion address itself. Securing the connection to the endpoint can be achieved by either running Tor on the same machine as the endpoint, or by creating a SSH/VPN tunnel or in case of a web server using a proxy connecting both using https. For a quick introduction on how to setup a Tor hidden service have a look at the article in the Tor documentation.

To forward HTTP requests sent to the onion site to your web server using https you can use the following simple NGINX configuration:

server {
        listen [::]:80;
        server_name youronionaddress.onion;

        location / {
                proxy_set_header original-host $http_host;

This will also add an additional header original-host to the forwarded request so that you have an easy way to distinguish between requests that came by using the onion address and requests that came by using the classic domain.

ECDSA and RSA certificate in parallel with NGINX and Let's Encrypt

On Fri, 03 Jun 2016 18:19:19 +0200 by Falco Nordmann - Write a comment

With version 1.11.0 of NGINX it is now possible to serve content via https using RSA and ECDSA certificates in parallel.

ECDSA is another approach to cryptographically sign messages and comes with some advantages compared to RSA. According to a comparison made by the BSI an ECDSA key with a key length of 256 bit provides about the same security as a RSA key of 2048 to 3072 bit (what is about 128 bit symmetric key size). The smaller key length of the ECDSA key results in less computing power needed for generating message signatures during TLS connections. This advantage becomes measurable on systems with thousands of concurrent TLS sessions.

Happily Let's Encrypt issues certificates for ECDSA keys since 10th of February so that it is possible to get a free ECDSA certificate accepted by all major browsers. Unfortunately these certificates are still signed by the Let's Encrypt Authority X3 intermediate certificate, which is a RSA certificate. The ability to get the end-entity certificates signed with an ECDSA intermediate certificate by Let's Encrypt is scheduled for this year. But since the certificate chain is validated on the client, this does not have an impact on the servers TLS performance (except the larger intermediate certificate sent to the client).

An ECDSA key and CSR can be generated similarly to its RSA equivalent using OpenSSL.

user@host:~$ openssl ecparam -name <curve> -genkey -noout -out service.ecdsa.key
user@host:~$ openssl req -new -sha256 -key service.ecdsa.key -subj "/" -out service.ecdsa.csr

The <curve> parameter specifies the elliptic curve used for the key. openssl ecparam -list_curves will print a list with all curves built into OpenSSL.

According to the Let's Encrypt forum and some tests I ran against the Let's Encrypt staging server, only certificates for keys using the curves prime256v1 and secp384r1 are issued. secp521r1 seemed to be in discussion for some time but is not enabled at the moment. This is not a very satisfying situation, since the supported curves seem to have some flaws and are not assumed to be totally secure. Hopefully more secure curves will be supported by Let's Encrypt soon.

The generated CSR can be submitted to Let's Encrypt the same way as done when using RSA keys. Here is an example using acme-tiny.

user@host:~$ --account-key letsencrypt.key --csr service.ecdsa.csr --acme-dir acme-challenge/ > service.ecdsa.crt

If the domain validation was successful, this will leave you with a signed ECDSA certificate in service.ecdsa.crt.

user@host:~$ openssl x509 -noout -in service.ecdsa.crt -text
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                ASN1 OID: secp384r1

To add multiple certificates to your NGINX configuration, the ssl_certificate and ssl_certificate_key directives can be specified multiple times.

server {
        listen [::]:443;


        # RSA
        ssl_certificate /etc/nginx/tls/service.rsa.crt;
        ssl_certificate_key /etc/nginx/tls/service.rsa.key;

        # ECDSA
        ssl_certificate /etc/nginx/tls/service.ecdsa.crt;
        ssl_certificate_key /etc/nginx/tls/service.ecdsa.key;


Make sure that the Let’s Encrypt Authority X3 intermediate certificate is appended in one of the files referenced by the ssl_certificate directive. If the intermediate certificate is present in both files, this will cause NGINX to send it twice what might result in errors on the client site.

Restart NGINX and check if your can connect with ECDSA ciphers enabled.

user@worksation:~$ openssl s_client -connect -status -tlsextdebug -tls1_2 -cipher ECDHE-ECDSA-AES128-SHA256 </dev/null
Certificate chain
 0 s:/
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Server public key is 384 bit
    Cipher    : ECDHE-ECDSA-AES128-SHA256

Try the same with a RSA cipher

user@worksation:~$ openssl s_client -connect -status -tlsextdebug -tls1_2 -cipher ECDHE-RSA-AES128-SHA256 </dev/null
Certificate chain
 0 s:/
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Server public key is 4096 bit
    Cipher    : ECDHE-RSA-AES128-SHA256

Which of the both certificates is actually used depends on the order of the ciphers listed within the ssl_ciphers directive and the capabilities of the connecting client. For example the cipher recommendations given in the Mozilla wiki prefer ECDSA ciphers over their RSA counterparts.

After configuration, go ahead and test your whole TLS configuration with public tools like Qualys SSL test or How to improve your TLS configuration for NGINX is also documented in my article „Secure webspaces with NGINX, PHP-FPM chroots and Let's Encrypt“.

Temporary trashmail addresses with postfix

On Mon, 09 May 2016 21:32:36 +0200 by Falco Nordmann - Write a comment

Warning: The information given in this article is outdated. See the project's website for up-to-date information.

If you are in need of temporary mail addresses (trashmail addresses) in postfix to avoid spam in your inbox you might be interested in the solution I found for this problem.

The idea is to generate an e-mail address from a date and a secret. Everyone who knows the secret (you and your mail server) will be able to generate the e-mail address for a given date. This e-mail address can then be used to sign up for a service or generated dynamically and published on your website and will only be valid for the current day.

Here is an example PHP code

$secret = "<Your secret>";
echo substr(md5(date("Ymd").$secret),0,8).'';

This will print a different e-mail address like for every day.

One problem with this technique is that if someone starts writing an e-mail at 23:59, he likely won't be finished before the address he uses expires. To solve this, two temporary addresses will always be valid: The one generated from the current date, and the one generated from yesterday's date.

To make this work with postfix, we need a way to map the temporary addresses to a permanent address. Looking at the Postfix Lookup Table Overview I decided to write a small script utilizing socat (since the traditional netcat package has its flaws and the OpenBSD version of netcat did not perform very well) to implement a simple TCP/IP lookup table for postfix. This is probably not a solution for high frequented mail servers, but sufficient for personal use.

It's just about 40 lines of code to do the job, and can be found on GitHub. On Debian 8 you will need the socat package.

root@mailhost:~# apt-get install socat git
root@mailhost:~# git clone

You have to open the actual script postfix-trashmail to configure some parameters

SECRET="<Your secret>"


SECRET sets the secret as described above and will be used to generate the temporary e-mail addresses consisting out of LENGTH hexadecimal characters followed by @ and DOMAIN. So the above configuration will generate e-mail addresses like

MAILDROP sets the address that is mapped to the temporary addresses. This is where mail sent to temporary addresses should be delivered to.

INTERFACE and PORT set the IP address and the port for the TCP lookup table. If this script is run on the same machine as the postfix daemon, a local interface should be used.

To test the configuration, run the script without arguments first. This will print the currently valid temporary addresses.

root@mailhost:~/postfix-trashmail# ./postfix-trashmail

Now start the script in listen mode with -l.

root@mailhost:~/postfix-trashmail# ./postfix-trashmail -l

and from another terminal use the postmap command to query for the real address.

root@mailhost:~# postmap -q tcp:

If you query for a currently valid temporary address, the permanent address as specified in MAILDROP should be returned. Querying for any other address should return an empty result.

To install the script and start it automatically on boot before postfix, copy the script to some commonly used path and install the systemd configuration. On Debian 8 you can do this with

root@mailhost:~# cp postfix-trashmail/postfix-trashmail /usr/local/bin
root@mailhost:~# chown postfix:postfix /usr/local/bin/postfix-trashmail
root@mailhost:~# chmod 700 /usr/local/bin/postfix-trashmail
root@mailhost:~# cp postfix-trashmail/postfix-trashmail.service /etc/systemd/system
root@mailhost:~# systemctl daemon-reload
root@mailhost:~# systemctl start postfix-trashmail
root@mailhost:~# systemctl enable postfix-trashmail
Created symlink from /etc/systemd/system/postfix.service.wants/postfix-trashmail.service to /etc/systemd/system/postfix-trashmail.service.

Then edit your /etc/postfix/ to add the lookup table to the virtual_alias_maps.

virtual_alias_maps = ... tcp:

Reload postfix and test if you receive mails to the addresses printed by the postfix-trashmail command.

root@mailhost:~# postfix reload && postfix-trashmail