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 http://ftp.de.debian.org/debian/pool/main/libp/libpng/libpng12-0_1.2.50-2+deb8u2_i386.deb
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

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:

/etc/nginx/conf.d/example-com.onion.conf

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

        location / {
                proxy_set_header original-host $http_host;
                proxy_pass https://www.example.com:443;
        }
}

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.

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 "/CN=www.example.com" -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:~$ acme_tiny.py --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)
                pub: 
                    04:43:90:a2:b2:79:55:df:ba:e8:fc:a9:ef:04:d0:
                    12:d6:f7:6b:56:78:58:b1:db:3a:05:c3:bc:62:4d:
                    14:c6:c2:c7:ce:1c:11:7a:1c:a7:15:bf:00:96:69:
                    0c:3c:17:e8:3b:84:48:f5:85:d1:d3:12:b5:01:af:
                    d9:89:29:80:f4:45:27:d8:98:b4:20:15:d4:e0:bb:
                    89:6e:d6:08:44:71:37:44:1c:8f:a5:7d:90:f6:b8:
                    7e:68:e5:b5:41:29:24
                ASN1 OID: secp384r1
...

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

/etc/nginx/conf.d/www000.conf

server {
        listen 0.0.0.0:443;
        listen [::]:443;
        server_name  www.example.com;

        ...

        # 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 www.example.com:443 -status -tlsextdebug -tls1_2 -cipher ECDHE-ECDSA-AES128-SHA256 </dev/null
...
---
Certificate chain
 0 s:/CN=www.example.com
   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 www.example.com:443 -status -tlsextdebug -tls1_2 -cipher ECDHE-RSA-AES128-SHA256 </dev/null
...
---
Certificate chain
 0 s:/CN=www.example.com
   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 testssl.sh. 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“.

Links

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).'@example.com';

This will print a different e-mail address like 35de1bff@example.com 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 https://github.com/68b32/postfix-trashmail.git

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

postfix-trashmail

SECRET="<Your secret>"
LENGTH=8
DOMAIN="example.com"
MAILDROP="permanent-address@example.com"

INTERFACE="127.0.0.1"
PORT="10000"

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 35de1bff@example.com.

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
35de1bff@example.com
97615254@example.com

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 35de1bff@example.com tcp:127.0.0.1:10000
permanent-address@example.com

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/main.cf to add the lookup table to the virtual_alias_maps.

/etc/postfix/main.cf

virtual_alias_maps = ... tcp:127.0.0.1:10000

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

root@mailhost:~# postfix reload && postfix-trashmail
35de1bff@example.com
97615254@example.com