Kostenlose und günstige SSL-Zertifikate – Einkaufsführer

SSL-Zertifikate (oder sollte ich TLS sagen? Nun gut, lassen wir das) werden von Herausgeberstellen, den Certificate Authorities, herausgegeben und Bestätigen die „Echtheit“ einer Domain oder Person. Im einfachsten Fall muss der Beantragende nur beweisen, dass ihm eine Domain gehört bzw. er Zugriff auf den Webspace hat, in komplexeren Fällen werden die Identität des Beantragenden durch Ausweiskontrolle und bei Firmen durch Handelsregisterauszüge geprüft. Man teilt Zertifikate daher in 5 Klassen ein.

  • Klasse 1 ist dabei für Privatpersonen gedacht und es wird nur die Domain verifiziert.
  • Ab Klasse 2 nimmt man ein Zertifikat normalerweise ernst, da ein Nachweis der Identität erbracht werden muss. Man sagt daher auch, dass Firmen Zertifikate ab Klasse 2 verwenden (müssen).
  • Klasse 3 erlaubt die Signierung von Code, bspw. unter Windows
  • Zusätzlich existiert mit „Extended Validation“ ein sehr gefragter Zertifikatstyp, der das grüne Siegel im Browser ermöglicht und was die Anforderungen betrifft mehr oder minder Klasse 3 entspricht.
    Mindestens ebenso interessant ist das Renomme des Herausgebers, denn nur wenn das Root-Zertifikat, mit dem eine Certificate Authority, das jeweile Zertifikat signiert, im Browser oder Betriebssytem installiert ist, können Zertifikate validiert werden. Ältere Betriebssysteme und Browser kennen nur ebenso alte Zertifizierungsstellen. Der Wettbewerb in dem Markt hat nach und nach neue Zertifizierungsstellen angelockt, die erst nach und nach in Betriebssysteme/Browser integriert werden.

Empfehlung: Für die private Homepage reicht Klasse 1 aus und mit modernen Browsern hat man keine Problem gleich ob Comodo, RapidSSL oder Thawte.

Einige Experten halten das auf Vertrauensstellung basierende Zertifikatssystem für veraltet, setzen auf certificate-pinning etc. aber um den Otto-Normalverbraucher zu erreichen, muss man weiterhin Zertifikate erwerben.

Es gibt sie auch kostenlos bei Let’s Encrypt, momentan in kaum einem Browser vertreten, oder bei Startssl (Personengebunden: Class1 nach Anmeldung, Class2 nur nach gebührenpflichtiger Validierung der Identität).
Ebenso erhält man die Comodo-Domainzertifikate für 5-10€ pro Jahr.

Es gibt dennoch eine Berechtigung für kostenpflichtige, teurere Zertifikate und zwar bei folgenden Anwendungszwecken:

  • Extended Validation (grünes Siegel im Browser)
  • Wildcardzertifikate, die für Subdomains unter einer Domain gelten

Ich habe eine Liste günstiger Bezugsquellen als kleinen SSL-Einkaufsführer zusammengestellt, die ich jeweils mit einem kurzen Kommentar versehen habe:

  • Mein FAVORIT: GoGetSSL mit Bestpreisgarantie und tollem Resellerinterface inkl. Webpanel-Integration. Resellerpreise: Comodo PositiveSSL für nur 4$(!) oder als Wildcard für 69$, Comodo EV SSL für 98$.
    Hinweis: Comodo EV Trial SSL heißt nun Comodo InstantSSL with Free EV und kostet 30$.
  • AlphaSSL: Wildcard-Zertifikat für nur 39$ p.a. bei 2 Jahren Laufzeit
  • Cheapsslsecurity: Comodo PositiveSSL (Class1) 4,99$ und Essential SSL (Class2) für 17$, RapidSSL (Class1) für 6,66$ und Geotrust Premium (Class2) für 37,4$
  • GlobeSSL: Class 1 ab 5$
  • 20 Empfehlungen für günstige Bezugsquellen

Hinweis: zu allen US$-Preisen wird typischerweise 21% VAT/USt fällig und es kommen Währungskonvertierungskosten hinzu.

Probleme mit IPTV (Entertain) über WLAN mit DDWRT/OPENWRT-Firmware auf dem Router? Lösung!

