-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 19 von 45)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

FreeBSD: Automatische ZFS-Snapshots mit zfs-auto-snapshot

19. Mai 2016 / / Keine Kommentare

Automatische Snapshots einrichten

Auf FreeBSD gibt es mehrere Wege, ZFS-Snapshots zu automatisieren. Ein bewährtes Tool ist zfs-auto-snapshot aus den Ports (sysutils/zfstools). Es orientiert sich an der Snapshot-Automatisierung von Solaris/OpenSolaris und kann auch konsistente Snapshots einer MySQL- oder PostgreSQL-Datenbank erstellen.

Hinweis: Seit FreeBSD 13 gibt es mit periodic(8) und dem ZFS-Periodic-Script eine eingebaute Alternative, die ohne zusätzliche Pakete auskommt. Für ältere Systeme oder mehr Kontrolle über die Retention bleibt zfstools eine gute Wahl.

Installation:

pkg install zfstools

Danach die Cronjobs in /etc/crontab eintragen:

# ZFS snapshots
15,30,45 * * * * root /usr/local/sbin/zfs-auto-snapshot frequent  4
0        * * * * root /usr/local/sbin/zfs-auto-snapshot hourly   24
7        0 * * * root /usr/local/sbin/zfs-auto-snapshot daily     7
14       0 * * 7 root /usr/local/sbin/zfs-auto-snapshot weekly    4
28       0 1 * * root /usr/local/sbin/zfs-auto-snapshot monthly  12

Falls zfs im Cronjob nicht gefunden wird, die PATH-Variable in der Crontab erweitern:

PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin

Jetzt noch die Snapshots für das gewünschte Dataset aktivieren:

zfs set com.sun:auto-snapshot=true zroot/usr/home

Retention-Schema

Mit der Crontab oben werden folgende Snapshots vorgehalten:

  • Alle 15 Minuten — 4 Snapshots vorgehalten
  • Stündlich — 24 Snapshots vorgehalten
  • Täglich — 7 Snapshots vorgehalten
  • Wöchentlich — 4 Snapshots vorgehalten
  • Monatlich — 12 Snapshots vorgehalten

Snapshots prüfen

zfs list -r -H -t snapshot zroot/usr/home
zroot/usr/home@zfs-auto-snap_hourly-2016-05-19-11h00     21,5M  -  82,5G  -
zroot/usr/home@zfs-auto-snap_frequent-2016-05-19-11h30   14,6M  -  82,6G  -
zroot/usr/home@zfs-auto-snap_frequent-2016-05-19-11h45   13,3M  -  82,6G  -
zroot/usr/home@zfs-auto-snap_hourly-2016-05-19-12h00     14,0M  -  82,7G  -

Datenbank-Snapshots

Für konsistente Datenbank-Snapshots muss das Property auf dem Datenbank-Dataset speziell gesetzt werden — zfs-auto-snapshot friert die Datenbank dann vor dem Snapshot kurz ein:

# PostgreSQL
zfs set com.sun:auto-snapshot=postgresql zroot/data/postgres

# MySQL/MariaDB
zfs set com.sun:auto-snapshot=mysql zroot/data/mysql

Wichtig: Snapshots auf demselben System sind kein Backup-Ersatz. Geht die Platte kaputt, sind die Snapshots mit weg. Für eine echte Sicherung die Snapshots per zfs send/recv auf ein zweites System replizieren.

Mehr zu ZFS: ZFS Compression und Deduplication. Details zu allen Snapshot-Optionen in der OpenZFS-Dokumentation. Fragen? Einfach melden.

FreeBSD auf dem Desktop: Grundinstallation mit MATE

17. Mai 2016 / / Keine Kommentare

Nach der Grundinstallation von FreeBSD hängt man auf der Konsole. Kein Fenstermanager, kein Browser, keine grafische Oberfläche. Für Serverleute normal, für Desktopnutzer erstmal irritierend. Hier die Schritte von der nackten FreeBSD-Installation zu einem funktionierenden MATE-Desktop mit deutschem Layout.

