Tor Project Logo (via https://media.torproject.org/)

Mac OS X: Tor Netzwerk nutzen

Seit einigen Monaten bin ich fast ausschließlich mit Macs unterwegs und muss mir für bestimmte Sachen immer wieder mal meine Umgebung anpassen. So auch für meine Tor-Nutzung. Was TOR ist sollte inzwischen jedem bekannt sein. Aber kurz gesagt: „Tor ist ein Netzwerk zur Anonymisierung von Verbindungsdaten.“ Schön erklärt es auch das Video vom Tor Project:

Früher habe ich vom Tor Project die Browser Bundles und Vidalia benutzt. Oder habe mir einen Proxy (Polio und Privoxy) gebaut, der das Tor Netzwerk nutzt. Inzwischen ist das nicht mehr nötig, denn man kann den Tor-Client direkt dafür benutzen.

Continue reading…

NGINX

Nginx: OCSP stapling aktivieren

Wer mit SSL Zertifikaten arbeitet weiß auch das diese irgendwann ablaufen oder für ungültig erklärt werden können. Damit dies auch jeder Browser und jedes Betriebsystem mitbekommt, wurde die CRL (certificate revocation list; Zertifikatsperrliste) erfunden. Leider werden diese Sperrlisten von den Betriebssystem nur in bestimmten Zeitabständen abgerufen. Wird ein Zertifikat heute für ungültig erklärt und die Betriebssysteme haben es noch nicht mitbekommen, weil sie die CRL von der CA erst morgen aktualisieren werden, bleibt das Zertifikat bis dahin gültig.
Aus diesem Grund wurde OCSP (Online Certificate Status Protocol) entwickelt. Durch das Netzwerkprotokoll ist es Clients möglich durch eine Anfrage beim OCSP-Responder (meist ein Server vom Root CA Betreiber; URL steht im Zertifikat) nachzufragen ob das Zertifikat noch gültig ist oder nicht. So bekommt der Client die aktuellen Sperrinformationen geliefert.
OCSP stapling lässt dich bei Nginx mit folgenden Zeilen in der „nginx.conf“ aktivieren:

# aktiviert OCSP stapling
ssl_stapling on;
# aktiviert die Überprüfung
ssl_stapling_verify on;
# Trusted Certificate
ssl_trusted_certificate /etc/nginx/ssl/alphassl.pem;

Sollte man mehrere Zertifikate auf dem Webserver zu Verfügung stellen, dann sollte man die Einstellungen in die entsprechende „http“-Konfiguration schreiben.
Die Datei für „ssl_trusted_certificate“ muss man manuell im PEM-Format erstellen. Dabei besteht die Datei aus den Zertifikaten des jeweiligen Anbieters, welche man auf deren Website bekommt. In einigen Fällen werden diese Zertifikate auch bei der Beauftragung des SSL-Zertifikats mitgeschickt. Wichtig: Damit die Überprüfung auch wirklich funktioniert müssen in die „ssl_trusted_certificate“ Datei das Root-Zertifikat und alle Intermediate-Zertifikate rein!

Continue reading…

NGINX

Nginx: SSL Cipher Suites vorschreiben

Bei einer SSL-Verbindung wird nicht nur ausgehandelt welches SSL-Protokoll benutzt werden soll, sondern auch welche Verschlüsselung es sein soll. Normalerweise gibt der Browser hier den Ton an und schlägt dem Webserver vor welche Cipher Suites er nutzen möchte. Die Browser fangen meisten immer mit schwachen Verschlüsselungen (z.B. RC4) an, obwohl sie auch viel sichere Verfahren könnten. RC4 sollte in Zeiten von NSA und Co. zum Beispiel gar nicht mehr zum Einsatz kommen, denn es gilt als geknackt. Erst wenn Browser und Webserver sich für eine Cipher Suite entschieden haben, kommt auch eine Verbindung zustande. Jede Cipher Suite ist eine Kombination aus vier standardisierten Algorithmen.
Leider unterstützen nicht alle Browser und Bots alle Verschlüsselungsverfahren, daher ist ist hier etwas Feinarbeit nötig und man muss einen Kompromiss eingehen.

Als erstes sollte Nginx die Cipher Suite dem Browser vorschreiben welches Verfahren man nutzen möchte und nicht umgekehrt. Standardmäßig ist diese Option aus. Mit der folgenden Zeile für die Nginx Konfiguration schalten wir diese erstmal an:

http {
ssl_prefer_server_ciphers on;
}

Jetzt würde die Cipher Suite so aussehen: ssl_ciphers HIGH:!aNULL:!MD5;

Continue reading…

NGINX

Nginx: SSL Zertifikat anfordern und einrichten

Inzwischen ist es sicherlich bei jedem angekommen, dass Google in nächster Zukunft Websites mit HTTPS (SSL/TLS) besser im Ranking bewertet als HTTP. Ich kann diesen Schritt nur begrüßen, doch leider finde ich diesen Schritt auch etwas zu spät. Das hätte man auch schon vor den ganzen NSA-Enthüllungen forcieren können. Aber besser spät als nie. Es ist immer noch unglaublich wie viele Daten unverschlüsselt im Internet übertragen werden. Sei es die Anmeldung bei einigen WordPress-Backends oder Verbidnung von eine App zu einem Server. Da gibt es noch eine Menge Nachholbedarf.
Vielen haben eine Website möchte diese nun per HTTPS absichern (und ein besseres Ranking bei Google bekommen), aber wissen nicht wie man das macht.
Continue reading…

NGINX

Nginx: TLS statt SSL nutzen

TLS ist der Nachfolger von SSL und wird inzwischen von den meisten Browsern bevorzugt. Es wird auch weiterhin SSL-Verbindung heißen, obwohl man TLS nutzt. TLS ist sicherer als SSL und sollte dadurch auch bevorzugt genutzt werden.
Daher sollte man auf SSLv1, SSLv2 und SSLv3 ganz verzichten und nur noch TLSv1, TLSv1.1 oder TLSv1.2 erlauben/nutzen. Ich glaube der IE6 ist der einzige Browser der kein TLS kann. Aber wer benutzte den noch.

Der Standardwert der SSL-Protokolle bei Nginx sieht so aus:
http {
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
}

Wenn man nur noch TLS einsetzen möchte, dann lautet die Zeile:
http {
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}

Wichtig hierbei ist allerdings, dass dies nur funktioniert wenn OpenSSL 1.0.1 oder höher bei Euch auf dem Server läuft.

Wichtige Mailadressen einrichten

In Zeiten wo fast monatlich Nachrichtenmeldungen aufkommen, dass Server kompromittiert oder Email-Adressen entwendet wurden, kann es hilfreich sein bestimmte Emailadresse einzurichten.
In der RFC 2142 gibt es eine Empfehlung welche Emailadressen es geben sollte. Das geht natürlich nur wenn man seinen eigenen Mailserver bzw. eine eigene Domain hat. Bei den ganzen Email-Anbietern am Markt kann man das nicht machen, schließlich benutzen diese solche Adressen schon für sich selber.
Sollte jemand technische Probleme mit eurer Website oder mit Spammails die von Eurem Server kommen haben, dann werden sich die Betreiber oder Behörden meistens an diese Adressen wenden. In der RFC stehen ein paar mehr, aber die wichtigsten habe ich mal zusammengefasst:

Für den Netzwerkbetrieb:

  • abuse@domain.de – Missbrauchsmeldungen wie Spamversand oder DOS-Attacken
  • noc@daomain.de – Kontakt zum Betreiber der Netzwerkinfrastruktur
  • security@domain.de – für Sicherheitsmeldungen oder -anfragen
  • Für angebotenen Serverdienste:

  • postmaster@domain.de – für Probleme mit dem Mailempfang bzw. -versand
  • hostmaster@domain.de – bei Nameserver-Problemen
  • webmaster@domain.de – um den Betreiber einer Website zu kontaktieren
  • ftp@domain.de – für Probleme mit dem FTP-Server
  • Für den Geschäftsverkehr:

  • info@domain.de – allgemeine Anlaufstelle
  • support@domain.de – Kundendienst
  • Ein paar von den Adressen werden auch für Spam missbraucht, daher solltet ihr einen entsprechenden Spamfilter nutzen.