IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Security (Seite 7 von 16)

ownCloud / Nextcloud Security Scanner

Ihr erinnert euch doch sicher noch an meinen Bla zum BSI und nextcloud, oder? ==> Die Jungs vom BSI und nextcloud

Inzwischen ist der Scanner wohl für jeden einfach nutzbar… So wie man es von Qualys oder ähnlichem kennt. Einfach mal hier klicken: https://scan.nextcloud.com/ und fröhlich scannen.

Solche Scanner haben ja auch schon irgendwie etwas für sich, oder? Ein A+ sollte wohl für den Moment jeder ohne weitere Probleme erreichen können!

So long…

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

Die Jungs vom BSI und Nextcloud: Zusammenarbeit für mehr Sicherheit

Nextcloud hat sie die Mühe gemacht und mal nach owncloud und nextcloud Installationen gesucht. Dabei haben sie direkt mal geprüft wie sicher oder unsicher die wohl sind. Das hat seinen Weg zum BSI gefunden und die haben dann die abuse Adressen aller Netzbetreiber „gefüttert“.

Erstmal keine schlechte Idee. Natürlich will nextcloud was damit erreichen, das BSI macht auch brav mit super… Solange wir alle IPv4 machen läuft diese Version auch!

Oh ja, die abuse Mail:

Sehr geehrte Damen und Herren,
 
 ownCloud und Nextcloud sind Software-Lsungen zum Betrieb selbst
 gehosteter Cloud-Instanzen zur Synchronisation und zum Austausch
 von Daten.
 
 Das Unternehmen Nextcloud GmbH hat offen aus dem Internet
 erreichbare Installationen von ownCloud und Nextcloud geprft.
 Dabei wurden zahlreiche Cloud-Instanzen identifiziert, die mit
 veralteten Software-Versionen laufen, welche verschiedene
 Sicherheitslcken aufweisen.
 
 Angreifer knnen diese Schwachstellen ausnutzen, um unter anderem
 unberechtigt auf die in der Cloud gespeicherten Daten zuzugreifen.
 Dabei knnen die Angreifer ggf. sensible Informationen wie z.B.
 persnliche Dokumente, Fotos oder Kundendaten von Unternehmen
 aussphen und diese anschlieend im Internet verffentlichen oder
 fr kriminelle Zwecke wie Erpressungen nutzen.
 Andere Schwachstellen ermglichen Angreifern die Ausfhrung
 beliebigen Programmcodes auf dem Cloud-Server. Dies kann ggf.
 zu einer vollstndigen Kompromittierung des Systems und dessen
 Missbrauch fr weitere kriminelle Aktivitten fhren.
 
 Die Nextcloud GmbH hat CERT-Bund ihre Ergebnisse der Prfungen
 zur Untersttzung bei der Benachrichtigung betroffener Server-
 Betreiber bereitgestellt.
 
 Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in
 Ihrem Netzbereich. Der Zeitstempel (Zeitzone UTC) gibt an, wann
 die verwundbare Cloud-Installation identifiziert wurde.
 Weiterhin sind fr jedes System eine Risikoeinstufung sowie eine
 eindeutige ID (UUID) angegeben.
 
 Die Nextcloud GmbH stellt unter folgender URL detaillierte
 Informationen zu den bei der jeweiligen Cloud-Instanz erkannten
 Schwachstellen und deren Behebung zur Verfgung:
 https://scan.nextcloud.com/results/[UUID]
 
 Der Parameter [UUID] muss dabei durch die zu der jeweiligen Instanz
 angegebene UUID ersetzt werden. Beispiel:
 https://scan.nextcloud.com/results/12345678-1234-1234-1234-12345678
 
 Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur
 Aktualisierung der Cloud-Installationen auf den betroffenen Systemen
 zu ergreifen bzw. Ihre Kunden entsprechend zu informieren. Fr alle
 auf den betroffenen Systemen identifizierten Schwachstellen stehen
 entsprechende Sicherheitsupdates der Hersteller zur Verfgung.
 
 Bei Rckfragen zu den durchgefhrten Prfungen der Cloud-Instanzen
 wenden Sie sich bitte direkt an die Nextcloud GmbH unter
 <cloud-security-scan@nextcloud.com>.
 
 
 Diese E-Mail ist mittels PGP digital signiert.
 Informationen zu dem verwendeten Schlssel finden Sie unter
 <https://reports.cert-bund.de>.
 
 Bitte beachten Sie:
 Dies ist eine automatisch generierte Nachricht.
 An die Absenderadresse kann nicht geantwortet werden.
 Bei Rckfragen zu dieser Benachrichtigung wenden Sie sich bitte
 unter Beibehaltung der Ticketnummer in der Betreffzeile an
 <certbund@bsi.bund.de>.
 
 ======================================================================
 
 Betroffene Systeme in Ihrem Netzbereich:
 
 Format: ASN | IP | Timestamp (UTC) | UUID | Severity | Port | Hostname
  12345 | 1.2.3.4    | 2017-02-06 19:53:17 | 1ae3f7da-3367-4012-9382-7912dd4bd163 | high       | 80     | cloud.domain.de
  12345 | 1.2.3.5    | 2017-02-06 19:53:17 | 2e0a45fa-1568-458f-898e-2a888b44c9c6 | medium     | 80     | cloud.wurst.com
  12345 | 1.2.3.6    | 2017-02-06 19:53:17 | 32288a95-d396-4c9b-8998-d1968dc30ad7 | low        | 80     | cloud.alalaa.de 
  12345 | 1.2.3.7    | 2017-02-06 19:53:17 | ecfd4e62-b1b5-4c7d-b888-3f19ca3ca7ff | high       | 443    | cloud.butani.cn
  12345 | 1.2.3.8    | 2017-02-06 19:53:17 | 52ff7f71-c004-4a36-9975-2b5a99f280d6 | high       | 80     | cloud.bima.org
  12345 | 1.2.3.9    | 2017-02-06 19:53:17 | e388d8c5-4124-4af3-b052-57f77469783a | high       | 80     | cloud.2083a.net
  12345 | 1.2.3.10   | 2017-02-06 19:53:17 | 5cad0785-a6eb-47ca-aeec-6c4252928d13 | low        | 443    | cloud.lutzola.nl
  12345 | 1.2.3.11   | 2017-02-06 19:53:17 | 7da5d2dc-8556-4699-9ea4-7814c6afb8c0 | high       | 80     | cloud.weglaa.wu
  12345 | 1.2.3.12   | 2017-02-06 19:53:17 | adac575f-6a42-487d-a8c3-1b789ebafe39 | medium     | 80     | cloud.breck.aa
  [.....]

 
 Mit freundlichen Gren / Kind regards
 Team CERT-Bund
 
 Bundesamt fr Sicherheit in der Informationstechnik (BSI)
 Federal Office for Information Security
 Referat CK22 - CERT-Bund
 Godesberger Allee 185-189, D-53175 Bonn, Germany

Fragen? Einfach melden.

Anruf bei der G Data Hotline: Ein Erfahrungsbericht

Ich: tuuuuut…… tuuuuuut
Hotline: Bla gdata Hotline bla
Ich: Pffffhhhh
Hotline: *laala* (mucke)
Ich: Pffffhhhh
Hotline: Willkommen an der Hotline, mein Name ist Mann, was kann ich für sie tun?
Ich: Sie brauchen sicher meinen Benutzernamen, oder?

Das scheint da so etwas wie die Kundennummer in anderen Unternehmen zu sein….

Hotline: Oh ja, den nehme ich gerne.
Ich: Konrad-5-Julius-Heinrich-97- [Hotlinemann unterbricht mich]
Hotline: Konrad ausgeschrieben?
Ich: Öhm ähh ne also öh der Buchstabe?!?
Hotline: OK
Ich: Kundenummer…
Hotline: und was kann ich nun für sie tun?
Ich: Wir testen gerade die Amavis Integration eurer G DATA Business Lösung und das läuft nicht ganz rund.
Hotline: uhhaaa ohh
Ich: Warum uhaaa ohh?
Hotline: Öhm (hehe) also ähh, da bekommen wir eher weniger Anfragen. Wird nicht so oft benutzt.
Ich: Na aber ihr verkauft das ja.
Hotline: Ja aber ähh gut.