Screenshot vom FreeBSD Desktop

Pakete installieren

Ein Einzeiler holt alles was man für den Anfang braucht. MATE als Desktop, Xorg als Display-Server, LightDM als Login-Manager und die üblichen Anwendungen:

pkg install xorg mate mate-desktop lightdm lightdm-gtk-greeter \
  firefox thunderbird pidgin vlc libreoffice gimp \
  de-aspell de-hunspell cups cups-pdf sudo

rc.conf anpassen

In der /etc/rc.conf die nötigen Dienste aktivieren:

# Deutsche Konsolenschriftarten
font8x8="iso15-8x8"
font8x14="iso15-8x14"
font8x16="iso15-8x16"

# D-Bus für den Desktop
dbus_enable="YES"

# Grafischer Login
lightdm_enable="YES"

# Drucken über CUPS
cupsd_enable="YES"
lpd_enable="NO"

# Temp-Verzeichnisse aufräumen
clear_tmp_enable="YES"
clean_tmp_X="YES"

# Erweiterte Device-Regeln aktivieren
devfs_system_ruleset="devfsrules_common"

Deutsche Locale

FreeBSD setzt Sprache und Zeichensatz über Login-Klassen. In der /etc/login.conf eine neue Klasse anlegen:

german|German Users Accounts:\
      :charset=UTF-8:\
      :lang=de_DE.UTF-8:\
      :tc=default:

Danach die Login-Datenbank neu bauen und dem Benutzer die Klasse zuweisen:

cap_mkdb /etc/login.conf

In vipw die Klasse german im fünften Feld eintragen:

kernel:*:1001:1001:german:0:0:Sebastian:/home/kernel:/usr/local/bin/fish

Xorg: Deutsches Tastaturlayout

Datei /usr/local/etc/X11/xorg.conf.d/keyboard-de-nodeadkeys.conf anlegen:

Section "InputClass"
    Identifier  "KeyboardDefaults"
    Driver      "keyboard"
    MatchIsKeyboard "on"
    Option      "XkbLayout" "de"
    Option      "XkbVariant" "nodeadkeys"
EndSection

Hardware-Berechtigungen

Normale Benutzer brauchen Zugriff auf Laufwerke, USB-Geräte und Soundkarten. Die /etc/devfs.rules regelt das. Wer das Thema im Detail verstehen will: Im Beitrag zu CD/DVD-Brenner-Berechtigungen unter FreeBSD ist das ausführlicher erklärt.

[devfsrules_common=7]
add path 'ada[0-9]\*'   mode 666
add path 'da[0-9]\*'    mode 666
add path 'cd[0-9]\*'    mode 666
add path 'pass[0-9]\*'  mode 666
add path 'xpt[0-9]\*'   mode 666
add path 'ugen[0-9]\*'  mode 666
add path 'usb/\*'       mode 666
add path 'video[0-9]\*' mode 666
add path 'mmcsd[0-9]\*' mode 666
add path 'lpt[0-9]\*'   mode 666
add path 'ulpt[0-9]\*'  mode 666

sudo und wheel-Gruppe

Den Benutzer in die Gruppe wheel aufnehmen und per visudo die sudo-Berechtigung setzen:

pw groupmod wheel -m kernel
# visudo
root   ALL=(ALL) ALL
kernel ALL=(ALL) ALL

loader.conf: Kernel-Module

In der /boot/loader.conf ein paar Module die auf einem Desktop sinnvoll sind:

# Neuer Grafik-Konsolentreiber
kern.vty=vt

# Kernel-Tuning
kern.ipc.shmseg=1024
kern.ipc.shmmni=1024
kern.maxproc=10000

# SD-Kartenleser
mmc_load="YES"
mmcsd_load="YES"
sdhci_load="YES"

# FUSE (Dateisysteme im Userspace, z.B. NTFS)
fuse_load="YES"

# CPU-Temperatursensoren (Intel)
coretemp_load="YES"