Installiert man auf einem Router die alternativen Firmwares DDWRT oder OpenWRT kann man darauf einige Funktionen aktivieren, die mit der Herstellerfirmware nicht vorgesehen waren.
Unglücklicherweise fängt man sich damit aber auch das Problem ein, dass die Accesspointfunktion in Mitleidenschaft gezogen wird und IPTV-Streams wie T-Entertain über WLAN nicht mehr richtig funktionieren oder stocken. Bei 802.11n WLAN-Protokoll basierten Routern, die problemlos 300 Mbps Bruttodatenrate erzielen unverständlich, zumal ein Speedtest schnell zeigt, dass die Bandbreite selbst nicht das Problem ist.

Ursächlich ist eine unglückliche Einstellung in den erweiterten WLAN-Settings bzgl. der Paketgröße über WLAN. Sie führt dazu, dass Pakete beispielsweise sehr stark fragmentiert werden und ein IPTV-Paket dann in 2 oder 3 WLAN-Pakete (richtig wäre 802.11n-Frame) eingepackt werden muss, weil es die „Fragementation Treshold“, also die Schwelle aber der fragmentiert wird, überschreitet. Die verursacht bei einem UDP-IPTV-Livestream ohne Bufferung natürlich Verzögerungen, instabile Paketlaufzeiten und reduziert den Durchsatz ein klein wenig. Moderne TCP-basierte Anwendungen erkennen diesen Umsatz und passen die Paketgröße durch Reduktion an, doch Entertain beherrscht dies nicht und ist ohnehin UDP-basiert.

Der Fehler kann aber auch in einer zu großen Paketgröße liegen, wobei der Router dann wartet, bis er ausreichend IPTV-Pakete gesammelt hat, um sie gemeinsam in eine WLAN-Datenpaket zu verpacken und zu senden. Der Client empfängt dann zwar mehrere Pakete auf einmal aber eben mit Verzögerung und u.U. ungleichen Laufzeiten. Geht ein WLAN-Paket durch Störungen fehlen gleich mehrere IPTV-Pakete und es gibt Bildstörungen oder Aussetzer.

Hintergrund Paketgrößen und MTU:
Ein Ethernet (LAN)-Frame bzw. Paket ist normalerweise 1518 Bytes groß (VLANs und Q-in-Q-tagging außen vor gelassen). Zieht man den Header ab, so verbleiben 1500 Bytes, was auch als maximum transmission unit (MTU) bezeichnet wird.
Beim Internetzugang über xDSL werden die Pakete mittels PPPoE-Protokoll eingepackt, was weitere 8 Bytes kostet
Bei der kabelgebundenen Übertragung tritt das Problem übrigens nicht auf, da die maximale IP-Paketgröße aus dem Internet bei 1500 Bytes MTU (Ethernet-Paketgröße) abzüglich PPPeE-Header bei 1492 Bytes liegt.
Beim Versand eines IP-Datenpaketes fallen für den IP-Header 20 Bytes weg, was die Nutzlast auf 1472 Bytes reduziert.
Mittels ping-Kommando kann man ein ICMP-Datenpaket versenden es mit do-not-fragment-Flag versehen, um die maximale Paketgröße zu ermitteln.
Da ICMP wiederum einen Header von 8 Bytes hat, führt folgendes Kommando auf einem DSL-Anschluss zum Erfolg:
ping -f spiegel.de -l 1464

Die Lösung liegt in der Anpassung zweier Werte in den WLAN-Einstellungen der alternativen Firmwares DDWRT/OPENWRT.
Die 802.11n-Pakatgröße beträgt normalerweise 2346 Bytes. Es wird deutlich, dass ein IP-Datenpaket mit maximal 1472 Bytes ohne Fragementierung genau einmal reinpasst. Für ruckelfreies IPTV sollte der Router also genau ein IP-Paket in ein WLAN-Paket packen und dieses dann sofort abschicken. Ein Entertain Multicast-IPTV-Paket ist typischerweise 1370 Bytes groß (Protocol 2048 (ip), IP Protocol 17 (udp), Size 1370, IP Packet Size 1356, IP: IP Header Size 20, TOS 32,..)
Der Wert müsste also so gewählt werden, dass ein Entertain-Paket nicht fragmentiert wird und zugleich nicht zwei Entertain-Pakete in einem WLAN-Paket landen. Zugleich sind aber weitere IP-Pakete auf dem WLAN-Interface unterwegs diese beanspruchen durchschnittliches nicht die volle Größe. Darüber hinaus senden PCs im lokalen Netz 1500 Bytes großes Ethernetframes.
Es lässt sich daher keine Patentlösung finden, die sich an einer bestimmen Paketgröße orientiert.
Man ist daher gezwungen, die WLAN-Datenpaketgröße so klein zu wählen, dass sowohl typische Standard-Ethernetframe als auch IPTV-Datenpakete zügig abtransportiert werden.