Dann wurden Version und OS abgefragt und ein Ticket angelegt. Ich sollte mal Auszüge aus dem Maillog senden. irgendwie habe ich das Gefühl als wenn das gerade nix wird.

Für Spaß auch mal die Logfiles:

Feb  7 08:27:54 mx amavis[27217]: (21323-04-4) (!)run_command: child process [27217]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)collect_results from [27217] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-21323-gFK_Ofar
Feb  7 08:27:54 mx postfix/smtp[27003]: EFA15C0A13: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=85234, delays=85181/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=21323-04-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:54 mx amavis[27219]: (21323-04-5) (!)run_command: child process [27219]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output=""
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="" at (eval 97) line 905.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)WARN: all primary virus scanners failed, considering backups Feb  7 08:27:54 mx amavis[27221]: (20783-09-4) (!)run_command: child process [27221]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)collect_results from [27221] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-20783-75UHo67I
Feb  7 08:27:54 mx postfix/smtp[27159]: D74F7C00F4: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=342238, delays=342185/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=20783-09-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:55 mx amavis[20783]: (20783-09-5) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.3.4]:44419 [1.2.3.4] <type@domain.de> -> <type@domain.de>, Queue-ID: 6D65CC0A33, Message-ID: <62734015.3835.1486452455492.JavaMail@domain.de>, mail_id: lsOZOYNAIa3o, Hits: 0, size: 44774, queued_as: 57B04C0A40, 471 ms

Feb  7 09:55:25 mx amavis[22893]: (22893-07) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.32.4]:36945 [1.5.7.98] <type@domain.de> -> <type@domain.de>, Queue-ID: E7592C0071, Message-ID: <20170207085513.B8A52340881@domain.de>, mail_id: 3lhpfBFnyuAI, Hits: 0, size: 4172, queued_as: 1F499C00F7, 10166 ms Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output="SKIP"
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="SKIP" at (eval 97) line 905.
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)WARN: all primary virus scanners failed, considering backups

Fragen? Einfach melden.

Neues Zertifikat für die Homepage von Let’s Encrypt

Tach zusammen,

StartSSL ist ja aktuell einfach tot 🙁 Eine für mich sinnvolle Alternative konnte ich aber nicht finden. Eine Wildcard Zertifikat für meine Domains und dann einfach überall das gleiche *grusel* aber 10000 € ausgeben um sonst meine Wünsche zu erfüllen macht auch keinen Sinn. Tja bleibt Let’s Encrypt…. Gott, ich will nicht alle drei Monate neue Zertifikate bauen. Das ist Käse, vor allem mit TLSA/DANE, HPKP usw. *brech*

Für jetzt bin ich dennoch dazu gezwungen auf Let’s Encrypt zu wechseln. Es wird also ein solches Zertifikat hier geben. Ich hoffe nun einfach darauf, dass StartSSL wieder in die Browser kommt. 01.06.2017 soll es da wohl weiter gehen, hm?

https://bugzilla.mozilla.org/show_bug.cgi?id=1311832

https://startssl.com/NewsDetails?date=20160919

Klar ist jetzt dieser China CA zu vertrauen? Nö… Nur bis zu einem gewissen Punkt und ab dann halt HPKP, TLSA/DANE, DNS CAA. Was mir so gut gefällt ist die Möglichkeit für einen vertretbaren Preis so viele unterschiedliche Zertifikate raus zu hauen, wie ich es für richtig halte.

Also kommt nun Let’s Encrypt als „hoffentlich Übergang“ und dann wieder StartSSL oder jemand von euch hat eine gute Idee für mich?

So long…

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

Spam im Jabber / XMPP

Aktuell beobachte ich sehr für SPAM mit teils russsichem Inhalt zu Exploits und ähnlichem, der von vielen verschiedenen Domains bei meinem Server ankommt.

