HTTPS

Weiterleitung von HTTP auf HTTPS

caticonslite_bm_alt

Im Chromium Blog wurde angekündigt, dass mit Veröffentlichung von Chrome 68 im Juli 2018 alle via HTTP abgerufenen Seiten als „Nicht sicher“ in der Adressleiste gekennzeichnet werden. Dank Diensten wie Let’s Encrypt oder Cloudflare ist die Aktivierung eines SSL- bzw. TLS-Zertifikats heutzutage einfach und kostenlos möglich. Um die Weiterleitung von HTTP auf HTTPS für die Webseite zu aktivieren ist folgende Apache-Konfiguration (z.B in der .htaccess-Datei) erforderlich:

RewriteEngine On
RewriteCond %{HTTP_HOST} =blog.webentwickler.at
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Jede RewriteCond muss für die nachfolgende RewriteRule zutreffen, damit diese angewandt wird. In diesem Fall muss der Hostname „blog.webentwickler.at“ lauten und die Environment-Variable „HTTPS“ darf nicht „on“ sein und „HTTP:X-Forwarded-Proto“ darf nicht „https“ sein, damit die Weiterleitung auf die HTTPS-Adresse erfolgt. Die Überprüfung von „HTTPS“ ist für direkt auf Apache aufgeschaltete Domains erforderlich, „HTTP:X-Forwarded-Proto“ kommt im Falle eines Reverse-Proxy (z.B. NGINX oder Varnish) oder Cloudflare zum Tragen.

NGINX als SSL-Wrapper

caticonslite_bm_alt

NGINX ist bekannt für seine gute Performance und ideal, um als Reverse Proxy bzw. Load Balancer vor speicherintensiven Anwendungsservern (z.B. Apache mit PHP) eingesetzt zu werden und in diesem Zuge auch die HTTPS-Verbindung zu terminieren, damit sich die Anwendungsserver nicht mehr darum kümmern müssen. Um NGINX als SSL-Wrapper einzusetzen ist folgende Konfiguration erforderlich:

server {
        listen 80;
        server_name domain.tld;
 
        return 301 https://domain.tld$request_uri;
}
 
server {
        listen 443;
        server_name domain.tld;
 
        ssl on;
        ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
        ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
        ssl_session_timeout 5m;
        ssl_protocols SSLv3 TLSv1;
        ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
        ssl_prefer_server_ciphers on;
 
        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_pass http://10.0.0.1/;
        }
}

Die erste server-Anweisung dient dazu alle HTTP-Anfragen auf HTTPS umzuleiten – „domain.tld“ ist selbstverständlich mit der eigenen Domain zu ersetzen. Sollte neben HTTPS auch HTTP möglich sein, ist diese Konfiguration nicht erforderlich und kann weggelassen werden.

Die zweite server-Anweisung behandelt alle HTTPS-Anfragen und leitet diese im sicheren internen Netz auf den Anwendungsserver „10.0.0.1“ via HTTP-Protokoll weiter. Die Zertifikats- und Schlüsseldatei ist, genauso wie die Adresse des Anwendungsservers, an die eigene Infrastruktur anzupassen. Das Ursprungsprotokoll und die Ursprungsadresse werden als X-Forwarded-Proto bzw. X-Forwarded-For HTTP-Header an den Anwendungsserver weitergeleitet und können somit in der Anwendung entsprechend behandelt werden, z.B. um absolute Links für das verwendete Protokoll zu generieren.

In diesem Fall wurde der Einfachheit halber das automatisch erstellte Snakeoil-Zertifikat von Debian verwendet. Die Installation erfolgt mit „apt-get install ssl-cert“, die Verwendung kann im ubuntuusers.de-Wiki nachgelesen werden.

 nach oben