# tmpfs und asynchrone I/O
tmpfs_load="YES"
aio_load="YES"

# Unicode auf Wechselmedien
libiconv_load="YES"
libmchain_load="YES"
cd9660_iconv_load="YES"
msdosfs_iconv_load="YES"

# Sound
snd_driver_load="YES"

# Linux-Kompatibilität
linux_load="YES"

# ZFS ARC begrenzen (hier 2 GB, an RAM anpassen)
vfs.zfs.arc_max="2048M"

Die vfs.zfs.arc_max Einstellung ist wichtig. ZFS nutzt standardmäßig so viel RAM wie verfügbar für den Dateisystem-Cache. Auf einem Desktop mit 8 GB will man das begrenzen, damit für Anwendungen genug übrig bleibt.

Fertig

Nach einem Neustart sollte LightDM den grafischen Login zeigen. MATE als Session auswählen, anmelden, fertig. Firefox, Thunderbird, LibreOffice und der Rest sind installiert und startbereit.

FreeBSD auf dem Desktop ist nicht so komfortabel wie ein Ubuntu. Dafür hat man ein sauberes ZFS, ein durchdachtes System und eine Dokumentation die ihresgleichen sucht. Wer sich darauf einlässt, wird es mögen.

Fragen? Einfach melden.

MacBook Pro GPU-Panic Reparatur: Backofen-Methode im Test

14. Februar 2016 / / Keine Kommentare

Mir ist vor kurzem ein Apple MacBook Pro (Mitte 2010) in die Hände gefallen. Hardware noch ganz interessant — 8 GB RAM, Core i7, SSD. Aber das Ding hatte den bekannten Bug mit der NVIDIA GeForce GT 330M. Abstürze und Reboots mitten in der Arbeit, und die wurden eher mehr als weniger.

Die Optionen

  1. Apple mit Garantie — anrufen und reparieren lassen.
  2. Apple ohne Garantie — knapp 500 € Reparaturkosten. Lohnt sich bei einem sechs Jahre alten Gerät nicht.
  3. Apple Kulanz — gab es tatsächlich, sogar bis zwei Jahre nach Garantieablauf. Für mein Gerät aber zu spät.
  4. GPU per Software deaktivieren — die NVIDIA Karte abschalten und nur mit der Intel HD Graphics in der CPU leben. Funktioniert, schiebt den endgültigen Tod aber nur auf. Irgendwann startet die Kiste gar nicht mehr.
  5. Backofen.

Backofen?

Klingt bekloppt. Ist es auch — etwas. Die NVIDIA GPU ist als BGA (Ball Grid Array) auf das Logicboard gelötet. Unter Hitze und Vibration brechen mit der Zeit einzelne Lötstellen. Die GPU verliert die Verbindung zum Board — Kernel Panic.

Wenn ich mir mein Gerät genauer anschaue, findet sich vorne links eine beachtliche Delle. Da ist das Teil draufgefallen und das war vermutlich der Anfang vom Ende.

Die Idee: Das Logicboard im Backofen auf eine Temperatur bringen, bei der das Lötzinn weich wird und die Verbindungen sich neu setzen — ein primitiver Reflow. Apple hat sich die Mühe gemacht, alle wichtigen Chips seitlich mit dem Board zu verkleben. Das hält die Chips an Ort und Stelle, während das Lot flüssig wird.

Schritt für Schritt

  1. Logicboard komplett ausbauen — iFixit hat gute Anleitungen dafür.
  2. Backofen auf 200 °C vorheizen. Ober-/Unterhitze, keine Umluft — die Vibrationen des Gebläses können das Board zerstören.
  3. Aus Alufolie kleine Füße formen und in die Bohrungen des Boards stecken. So liegt es nicht direkt auf dem Blech.
  4. Board rein, schwere Chips nach oben. Danach nicht mehr bewegen.
  5. 7 bis 8 Minuten backen.
  6. Ofen abschalten, Tür leicht öffnen, 15–20 Minuten langsam abkühlen lassen. Wenn man das Board mit der Hand greifen kann, ist es kühl genug.
  7. Zusammenbauen, Daumen drücken.

