БэФ블로그

Apache's mod_vhost_alias provides a neat little feature for easing up virtual host configurations:

This module creates dynamically configured virtual hosts, by allowing the IP address and/or the Host: header of the HTTP request to be used as part of the pathname to determine what files to serve.

Now suppose the following not so uncommon scenario: Two IP addresses share the same host - let's say 10.0.0.10 and 10.0.0.11. One IP is meant for production services, the other IP may be totally unrelated. However, both IPs are configured for named virtual hosts with overlapping wildcards and share the same VirtualDocumentRoot:

span style="color: #7f007f;">"/protected/"

Our second virtualhost beta.foo.bar blocks access to /protected/ - the first virtualhost has no such protection. Let's check out beta's protection manually:

span style="color: #ff0000;">"-//IETF//DTD HTML 2.0//EN"

Now, just for fun, the very same request goes to the other IP:

# telnet 10.0.0.10 80
"e8127-1c-4697bd6c57000"

Please, keep that in mind when rolling out VirtualDocumentRoots on more than one IP with overlapping wildcard hostnames.

Ein kurzer Abriss der Geschichte: Bis Ende der 90er wurde starke Kryptographie unter anderem von den USA als militärische Komponente gesehen (siehe WP/Export of crypto und USML). Gleichzeitig erfand Netscape den Verschlüsselungsstandard SSL, der als Basis für TLS diente. In der Kombination wurde die erste öffentliche Version von SSL (SSLv2) absichtlich unsicher gestaltet, um nicht durch US-Exportbestimmungen eingeschränkt zu werden. In aktuellen Browsern wird SSLv3 und TLSv1 verwendet. Der erste Netscape Browser mit SSL wurde mit 128-Bit symmetrischer Verschlüsselung als US-only Variante gebaut und mit 40-Bit zum Export für den Rest der Welt. Die so abgeschwächte "Verschlüsselung" kann heute in Minuten gebrochen werden.

In einer Phase des TLS-Protokolls handeln Server und Client aus, welche Verschlüsselungsmethode (Cipher) verwendet werden soll. Das OpenSSL-Tool zeigt leicht eine Liste der möglichen Cipher für auf OpenSSL basierende Anwendungen an:

$ openssl ciphers -v ALL:eNULL
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
...

Nicht verwenden möchte man eben SSLv2, unsichere 40-Bit Export-Cipher, niedrige 56-Bit oder garkeine Verschlüsselung (eNULL) oder keine Authentifizierung (aNULL). Übrig bleibt noch folgendes:

$ openssl ciphers -v 'ALL:!SSLv2:!LOW:!EXPORT:!eNULL:!aNULL'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
...

Einen Apache Webserver passend zu konfigurieren, macht nur eine Zeile aus:

SSLCipherSuite ALL:!SSLv2:!LOW:!EXPORT:!eNULL:!aNULL

oder noch besser

SSLCipherSuite HIGH:!SSLv2:!EXP:!aNULL:!eNULL

Randnotiz: Firefox zeigt mit CipherFox den aktuell verwendeten Cipher an.

Heute, etwa zehn Jahre nach dem Wegfall absurder US-Exportbeschränkungen antworten Webserver immer noch auf Anfragen mit SSLv2 oder mit LOW/EXPORT Ciphern. Das OpenSSL-Tool testet das gerne:

$ openssl s_client -no_tls1 -no_ssl3 -cipher EXP -connect www.my-bank.foo:443
...
New, SSLv2, Cipher is EXP-RC2-CBC-MD5
...

Leute, Leute, Leute, - und damit soll sich mein Internetbankingprovider angesprochen fühlen - schaltet bitte den alten und unsicheren Krempel ab.