Die Admins dieser Server kommen zum Teil aktuell nicht mit dem Aussortieren der Spamaccounts nach. Ich selbst habe ebenfalls schon viele Anmeldeversuche dieser Spamaccounts bewundert. Diese werden automatisch erstellt, dann etwas später wird darüber ein einem riesigen Schwung versucht Spam zu verteilen und nach knapp 1Stunde verstaubt der Account wieder. Dagegen hilft fast nur die einfache Benutzeranmeldung über xmpp zu deaktivieren.

Derzeit bei mir also nur möglich über (Gott ist das hässlich): https://jabber.kernel-error.de:9091/plugins/registration/sign-up.jsp

Oh ja, die Spamserver habe ich aktuell geblockt. Im Moment sind es die folgenden:

ajabber.me     
anonymitaet-im-inter.net     
codingteam.net     
exploit.im     
igniterealtime.org     
jabber.co.za     
jabber.no     
jabber.zerties.org     
jabbim.cz     
jclub.pw     
jumbo.li     
justnet.pl     
km-net.pl     
lih.im     
pandion.im     
qip.ru     
svnet.fr     
sync-hv.de     
talkers.im     
tigase.im     
xmpp.svnet.fr

Siehe auch: Eigenen Jabber-Server betreiben

Fragen? Einfach melden.

TLSA verkackt: Wenn man nach dem Zertifikatstausch den DNS-Record vergisst

Da kommt folgende Mail rein:

Hi,
mein Firefox Plugin und hash-slinger sagen beide, dass dein TLSA Record für
munin.kernel-error.com
kaputt ist.

Gruß
Andreas

Recht hat der Mann. Ich hatte das Zertifikat getauscht (auf Elliptic Curve umgestellt) und vergessen, den TLSA-Record im DNS zu aktualisieren. Klassiker. Der TLSA-Record enthält einen Hash des Zertifikats. Tauscht man das Zertifikat, stimmt der Hash nicht mehr, und jeder Client der DANE prüft sieht einen Fehler.

Passiert schneller als man denkt, besonders wenn man mehrere Dienste auf verschiedenen Subdomains hat. Jeder braucht seinen eigenen TLSA-Record. Zertifikat erneuern, TLSA vergessen, niemand merkt es (weil kaum jemand DANE validiert). Bis jemand wie Andreas mit dem Firefox-Plugin vorbeikommt.

Die Lektion: Nach jedem Zertifikatstausch die TLSA-Records prüfen. Am besten automatisiert, zum Beispiel per Skript das nach dem ACME-Renewal den Hash berechnet und den DNS aktualisiert. Wer TLSA-Records von Hand prüfen will, findet die Anleitung unter TLSA/DANE manuell prüfen. Die Grundlagen zu DANE stehen im Beitrag DNSSEC und DANE. Fragen? Einfach melden.

EC 521 bits / SHA256withRSA – Elliptic Curve mit openssl für den Apache

Heute möchte ich einmal ein Zertifikat für meinen munin erstellen. Als Test möchte ich einmal ein Zertifikat mit Elliptischen Kurven im Schlüssel probieren. Dieses soll natürlich ebenfalls von StartSSL signiert werden.

Die openssl Befehle sind wie immer nicht weiter besonders….

Schlüssel erstellen:

$ openssl ecparam -out http.key -name secp521r1 -genkey

CSR erstellen:

$ openssl req -new -sha256 -key http.key -nodes -out http.csr

Den Inhalt des CSRs ausgeben und der CA (StartSSL) zum signieren geben, sowie das signierte Zertifikat in die Datei http.crt gießen:

$ cat http.csr 
$ vi http.crt

Alles im PEM-File zusammenführen:

$ cat http.key http.crt > http.pem

Als guten Abschluss noch ein paar Diffie Hellman einwerfen (wenn auch etwas unnötig):

$ openssl gendh 4096 >> http.pem

Fertig ist das Zertifikat! Alles noch wie bekannt in den Apachen werfen und zur Sicherheit einmal Qualys auf die Seite loslassen:

https://www.ssllabs.com/ssltest/analyze.html?d=munin.kernel-error.com

Damit habe ich also nun ein EC 521 bits / SHA256withRSA Zertifikat. Tja, in meinem Firefox sieht alles aus wie immer. Gut, der Microsoft Rempel schlägt wie so oft hart auf aber ich nutze die Seite eh nie mit dem IE ;-P