Neben der Fragmentierungsschwelle verwendet das WLAN-Protokoll 802.11n noch das RTS-CTS (Request to Send / Clear to Send)-Protokoll u.a. um zu prüfen, ob der Kanal frei ist und um Kollisionen und damit einhergehende verlorene oder defekte Pakete zu vermeiden. Die Einstellung „RTS Treshold“ legt fest, ab welcher Paketgröße WLAN-Accesspoint und Client das RTS-CTS-Protokoll verwenden müssen. Die WLAN-Paketgröße muss also kleiner oder gleich der RTS Treshold liegen, sonst wird letztere niemals überschritten.

Den Lösungsvorschlag habe ich nach einiger Recherche hier gefunden und er basiert darauf, Standard-Ethernet-Paket mit  1500 Bytes Größe (=MTU) in zwei WLAN-Pakete aufzuteilen und empfiehlt eine Fragmentation Treshold von 784 Bytes (1500 Bytes Framesize / 2 = 750 Bytes Nutzlast + 34 Bytes Overhead für Header).
Dem geht einher, das RTS-CTS-Protokoll ab einem Drittel Ethernet-Frame zu verwenden, also einer RTS Treshold von 534 Bytes.

Im Falle der Entertain IPTV-Datenpakete, die 1370 Bytes groß sind, wird das RTS-CTS-Protokoll verwendet und es wird auf zwei WLAN-Pakete fragmentiert.

Gruppenrichtlinientemplates auf Windows 10 (1511) aktualisieren, Berechtigungsproblem umgehen

Wer das Herbst 2015-Update von Windows 10 (1511) nicht per Clean Install installiert hat, sondern ein Upgrade eines bestehenden Windows 10 über Windowsupdate ausgeführt hat, der wird möglicherweise veraltete Gruppenrichtlinientemplates (.ADMX-Dateien) auf seinem System vorfinden.
Ärgerlich ist dies beispielsweise, wenn man Bitlocker standardmäßig auf die sicherere XTS AES-Variante einstellen möchte, die mit Windows 10 (1511) eingeführt wurde.

Der Task ist relativ simpel: Neue Templates herunterladen und nach C:\Windows\PolicyDefinitions kopieren, scheitert aber normalerweise an fehlenden Berechtigungen.

Aber Schritt für Schritt:

  1. Aktualisierte Gruppenrichtlinien-Templates für Windows 10 (1511) herunterladen (es wird nur die Datei Windows10_Version_1511_ADMX.msi benötigt) und installieren.
  2. Prüfen, ob die neuen Versionen in C:\Program Files (x86)\Microsoft Group Policy\Windows 10 Version 1511\PolicyDefinitions liegen, das Dateidatum müßte dem 14.11.2015 10:05 Uhr entsprechen.
  3. Eine Eingabeaufforderung als Administrator starten und dann
    1. In das Zielverzeichnis wechseln:
      # cd C:\Windows\PolicyDefinitions
    2. Sich die erforderliche Berechtigung verschaffen:
      # takeown /f *
      # icacls     * /grant "%USERDOMAIN%\%USERNAME%":(F)
    3. Die neuen 195 Dateien von C:\Program Files (x86)\Microsoft Group Policy\Windows 10 Version 1511\PolicyDefinitions nach C:\Windows\PolicyDefinitions kopieren und dabei vorhandene Versionen überschreiben.
    4. Die Berechtigungen wiederherstellen:
      # icacls     * /setowner "NT SERVICE\TrustedInstaller"
      # icacls     * /remove "%USERDOMAIN%\%USERNAME%"
    5. Teilschritte 1 bis 4 für die Unterverzeichnisse „de-DE“ und „en-US“ wiederholen.
  4. Nun kann der Gruppenrichtlinieneditor (gpedit.msc) gestartet werden und sollte die aktualisierten Einstellungsmöglichkeiten anzeigen.

Fertig!

Ich habe mich beim Vorgehen an einer Anleitung orientiert, die die ADMX-Berechtigungsthematik anhand des Bugs der doppelten Files LocationProviderADM.admx und Microsoft-Windows-Geolocation-WLPAdm.admx auf einem Windows Server nach Einspielen der aktualisierten Gruppenrichtlinien beschreibt, orientiert.

