Kategorie: IT-Security (Seite 9 von 15)

Oh ich habe in der letzten Zeit viele Fragen bekommen, ob es mir gut geht. Ja, danke es geht mir gut! Ich hatte nur einfach keine Zeit mehr für einen neuen Beitrag, tut mir Leid. Zwar habe ich ein paar begonnen, werde aber einfach nicht mit ihnen fertig 🙁 Nun aber erstmal ein neuer Post und direkt etwas zum basteln.

Viele von euch habe ja nach meinem Post zu den verschärften SSL/TLS Einstellungen meiner Webseite ähnliches auf ihren Webseiten getestet. Bei mir ist fast nur positives Feedback angekommen! Irgendwie scheinen wir nicht die User eines Windows XP IE6 als Zielgruppe zu haben! Gut gut… Qualys bescheinigt uns also nun ein A+ inkl. der viermaligen Wertung 100. Etwas bekloppt sind wir schon, hm?

ABER habt ihr mal auf eure Header geachtet? Header?!? Jopp… Da da könnte man Policys veröffentlichen die vor Cross-Site-Scripting schützen, Clickjacking, Zeugs das den IE davon abhalten sollte MIME-Types zu sniffen usw. usw…

Nun fühlt euch nicht schlecht, die wenigsten denken darüber nach! Dieses zeigt sich auch schnell über folgende Statistik: https://securityheaders.com/stats.php

Oh ja, oben rechts auf der Seite könntet ihr nun eure Domain eintippen und mal schauen was heraus kommt 😀 Gemacht? Gut, sollten wir was ändern?!?! Na dann mal los…

Für einen guten Start wäre folgendes zu tun:

Sofern noch nicht bereits lange an bitte das Apache Modul headers aktivieren:

$ a2enmod headers

Euer Apache wird für neue Module einen Restart benötigen:

$ service apache2 restart

Für spätere Konfigurationsänderungen reicht dann ein einfacher Reload aus:

$ service apache2 reload

Aktuelle Apache Versionen kommen auf einem Debian in der Regeln mit folgender Konfigurationsdatei: /etc/apache2/conf–enabled/security.conf

Möchte man für alle seine V-Host auf dem Server diese Dinge setzten fügt man es hier einfach unten an. Möchte man es nur für einen bestimmten v-host setzten, dann halt direkt in dessen Konfigurationsdatei. Logisch, hm?

Folgender Schwung räumt schon mal etwas auf:

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Header set X-Content-Type-Options: "nosniff"
Header set X-Frame-Options: "sameorigin"
Header set X-Permitted-Cross-Domain-Policies: "master-only"
Header set X-XSS-Protection: "1; mode=block"
Header set X-Frame-Options: "sameorigin"
Header set X-XSS-Protection: "1; mode=block"
Header unset X-Powered-By

Beim Header set X–Frame–Options: „sameorigin“  bitte bedenken, dass er Einbindungen in andere Seiten per iframe grillen würde. Ist dieses bei eurer Webseite so, solltet ihr den Header besser so nicht setzten!

ServerSignatur Off sorgt dafür, dass an keiner Stelle mehr eure Serverversion auftaucht. Ganz gut wenn ihr es möglichen Angreifen/Bots erschweren wollt Sicherheitslöcher für eure Version zu finden.

ServerTokens Prod sagt dem Apachen, dass er im Server Header nur das Wort Apache senden soll. Noch weniger wäre noch schöner, ist aber ohne weitere Arbeit nicht drin. Dazu später mehr!