Die Kunststoffbuchsen auf dem Board halten 7 Minuten bei 200 °C aus — die müssen nicht abgedeckt werden.

Hat es funktioniert?

Ja. Überraschenderweise.

Aber — und das muss klar sein — diese Methode ist ein letzter Versuch. Die Erfolgsquote ist gering. Das Flussmittel in den Lötstellen verbrennt beim Erhitzen teilweise, daher funktioniert ein zweiter Durchgang fast nie. Wenn euer MacBook sowieso auf dem Weg in die Tonne ist: probiert es. Wenn ihr noch ernsthaft auf das Gerät angewiesen seid: lasst es.

Der Panic-Log

Für die Suchmaschinen und alle, die den gleichen Fehler haben — hier die relevanten Zeilen aus dem Kernel-Panic-Report:

*** Panic Report ***
panic(cpu 0 caller 0xffffff7f9320abad):
  "GPU Panic: [<None>] 3 3 7f 0 0 0 0 3 :
   NVRM[0/1:0:0]: Read Error 0x00610b94:
   CFG 0xffffffff 0xffffffff 0xffffffff,
   BAR0 0xd2000000 0xffffff912c33d000 0x0a5480a2, D0, P3/4"

System model name: MacBookPro6,2 (Mac-F22586C8)
Mac OS version:    15B42 (El Capitan 10.11.1)

Graphics: NVIDIA GeForce GT 330M, PCIe, 512 MB
Graphics: Intel HD Graphics, Built-In

Kernel Extensions in backtrace:
  com.apple.nvidia.classic.NVDAResmanTesla  10.0
  com.apple.nvidia.classic.NVDANV50HalTesla 10.0
  com.apple.driver.AppleMuxControl          3.11.33b1
  com.apple.iokit.IOGraphicsFamily          2.4.1

Der entscheidende Hinweis: NVRM[0/1:0:0]: Read Error mit CFG 0xffffffff — die CPU kann den Konfigurationsraum der GPU nicht mehr lesen. Die Verbindung ist weg.

Jetzt habe ich hier also so ein komisches MacBook. Der spannende Teil — auseinanderbauen und reparieren — ist erledigt. Was macht man nun damit?

Siehe auch: Parken an der Burg Blankenstein

Fragen? Einfach melden.

Sicheres onlinebanking in China

21. Januar 2016 / / Keine Kommentare

Ich habe ja beruflich ebenfalls mit der Betreuung von Systemen in China zu tun. Die Probleme mit der „great wall of china“ sind mir also bekannt. Onlineüberwachung ist hier also sehr deutlich vertreten, sobald man etwas Crypto einsetzte, wird die Verbindung gleich so schlecht, langsam und instabil, dass es keinen Spaß mehr macht sie zu nutzen. Wenn es überhaupt zu einer Verbindung kommt!

Was mir aber jetzt geschickt wurde ist schon hart 🙂 „sicheres onlinebanking in China“ oder so ähnlich! Erlaubt ist, was geknackt werden kann. *kopfschüttel*. 

OK OK, China ist weit weg und wer hat schon ein Konto in China? Ich möchte aber noch einmal anmerken, dass auch bei uns und in den USA bereits Ideen aus der Regierung gekommen sind, nur noch Verschlüsselungen zu erlauben, welche auch „geknackt“ werden können… Oder erinnert euch an die Idee, jede Verschlüsselung ebenfalls noch einmal mit einem speziellen Schlüssel der Regierung mit verschlüsseln zu müssen? So das die Regierung in jedem Fall die Möglichkeit hat alles zu entschlüsseln! Natürlich alles zur Terrorabwehr… versteht sich von selbst!

So anstrengend unsere Aluhüte manchmal sind… Sie retten auch unsere Freiheit!

Danke Jost!

Fragen? Einfach melden.

Debian in einer FreeBSD Jail: Linux-Userland mit iocage und debootstrap