Festplattenverschlüsselung mittels Bitlocker unter Windows 10 (1511) konfigurieren

Windows 10 bringt mit Bitlocker in der Pro-Version (in Home leider nicht unterstützt) eine hauseigene Festplattenverschlüsselungssoftware mit, die mit UEFI-Bios kompatibel ist.

Sofern man über einen Computer mit TPM-Modul verfügt und dies im Bios eingestellt und richtig konfiguriert (möglichst TPM 2.0 statt Auto oder 1.2 konfigurieren) hat und Safeboot verwendet, sollte damit ein ausreichendes Sicherheitsniveau erreichbar sein. Über die Vor-und Nachteile sowie Alternativen möchte ich mich an dieser Stelle nicht auslassen, sondern nur auf die Konfiguration der Verschlüsselung eingehen.
Das Thema wird im Englischen von Chris Hoffmann ausführlich behandelt und detailliert und schön bebildert erklärt: How to Make BitLocker Use 256-bit AES Encryption Instead of 128-bit AES

Änderungen seit Windows 10 (1511)
Zu beachten gilt es, dass Windows 10 seit Build 1511 (Herbst 2015-Update) den neuen Verschlüsselungsmodus XTS AES.
Microsoft schreibt dazu: „XTS AES bietet zusätzlichen Schutz gegen eine Klasse von Angriffen auf die Verschlüsselung, die darauf beruht, verschlüsselten Text so zu manipulieren, dass im Nur-Text vorhersagbare Änderungen verursacht werden. BitLocker unterstützt 128-Bit- und 256-Bit-XTS AES-Schlüssel„.

Unzureichende Standardeinstellung
Zu beachten gilt es, dass Windows 10 RTM (also vor 1511) per default mit AES 128 verschlüsselt hat, die 1511 Version verschlüsselt mit XTS AES 128, besser wäre aber XTS AES mit 256-bits.
Dies kann mittels des Gruppenrichtlinieneditors (gpedit.msc) leicht angepasst werden im Baum unter Computerkonfiguration, Windows-Komponenten, Bitlocker-Laufwerksverschlüsselung und dann in der Option „Verschlüsselungsmethode und Verschlüsselungsstärke für Laufwerke auswählen (Windows 10 [Version 1511] und höher)“.
gpedit-bitlocker

Im Dialog muss zunächst aktivieren gewählt werden, anschließend können die Einstellungen für das Startvolumen, Festplatten und Wechseldatenträger geändert werden. Die ersten beiden sollten unbedingt XTS-AES 256-Bit erhalten. Bei Wechseldatenträgern empfiehlt Microsoft bei AES zu verbleiben, vermutlich weil nur diese Variante mit alten Betriebssystemen (Windows 7, 8, 8.1, 10 (vor 1511)) kompatibel sind.
gpedit-bitlocker-dialog
Sobald diese Einstellungen vorgenommen wurden, sollte der Computer neu gestartet werden, damit sie auch sicher aktiviert werden (alternativ kann man sein Glück als Administrator per „gpupdate /Target:Computer“ versuchen).

Sofern die Option für Windows 10 (1511) fehlt, sind die Gruppenrichtlinientemplates veraltet. In einem extra Artikel beschreibe ich, wie diese aktualisiert werden können. Nach einem Upgrade von Windows 10 RTM zu 1511 muss dies möglicherweise per Hand nachgezogen werden.

Keine Migration vorhandener Bitlocker-Volumes möglich
Neu angelegte Bitlocker-Volumes (=verschlüsselte Laufwerke/Partitionen/Festplatten) erhalten nach aktivieren von Bitlocker den neuen Modus.

Einmal angelegte Bitlocker-Volumes werden nach dem Upgrade von Windows 10 auf 10 (1511) oder dem Ändern der Gruppenrichtlinie jedoch leider nicht automatisch auf die neue Verschlüsselung umgestellt und es besteht keine Möglichkeit zur automatischen Konvertierung.
Da hilft nur das Deaktivieren von Bitlockern, was dem Entschlüsseln des Bitlocker-Volumes entspricht, und die anschließende erneute Verschlüsselung.
Dies geht am einfachsten per Kommandozeile

# manage-bde -off C:

oder durch einen Rechtsklick im Explorer auf das Laufwerk und „Bitlocker deaktivieren“.
Den Status der Entschlüsselung und späteren Verschlüsselung kann man sich auf der Kommandozeile per