TraceEnable Off wirft, wie zu erwarten die HTTP TRACE Method raus (braucht man es für manche seiten, könnte man es auch über die .htaccess wieder aktivieren:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

Einfach mal testen….

Bis auf Header unset X–Powered–By hängen die anderen fast alle am Internet Explorer und kümmern sich darum hier für etwas mehr „Ruhe“ zu sorgen. Ach ja, Powered By fliegt durch ein unset natürlich raus. Man liest auch öfter mal von einem Header unset Server. Im Standard ist es aber nicht möglich den Apachen davon zu überzeugen sich selbst zu verleugnen. Es gibt auch bereits einen Bug-Report und ein WONTFIX.

https://bz.apache.org/bugzilla/show_bug.cgi?id=40026

Also selbst kompilieren oder damit leben. Die eine oder andere Distribution hat den mitgebrachten Apachen aber soweit gepatcht, dass ein unset für den Header Server funktioniert. Also einfach mal testen…

So… Noch mal scannen bitte. Und besser? Fein, wieder was gelernt und das Internet etwas verbessert!

Bei Fragen, fragen 😀

Natürlich ist bei mir OCSP Stapling am Apache 2.4 aktiviert…. Doch plötzlich zeigt mir meine Webseite beim Besuch mit dem Mozilla Firefox folgende Fehlermeldung:

Secure Connection Failed

An error occurred during a connection to www.kernel-error.de. The OCSP server suggests trying again later. (Error code: sec_error_ocsp_try_server_later)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

Im Error Log des Webservers finden sich zur gleichen Zeit Logmeldungen wie:

[Mon Aug 10 07:06:28.572899 2015] [ssl:error] [pid 23648] (70007)The timeout specified has expired: [client 1.2.3.4:23726] AH01977: failed reading line from OCSP server
[Mon Aug 10 07:06:28.572924 2015] [ssl:error] [pid 23648] [client 1.2.3.4:23726] AH01980: bad response from OCSP server: (none)
[Mon Aug 10 07:06:28.572950 2015] [ssl:error] [pid 23648] AH01941: stapling_renew_response: responder error

Ahja… bad response from OCSP Server…. Habe ich nun irgendwo Mist konfiguriert oder hat wirklich der OCSP Server meiner CA StartSSL / StartCOM ein Problem? Mein Verdacht ist natürlich, dass es an der CA liegen muss. ;-P

Am schnellsten Teste ich es einmal von Hand auf meinem Client. Ist hier das gleiche Problem, liegt es sicher an der CA. Wie also manuell per openssl testen ob der OCSP Server tut was er will? Ganz einfach, so:

Als erstes einmal den öffentlichen Teil meines Zertifikates herunterladen und in einer Datei speichern:

# openssl s_client -connect www.kernel-error.de:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > www.kernel-error.de.pem

Jetzt das Intermediate besorgen. Dieses sollte ja ebenfalls mein Server senden, also hole ich es von dort. Dabei ist hier nun etwas copy & paste Arbeit nötig. Folgendes wirft mir einiges um die Ohren:

# openssl s_client -connect www.kernel-error.de:443 -showcerts 2>&1 < /dev/null

Hier ist kopiere ich mir nun das Intermediate Zertifikat heraus in das File interm.pem. Spannend ist dabei das Zertifikat zu:

 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
MIIGNDCCBBygAwIBAgIBGzANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEW

Dabei alles ab —–BEGIN CERTIFICATE—– bis einschließlich —–END CERTIFICATE—–

In meinem Zertifikat sollte der OCSP Server meiner CA hinterlegt sein. Diesen lasse ich mir nun mit folgendem Befehl ausgeben:

# openssl x509 -noout -ocsp_uri -in www.kernel-error.de.pem
http://ocsp.startssl.com/sub/class2/server/ca

Perfekt… Nun habe ich alle Informationen zusammen um einen manuellen Test gegen den OCSP Server meiner CA zu fahren:

# openssl ocsp -issuer interm.pem -cert www.kernel-error.de.pem -text -url http://ocsp.startssl.com/sub/class2/server/ca
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: B9B2D56DB021B36E42F627245806C4A9A6979AEB
          Issuer Key Hash: 11DB2345FD54CC6A716F848A03D7BEF7012F2686
          Serial Number: 06D8F968657B18
    Request Extensions:
        OCSP Nonce: 
            04109228F685EAF4211B1A6D6CCF67AD9CC9
Error querying OCSP responder
34379249832:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/ocsp/ocsp_ht.c:255:Code=400,Reason=Bad Request

Hm… Sehr eindeutig, oder? Es scheint also wirklich ein Problem am Server der CA zu geben. Eine kurze E-Mail an die CA später habe ich, auf die Frage ob es ein Problem mit dem OCSP Server gibt, die folgende Antwort in meinem Postfach:

Yes. It would be fixed asap.

-- 
Regards
 
Signer:  	Kirill Ivanov, VO
  	StartCom Ltd.

Na wunderbar… Damit schalte ich also OCSP Stapling mal wieder aus, bis meine CA wieder korrekt arbeitet!

SSLUseStapling Off

Bis spööööter 😀

Ich bin schon ein paar mal darum gebeten worden, doch bitte eine gesammelte Liste der verschiedenen Testtools zu erstellen.

Hiermit möchte ich dieser Bitte nachkommen 🙂

Bitte beachtet aber, dass diese Tests/Checks in den meisten Fällen grob sind und nur verlässlich mitteilen können, ob etwas klappt oder nicht. Dennoch ist es hier und da eine schnelle und einfache Hilfe für Experimente und/oder um zu prüfen ob eine Änderungen greift!

So long….

---

Tests für Mail Server

SSL/TLS/TLSA/DANE/DNSSEC/SMTP Tests:
https://de.ssl-tools.net/mailservers/kernel-error.de

SSL/TLS/SMTP/POP/IMAP Tests:
http://www.checktls.com/

DANE SMTP Validator:
https://dane.sys4.de/smtp/kernel-error.de

DMARC TEST:
https://dmarcian.com/dmarc-inspector/kernel-error.de

SPF TEST:
https://dmarcian.com/spf-survey/kernel-error.de

http://www.kitterman.com/spf/validate.html

Mailserver Blacklist check:
http://mxtoolbox.com/blacklists.aspx

https://www.senderbase.org/

http://www.barracudacentral.org/lookups

DKIM / SPF / DMARC E-Mail Testadresse:
check-auth@verifier.port25.com

check-auth2@verifier.port25.com

Microsoft Tests:

https://testconnectivity.microsoft.com

---

Tests für Web Server

SSL/TLS Test:
https://www.ssllabs.com/ssltest/analyze.html?d=kernel-error.de

https://de.ssl-tools.net/webservers/www.kernel-error.de

SPDY Test:
https://spdycheck.org/#www.kernel-error.de

---

Tests für DNS Server

DNSserver:
http://www.dnsinspect.com/kernel-error.de

DNSSEC:
http://dnssec-debugger.verisignlabs.com/www.kernel-error.de

http://dnsviz.net/d/kernel-error.de/dnssec/

---

Tests für Jabber/XMPP Server

Jabber/XMMPP-Security Test:
http://www.xmpp.net/

---

Tests für Clients

IPv6 Client-Test:
http://test-ipv6.com

Webbrowser Test:
https://www.ssllabs.com/ssltest/viewMyClient.html

OPENGPGKEY RR:
https://openpgpkey.info/?email=kernel-error%40kernel-error.com

Zwei Jahre sind schon wieder um. Das bedeutet es gibt ein neues S/MIME Zertifikat, da mein altes bald ungültig wird. Hier nun die Daten für interessierte zum Abgleich!

So long

ALT
Zertifikat-Fingerabdruck
SHA1:	7F 8B 92 19 FF 07 BF EB 8E E0 18 D4 98 B8 48 DF E3 0E 4A 85
Läuft ab: 16.05.2015
Signatur-Algorithmus:	SHA1 mit RSA 2048 Bit

 

NEU
Zertifikat-Fingerabdruck
SHA1:	F6 00 F9 B0 DB BF B9 C5 C1 58 03 B2 78 11 84 A7 F1 E8 96 6D
Läuft ab: 08.05.2017
Signatur-Algorithmus:	SHA256 mit RSA 4096 Bit

 

Es gibt bereits seit einigen Jahren die Möglichkeit, seinen GPG Key in die DNS Zone zu packen. Oder besser gesagt, man kann in der Zone einen Ort angeben, an welchem man seinen GPG-Key finden kann.

>>Hinzufügen der GPG Keys zum DNS<<

Dieses ermöglichte bisher einen einfachen Weg um anderen seinen Schlüssel zukommen zu lassen! Unabhängig von den Schlüsselservern und den dort „möglicherweise“ im Umlauf befindlichen ~fake~ Keys.

Inzwischen gibt es einen neuen Ansatz, welcher sich gerade auf dem Weg in ein RFC befindet. Dieser beschreibt, einen neuen Resource Record. Der RR beinhaltet dann direkt den kompletten Schlüssel. So lässt sich dieser noch einfacher und (DNSsec sei Dank) sicherer verteilen.

Nun habe ich meinen aktiven GPG Schlüssel als OPENGPGKEY Record in meine Bind Zone gepackt….

Testen lässt sich dieses hier:
https://openpgpkey.info/?email=kernel-error%40kernel-error.com

Zugegeben, dieser Record „sprengt“ etwas die Zonenlesbarkeit O_o

Den genauen Aufbau und die manuelle Erstellung des Records werde ich sicher bald als kleine „Update“ beschreiben.

Fragen? Dann fragen!

Die aktuelle Gültigkeitsprüfung anhand von CAs hat so ihre Lücken. So erscheint jedes Zertifikat als gültig und vertrauenswürdig, sofern es nur von einer CA unterzeichnet wurde, welcher der Client selbst vertraut.

Erschleiche ich mir also ein gültiges Zertifikat für eine Domain oder schiebe es dem Client als vertrauenswürdig unter, wird sich der Benutzer zwar sicher und geschützt fühlen, dennoch ist er es nicht.

Mögliche Beispiele finden sich hier:
– Google deckt erneut Missbrauch im SSL-Zertifizierungssystem auf
– Comodo stellt fälschlicherweise Microsoft-Zertifikat aus

Nun gibt es mehrere Ansätze um diese Situation zu verbessern. TLSA / DANE zusammen mit DNSsec, HSTS (Strict Transport Security) usw… Inzwischen bin ich auf fast alle eingegangen. Es fehlt aber noch ein, wie ich finde, wichtiger Vertreter. HPKP (Public Key Pinning). Daher soll es nun um HPKP gehen 🙂

Public Key Pinning verfolgt einen ähnlichen Ansatz, wie Strict Transport Security, erweitert diesen nur etwas. Strict Transport Security wird als HTTP-Header gesetzt und sorgt dafür, dass ein Client für den Ablauf einer, durch diesen Header, gesetzten Frist nur noch SSL/TLS gesicherte Verbindungen zu dieser Domain benutzen wird. Public Key Pinning sorgt nun zusätzlich dafür, dass der Client nur gewisse Zertifikate über einen bestimmten Zeitraum annimmt.

Sind beide Header gesetzt, baut der Client also nur noch gesicherte Verbindungen auf und akzeptiert nur noch bestimmte Zertifikate, für einen gewissen Zeitraum. Dieses bietet ebenfalls gewisse Lücken, dennoch hebt es die Sicherheit ein ganzes Stück an, denn es wird für einen Angreifer deutlich aufwendiger seine gefälschten Zertifikate ins Rennen zu bringen.

Wie funktioniert es nun genau?
Im HPKP Header übermittelt der Webserver zwei base64 encodete SHA256-Hash Werte von den Public Keys zweier Zertifikate, sowie eine Ablaufzeit (und ggf. noch ein paar Optionen). Zwei Hash Werte aus einem einfachen Grund… Es kann ja passieren, dass man sein Zertifikat tauschen möchte/muss. Wäre hier nur der Hash eines Zertifikates „fest gepinnt“, würden alle Clients den Verbindungsaufbau mit dem neuen Zertifikat verweigern und dieses im schlimmsten Fall bis zum Ablauf der gesetzten Frist (in meinem Beispiel gleich 60 Tage). Aus diesem Grund nimmt man zwei! Das aktive Zertifikat, welches man ggf. direkt von der CA unterschreiben lässt und einsetzte, sowie ein Backup-Zertifikat, welches man vielleicht nur bis zum CSR vorbereitet und an einer anderen Stelle aufbewahrt. Nun könnte man direkt noch ein anderes Verfahren einsetzten oder ein anderes System um dieses Zertifikat zu erzeugen usw. usw… Wir halten also fest, Hash Werte von zwei Zertifikaten, wobei eines selbstverständlich das aktive ist.

Diese Hashwerte lassen sich nun mittels openssl über die keys, csr oder das fertige Zertifikat bauen. Ich nehme dafür gerne direkt die keys, da sich aus diesen alles weitere ergibt. Als Test, auf korrekte Hash Werte, kann man natürlich alle drei Wege nutzen. Dabei sollten sich natürlich immer die gleichen Werte ergeben!

Ich gehe also davon aus, dass bereits zwei Keys erstellt wurden. Damit lassen sich nun wie folgt die Hash Werte erstellen:

$ openssl pkey -in http-active.key -pubout | grep -v PUBLIC|base64 -d|openssl dgst -sha256 -binary|base64
31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME=
$ openssl pkey -in http-backup.key -pubout | grep -v PUBLIC|base64 -d|openssl dgst -sha256 -binary|base64
KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA=

Um die Header setzten zu können muss beim Apache noch das Modul headers geladen werden:

$ a2enmod headers

In der eigentlichen Konfigurationsdatei des jeweiligen hosts/vhosts fehlt nun nur noch folgende Zeile:

Header always set Public-Key-Pins: 'max-age=5184000; pin-sha256="31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME="; pin-sha256="KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA="'

Hash Werte natürlich einpassen 😛 und in dem Zuge über HSTS nachdenken!

Zusätzlich können noch ein paar Optionen in diesem Header folgen. So zum Beispiel report-uri=”http://www.example.org/hpkpReportUrl” Hier wird über einen HTTP-Post einige Informationen vom Client im JSON Format übertragen. Also ob es Probleme gab oder nicht… Die dort folgende URL sollte demnach vielleicht nicht SSL/TLS gesichert sein, oder nicht unter der gleichen Domain liegen. Wäre im Fehlerfall ja sonst ebenfalls nicht erreichbar! Ebenfalls lässt sich mittels includeSubdomains; zusätzlich angeben, dass dieses ebenso für alle Subdomains gilt.

Prüfen?
Prüfen kann man alles natürlich wieder per https://www.ssllabs.com/

Viel Spaß und wie immer, bei Fragen; fragen!

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Apache und sichere SSL / TLS Verschlüsselung

Einige haben es ja schon gesehen, ich habe nun doch vorzeitig mein Zertifikat von SHA1 auf SHA2 (SHA256) gehoben. Nein, ich habe nicht für das Widerrufen bezahlt 😛 Wer ins Zertifikat schaut, wird schon sehen wie ich es gemacht habe. Damit bin ich dann wohl erst einmal wieder A+…. Fragt sich für wie lange 😛 OCSP stört mich noch etwas, nicht unbedingt nötig, denn noch finde ich es ~unschön~! Jetzt nicht so unschön, dass ich es unbedingt sofort angehen muss; dennoch ist es irgendwie unschön!

 

So long 🙂