13. November 2015 / / Keine Kommentare

FreeBSD kann Linux-Binaries ausführen. Das ist nichts Neues. Aber ein komplettes Debian in einer Jail laufen lassen, mit apt-get und allem was dazugehört? Das geht auch. Die Jail nutzt den FreeBSD-Kernel, das Userland kommt von Debian GNU/kFreeBSD. iocage erstellt die Jail, debootstrap installiert das Debian-Basissystem hinein.

Hinweis: Debian GNU/kFreeBSD wurde nach Debian 8 (Jessie) eingestellt. Für aktuelle Setups ist linux_enable="YES" in der /etc/rc.conf mit einer regulären Linux-Jail der bessere Weg. Die hier gezeigte Methode funktioniert aber weiterhin mit älteren Debian-Versionen und zeigt das Prinzip.

Voraussetzungen

iocage muss installiert und konfiguriert sein. Zusätzlich wird debootstrap benötigt:

pkg install debootstrap

Jail erstellen

Die Jail wird mit iocage angelegt. Die entscheidenden Parameter sind exec_start und exec_stop. Statt der üblichen FreeBSD-Init-Skripte werden die Debian-Runlevel aufgerufen:

iocage create -e tag=debian-jail01 \
  exec_start="/etc/init.d/rc 3" \
  exec_stop="/etc/init.d/rc 0"

Runlevel 3 startet die Dienste, Runlevel 0 fährt herunter. Den Mountpoint der neuen Jail auslesen:

iocage get mountpoint debian-jail01
# /iocage/jails/19e3594f-.../

Debian installieren

debootstrap holt ein minimales Debian von den Mirrors und entpackt es in das Root-Verzeichnis der Jail. In diesem Beispiel Debian Wheezy:

debootstrap wheezy /iocage/jails/19e3594f-.../root/
# I: Retrieving Release
# I: Retrieving Packages
# I: Resolving dependencies of required packages...
# I: Resolving dependencies of base packages...
# [... ~150 Pakete werden heruntergeladen und entpackt ...]
# I: Configuring adduser...
# I: Configuring apt...
# I: Base system installed successfully.

Das dauert ein paar Minuten. Am Ende steht ein komplettes Debian-Basissystem im Jail-Verzeichnis.

fstab für die Jail

Debian braucht ein paar Dateisysteme die FreeBSD nicht automatisch in Jails mountet. Die fstab der Jail (nicht die im Debian) bekommt drei Einträge:

# /iocage/jails/19e3594f-.../fstab
linsysfs  .../root/sys         linsysfs  rw          0 0
linprocfs .../root/proc        linprocfs rw          0 0
tmpfs     .../root/lib/init/rw tmpfs     rw,mode=777 0 0

linsysfs und linprocfs stellen die Linux-kompatiblen /sys und /proc bereit. Ohne die funktionieren viele Linux-Programme nicht. Das tmpfs für /lib/init/rw braucht Debians Init-System.

Netzwerk und Hostname

IP-Adresse und Hostname setzen:

iocage set vnet=off debian-jail01
iocage set ip4_addr="em0|192.168.1.46/16" debian-jail01
iocage set hostname="debian-jail01" debian-jail01
iocage set host_hostname="debian-jail01" debian-jail01

Die /etc/hosts im Debian-Dateisystem anpassen:

# /iocage/jails/19e3594f-.../root/etc/hosts
127.0.0.1       localhost debian-jail01
::1             localhost ip6-localhost ip6-loopback debian-jail01

Starten und nutzen

Beim ersten Start kommen ein paar Fehlermeldungen wegen mount_unionfs und fehlenden Verzeichnissen. Die sind harmlos und können ignoriert werden:

iocage start debian-jail01
# mount_unionfs: .../: No such file or directory
# mount: .../root/usr/home: No such file or directory
# * Starting 19e3594f-... (debian-jail01)
#   + Started (shared IP mode) OK
#   + Starting services        OK

Konsole betreten:

iocage console debian-jail01
# GNU/kFreeBSD debian-jail01 10.2-RELEASE-p4
root@debian-jail01:~# apt-get update
root@debian-jail01:~# apt-get install mc

apt-get funktioniert, Pakete lassen sich installieren, Dienste starten. Von aussen geht auch iocage exec debian-jail01 uname -a und zeigt den FreeBSD-Kernel mit GNU/kFreeBSD-Userland.

Das Stoppen funktioniert wie bei jeder anderen Jail:

iocage stop debian-jail01

Einordnung

Das hier ist kein Ersatz für eine richtige Linux-VM. Es ist ein Trick: Der FreeBSD-Kernel stellt die Jail-Isolation, Debian liefert das Userland. Nützlich wenn man ein bestimmtes Linux-Tool braucht das es für FreeBSD nicht gibt, oder wenn man testen will wie sich Software unter Debian verhält.

Für produktive Linux-Workloads auf FreeBSD ist heute eher eine reguläre Jail mit dem Linux-Kompatibilitätslayer oder gleich bhyve die bessere Wahl.

Fragen? Einfach melden.

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

26. Oktober 2015 / / Keine Kommentare

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

20. September 2015 / / Keine Kommentare

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

11. August 2015 / / Keine Kommentare

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 😀

Certificate Transparency Support – StartSSL

21. Juli 2015 / / Keine Kommentare

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft. Certificate Transparency ist heute bei allen CAs Pflicht und erfordert keine gesonderte Konfiguration mehr.

Google hatte 2014 eine weitere Idee um Zertifikate „vertrauenswürdiger“ zu gestalten. Alles unter dem Namen: „Google’s Certificate Transparency project“ http://www.certificate-transparency.org/ Hat man eine CA „geknackt“ oder entsprechenden Einfluss (z.B.: als Staat), kann man sich für beliebige Domains gültige Zertifikate ausstellen. Der jeweilige User rutscht also auf einer Webseite herum, die Verbindung ist verschlüsselt und das Zertifikat ist sauber. Ihm fällt also erst einmal nichts auf und somit fühlt sich der User sicher…. Genau diesen Punkt möchte Googles Idee verbessern! Die jeweilige CA „veröffentlicht“ das erstellte Zertifikat. So können die Clients/Browser diese „Logs“ absuchen und somit herausfinden, welches Zertifikat für welche Domain wohl das gültige ist. So lassen sich untergeschobene Zertifikate finden. OK, es gibt da schon Wege: – DNSsec – TLSA/DANE – Public Key Pinning (HPKP) Warum also etwas neues? Tja…. Dieses sind alles Techniken, welche der Admin selbst nutzen muss. Der Admin muss aktiv etwas tun. Bei Googles CT übernimmt diese Arbeit im Grunde die CA selbst. Maximal muss man noch einen kleinen Hacken setzten, fertig. Zertifikatsproblem Über Sinn und Unsinn kann man sich nun streiten. Ändert aber nichts, da Google dieses einfach in ihren Browser fest eingebaut hat. Möchte man nun also kein gelbes Ausrufezeichen in der Adresszeile vom Chrome haben, muss die eigene CA CT unterstützen und das Zertifikat veröffentlichen. StartSSL/StartCOM tut dieses bisher noch nicht. Ich habe aber folgende Info bekommen: There will be support shortly for submitting to the CT logs and installing the response for CT aware web servers (TLS extension). Support for the latter is lacking for a large part, but it should get better over time, most likely Apache first. Wenn ich mehr habe, gibt es mehr.
U-P-D-A-T-E Ich habe mal nach einem Zeitplan gefragt: I’m not sure about that, but the minute it’s supported there will be a new tool at the StartSSL Tool Box of your account. Tja… Na dann! -_-

Apache 2.4 und Diffie-Hellman DHE mit 4096bit

6. Juli 2015 / / Keine Kommentare

Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:

Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?

Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.

Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<

Wer gerne nachträglich generieren möchte macht es mir:

$ openssl gendh 4096 > dh_4096.pem

Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.

Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe.

easy

So long….

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