Was meint ihr?

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

2048 bit Elliptic Curve Diffie-Hellman (ECDH) – Java 8 und Openfire

Kleinere Schlüssel als 2048bit sollte man mit Elliptic Curve Diffie-Hellman (ECDH) ja nicht mehr nutzen. Seit Java Version 1.8 ist dieses auch unterstützt. Wer also seinem Openfire xmpp/jabber Server diese Möglichkeit unterschieben möchte, sollte auf ein Oracle Java 1.8 setzen!

Wie also nun Java 8 dazu überreden? Auf einem Debian 8 (jessi) oder ähnlichem klappt es, wie folgt:

Möglichkeit Nummer 1. Zentral für alle Java Prozesse:

$ vim /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security
jdk.tls.ephemeralDHKeySize=2048

Möglichkeit Nummer 2. Nur für den Openfire, einfach beim Start mit übergeben:

$ vim /etc/default/openfire
# Additional options that are passed to the Daemon.
DAEMON_OPTS="-Djdk.tls.ephemeralDHKeySize=2048"

Um zu prüfen ob alles auch sauber umgesetzt ist hilft wie immer xmpp.net:

https://xmpp.net/result.php?id=7146

https://xmpp.net/result.php?id=7134

Oh ja, über Openfire AES 256 und JCE Unlimited Strength Jurisdiction Policy Files  müssen wir jetzt nicht mehr sprechen, oder? Ebenfalls nicht darüber, wie bei Openfire unsichere Cipher und Protokolle deaktivieren, oder?

Puhh… das was angenehm einfach oder? Bei Fragen, fragen.

Fragen? Einfach melden.

Ein Blick auf die Apache Header

TLS allein reicht nicht. Auch mit einem A+ bei Qualys SSL Labs fehlt ein wichtiger Teil: die HTTP-Security-Header. Sie schützen vor Cross-Site-Scripting, Clickjacking und MIME-Sniffing. Trotzdem setzen die wenigsten Webserver sie. Einen schnellen Überblick gibt securityheaders.com.

Modul aktivieren

Apache braucht das Headers-Modul. Unter Debian/Ubuntu:

a2enmod headers
service apache2 restart

Für spätere Konfigurationsänderungen reicht ein Reload (service apache2 reload).

Header setzen

Die Header können global in /etc/apache2/conf-enabled/security.conf oder pro vHost in der jeweiligen Konfigurationsdatei gesetzt werden:

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 unset X-Powered-By

Was die einzelnen Einstellungen bewirken

ServerSignature Off entfernt die Serverversion aus Fehlerseiten. ServerTokens Prod reduziert den Server-Header auf das Wort „Apache“, ohne Versionsnummer. Komplett entfernen lässt sich der Header im Standard-Apache nicht. Es gibt dazu einen Bug-Report mit WONTFIX. Manche Distributionen patchen das, sonst muss man selbst kompilieren oder damit leben.

TraceEnable Off deaktiviert die HTTP-TRACE-Methode serverweit.

X-Frame-Options: sameorigin verhindert, dass die Seite in fremde iframes eingebettet wird. Wer Einbettungen braucht, sollte diesen Header weglassen oder auf Content-Security-Policy: frame-ancestors umsteigen.

X-Content-Type-Options: nosniff verhindert MIME-Type-Sniffing im Browser. X-XSS-Protection aktiviert den XSS-Filter in älteren Browsern. Moderne Browser setzen stattdessen auf Content Security Policy (CSP).

Header unset X-Powered-By entfernt den PHP-Versionsheader, sofern vorhanden.

Ergebnis prüfen

Nach dem Reload die eigene Domain auf securityheaders.com scannen. Die Bewertung sollte sich deutlich verbessert haben.

Fragen? Einfach melden.

Firefox OCSP-Stapling Fehler bei StartSSL beheben

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht mehr vertrauenswürdig eingestuft und hat den Betrieb eingestellt. OCSP Stapling ist weiterhin relevant, aber die hier beschriebene Fehlerursache (StartSSL OCSP-Responder) existiert nicht mehr.

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 😀

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