# manage-bde -status

anzeigen lassen.

Nach der Entschlüsselung sollte die Anzeige wie folgt aussehen:

# manage-bde -status
 Volume "C:" [WINDOWS]
 [Betriebssystemvolume]

Größe:                        343,44 GB
 BitLocker-Version:            Kein
 Konvertierungsstatus:         Vollständig entschlüsselt
 Verschlüsselt (Prozent):      0,0 %
 Verschlüsselungsmethode:      Kein
 Schutzstatus:                 Der Schutz ist deaktiviert.
 Sperrungsstatus:              Entsperrt
 ID-Feld:                      Kein
 Schlüsselschutzvorrichtungen: Keine gefunden

Nun kann das Laufwerk erneut verschlüsselt werden, wobei sich der Wizard über einen rechtsklick im Explorer auf das Laufwerk und die Auswahl „Bitlocker aktivieren“ empfiehlt. Alternativ kann man in der Systemsteuerung nach „Bitlocker verwalten“ suchen.

Exkurs: Authentifizierungsmöglichkeiten
Die Möglichkeiten der Benutzerauthentifizierung über TPM, TPM mit PIN, ohne TPM aber dafür mit USB-Stick, Passwort oder eine Kombination daraus sind hier ausführlicher beschrieben (Merke: PIN != Passwort. Ein Passwort muss ).
Auf stationären PCs sind TPM oder USB-Stick (möglich ein mini-Stick, der nicht stört und ggfs. gar intern angeschlossen wird) ausreichend, auf einem mobilen Gerät sollte zwingend (am besten zusätzlich) ein Passwort durch den Benutzer eingegeben werden.
Wer einen Yubikey hat, kann darauf ein ultralanges statisches Passwort ablegen und ergänzt um ein vom Benutzer einzugebendes kurzes Teilpasswort eine sehr sichere Authentifizierungsmöglichkeit schaffen, bei der ein gefundener Laptop mitsamt Yubikey für einen Angreifer nutzlos bleibt: Festplattenverschlüsselung mit Bitlocker und Yubikey.

Smartcard: sicher aber die Usability…
Die schöne Variante mit der Smartcard funktioniert leider nicht für die pre-boot-Authentication des Startlaufwerkes, wohl aber für zusätzliche Bitlocker-Volumes. Ein Yubikey NEO kann dabei eine Smartcard ersetzen, hier der Weg per OpenSSL, bequemer geht es per GUI über den Yubikey PIV Manager für Windows (siehe Anleitung ab Seite 7). Im Anschluss muss Bitlocker konfiguriert werden, selbst-signierte Zertifikate statt ausschließlich denen aus einer CA in einem Active-Directory zu akzeptieren (unter \HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\FVE das neue DWORD32 „SelfSignedCertificates“ mit Value=1 anlegen).

Der Wiederherstellungsschlüssel muss unbedingt auf einem externen Laufwerk gesichert oder ausgedruckt werden, damit man bedarfsweise mit einer Rescue Boot-CD, die auf Windows 10 (1511) basieren muss, auf das bitlocker-verschlüsselte Laufwerk zugreifen kann. Diee Option in Microsoft-Account speichern, hinterlegt den Key in OneDrive. Aus Sicherheitsgründen ist davon abzuraten. Falls es bereits zu spät ist, kann der Bitlocker-RecoveryKey aus OneDrive gelöscht und ein neuer erstellt werden.

Bei der erstmaligen Verschlüsselung sollte das „gesamte Laufwerk verschlüsselt“ werden, wenn nur ein Wechsel auf eine stärkere Verschlüsselung durchgeführt wird, kann „nur der verwendete Speicherplatz“ verschlüsselt werden.
Es sollte unbedingt die Option „Bitlocker-Systemüberprüfung ausführen“ gewählt werden, damit man keinen PC produziert, der sich nicht mehr starten lässt.
Nach einem Neustart startet hoffentlich die Bitlocker-Verschlüsselung.
Der Fortschritt lässt sich wie zuvor beschrieben mittels „manage-bde -status“ überprüfen.

PS. Um zu prüfen, ob das Windows 10 Oktober 2015-Update auf Version 1511 wirklich installiert wurde, einfach eine Eingabeaufforderung starten. Dort muss folgende Versionsnummer erscheinen:

# cmd
Microsoft Windows [Version 10.0.10586]