W2022-ITS

Vorträge

Freitag 14.10. 2022, Rudower Chaussee 25, Haus 3, Raum 3'328 (dritte Etage)

12:15-13:15	Tock (Rust&IoT)	Daniel, Fabrice	pdf
13:15-14:00	Eigener Sync-Server für Firefox (Rust)	Manuel	pdf
14:00-14:30	Pause: Snack & Schnack
14:30-15:30	JavaCard (erste Schritte)	Paul, Tobias, Marvin	pdf
15:30-16:30	Absicherung NFS	Leon, David	pdf
16:30-16:40	Zusammenfassung & Dank	Wolf Müller

Organisatorisches und Anmeldung für IT-Security Workshop 4. bis 14. Oktober 2022

Wenn Sie die unten genannten Themen interessant finden und in den ersten beiden Oktoberwochen Lust und Zeit haben sich damit auseinanderzusetzen, so finden Sie hier den angestrebten Zeitplan sowie die Möglichkeit sich und (optional) ein spannendes eigenes Thema anzumelden.

Themen

JavaCard (erste Schritte)

[Paul, Tobias, Marvin]

Für viele sicherheitskritische Anwendungen werden SmartCards als Sicherheitskern verwendet. Für viele Anwendungsfälle (E-Mail Signatur, QES, nPA, eGK, SIM...) gibt es bereits komplette Lösungen die die Karte als Plattform und eine fertige Anwendung enthalten. Will man jedoch eine eigene SmartCard-Anwendung schreiben, ist oft die Verwendung einer JavaCard und die Erstellung einer eigenen Applikation ein denkbarer Weg. Doch wie geht das konkret? Finden Sie es heraus und versuchen Sie eine eigene Smartcardanwendung in Java zu entwickeln und diese gemäß des Global Platform Standards auf der hoffentlich dann vorhandenen Javacard zu installieren und dann zu verwenden.

Im nächsten Schritt könnte versucht werden, die symmetrischen Schlüssel für OpenVPN durch sichere Hardware auf dem Server zu schützen. Dazu böte es sich an, das "key unwrapping" der symmetrischen clientspezifischen Schlüssel in sicherer Hardware (also auf der JavaCard) auszuführen. In der Initialisierungsphase würden die statischen symmetrischen Schlüssel die mit /usr/sbin/openvpn --genkey tls-crypt-v2-server erzeugt werden,

-----BEGIN OpenVPN tls-crypt-v2 server key-----
8mo8ow6tMvDdLD9eFgWGEAbniRmUbFUY82zcYAxefBhGj5RcKiggEouXVpEjoWnI
e8lM63rE+mmaRPU/TENSuigoa2W1c+iNgAdseLHGn/tvl00xtXNT2hiFEzuNXmpx
MdvNST7vFrbFvnIEBdzgfhkW9qyNVf3vW1h3RoNQk7Q=
-----END OpenVPN tls-crypt-v2 server key-----

in die JavaCard zu importieren. Dann werden damit die zugehörigen Schlüssel für die Clienten erzeugt /usr/sbin/openvpn --genkey tls-crypt-v2-client und gewrappt (also ein HMAC berechnet, sowie der eigentliche AES-Schlüssel mit dem AES-Verschlüsselungsschlüssel des Servers verschlüsselt) wie z.B.:

-----BEGIN OpenVPN tls-crypt-v2 client key-----
2SPJThku9MxJxsoOSAsFTPaVEhBQPBV30FlbTUjOGwvQxsD63BEsnKidHguqeEOy
MvyWGHfH44AYLmfATI1CEphoVnjVJe1psqFzBtOzw+YLgIc+7PEIYRrZv7nOY2L7
sxN/b+NKF/l56BzwSCwCty0Np/rhAd0bhdU7pkLXtzkk1UiGAVm9pBcw6YWqIGhd
M5tW3lRFfgopcyH5XGglEbDWr/DOzjhwa79EXkgEIcPsGmEOOO17iNdE5szusrMV
dup9KCtzu9NQwMqalyuHOb6LpzdpVYZc7iRUBAPK9uzez3hhVNY4TNXzs9bJi17T
VMpZ/NoNKvuBRyxsnTGc/tXLRkgge9wsamqn36hpXkLMau5inFFZTyfZA2d146Nk
xzBY/eshaF00PhHyMJckP5yadeokuDx2kVM5xRk2/0o/QzBRh8vkweja07Q017tf
oUFQK1yS8FOa/oiiUGA5SClK1v/rqz34q/AXjGNgXZEvUizFVEIFZuWAFOlP4ZCT
GcsSOovdN1SIxcCMHkovICssx09i/13SySLxC3IaYQ7pFD5E34ZDuThGQyouPJXk
5moSLCn5+heiT037W8Dt0JY8zp5OCGXfd65LuXX3x15cUsVU5LUsogYCnj85Idc5
XhVD8itPZFVnmWhSKFa7LVbJCcsWZ8nagRhPnUmYaqTBQLEhmBCDw0CrecpAnGp/
psdBQSOB2TAz7vlVNCk8y9R8ChRqwoDenQEr
-----END OpenVPN tls-crypt-v2 client key-----

In der operativen Phase liefern die Clienten beim Verbindungsaufbau ihre jeweiligen gewrappten Schlüssel dann wieder ein und das komplette unwrapping, also Verifikation des HMAC + Entschlüsselung soll dann idealerweise im Applet auf der JavaCard passieren, so dass die statischen Serverschlüssel durch die SmartCard geschützt bleiben. Details zum OpenVPN: KeyWrapping sind in der Linkliste zu finden.

Links:

• JavaCard Plugin für Eclipse
• GP Shell
• GlobalPlatformPro
• JavaCardBuyersGuide
• NXP J3H145 Eigenschaften
• OpenVPN: KeyWrapping

Mentor: Wolf Müller

WireGuard@Informatik

WireGuard ist ein auf modernen kryptografischen Algorithmen basierendes, in den Linux-Kernel gut integriertes und sehr performantes VPN. Die Konfiguration für einzelne Peers ist sehr übersichtlich. Jedoch ist es nicht vorgesehen, dynamische IP-Adressen nach etablierter Verbindung zu nutzen, sondern diese werden direkt in der Konfigurationsdatei gesetzt. Das reduziert die Komplexität und erhöht die Geschwindigkeit. Wie könnte aber eine komfortable Konfiguration für sehr viele Nutzer (die potenziell auch noch mehrere Geräte haben) aussehen? Gibt es hier bestehende Ansätze, wie (z.B. über einen Webdienst für authentisierte Institutsmitglieder) Konfigurationsdateien (die vielleicht auch einen QR-Code beinhalten) für die Geräte generiert und an die berechtigten Nutzer ausgeliefert werden, so dass potenziell alle Benutzer all Ihre Geräte konfliktfrei mit dem VPN verbinden können? Auch hierbei ist es sicherlich sinnvoll bereits über eine hohe Sicherheit gegen zukünftige Angreifer mit Quantencomputer nachzudenken man:

"PresharedKey — a base64 preshared key generated by wg genpsk. Optional, and may be omitted. This option adds an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance."

Ein interessantes Projekt könnte vielleicht wg-dynamic sein. Aber suchen Sie getrost nach besseren Ideen oder Ansätzen.

Links:

• WireGuard
• Protokoll
• wg-dynamic
• wg-dynamic: Idee

Mentor: Wolf Müller

OpenVPN: performant & sicher

OpenVPN ist ein sehr etabliertes und auch historisch gewachsenes VPN, welches viele Konfigurationsmöglichkeiten bietet. Das ist einerseits natürlich fantastisch, andererseits auch eine Herausforderung. Im Vergleich zu WireGuard, welches aufgrund seiner schlanken und "state of the art"-Kryptografie bereits Einzug in den Kernel gefunden hat, ist OpenVPN häufig signifikant langsamer und nicht immer sicher konfiguriert.

Können Sie hier weiterhelfen?

• So wäre es wünschenswert bereits jetzt etwas gegen Angreifer zu unternehmen, die den VPN-Verkehr aufzeichnen und später mit einem Quantencomputer entschlüsseln wollen. Weiterhin ist es wünschenswert, die Sicherheitsreserven zu erhöhen. Da Sie bei einer Authentifizierung mittels TLS-Client-Zertifikaten eine eigene PKI verwenden können, bietet es sich an, hier ECC-Schlüssel mit >400 Bit zu wählen. Weiterhin sind die Optionen --tls-crypt oder besser --tls-crypt-v2 interessant. Versuchen Sie, einen schnellen und sicheren TLS-Handshake zur Authentifizierung und Schlüsselableitung zu etablieren.
• Im zweiten Schritt müssen dann noch die eigentlichen Nutzdaten ver-/entschlüsselt werden. Um dies performant und dennoch sicher umzusetzen, können Sie zum einen versuchen, die Hardwareunterstützung für AES zu aktivieren. Aber selbst wenn Ihnen das gelingt, wird WireGuard wahrscheinlich immer noch weitaus performanter sein. Das Problem ist, dass bislang bei OpenVPN in der Regel zwischen Versenden und Empfang und der Ver-/Entschlüsselung ein aufwendiger Wechsel zwischen User- und Kernelspace erfolgt, der in WireGuard nicht erforderlich ist. Doch auch hier gibt es Hoffnung in Gestalt von "OpenVPN Data Channel Offload", welches unter Linux ein Kernelmodul "openvpn-dco" nutzt um hier die Performance deutlich zu steigern. Konkret werden die AEAD Verschlüsselungen AES-GCM-256, AES-GCM-128 und CHACHA20POLY1305 unterstützt.

Motivation: Bei meinem OpenVPN unter Windows 10 hat sich der Downstream von 48 Mbit/s auf 182 Mbit/s (exemplarisch, nicht repräsentativ) verbessert.

Links:

• OpenVPN DCO
• OpenVPN git für openvpn 2.6.0
• git für ovpn-dco-win
• Windows Binary
• BSI TR-02102-2

Mentoren: Wolf Müller

Eigener Sync-Server für Firefox (Rust)

[Manuel]

Die Authentisierung mittels (Name, Passwort) wird nach wie vor von vielen Diensten im Internet verwendet. Der Nutzer ist bei der Vielzahl der Dienste schlichtweg überfordert, sich all diese zu merken. Als Konsequenz wurden Lösungen wie Single Sign On oder Open ID vorgeschlagen. In der Post-Snowden-Ära gibt es jedoch Bedenken, die Authentisierung an eine dritte Partei auszulagern, da diese auch im Namen des legitimen Nutzers ohne diesen eine erfolgreiche Authentisierung bewerkstelligen könnte.

Einen anderen Ansatz bieten Passwortmanager. Hier wird dem Benutzer angeboten, mit Hilfe (eines hoffentlich starken Masterpassworts) den Zugang zu den Authentisierungsdaten für die einzelnen Dienste abzusichern. Die Referenzdaten dazu können beispielsweise lokal verschlüsselt gespeichert werden. Allerdings ist es ggf. wünschenswert, den Passwortmanager auch auf verschiedenen Geräten nutzen zu können. Eine Lösung die auch die Synchronisierung zwischen verschiedenen Geräten vorsieht, ist "Firefox Sync" was auch direkt im Firefox ohne zusätzliche Plugins oder Erweiterungen nutzbar ist.

Jedoch werden die (zwar verschlüsselten) Referenzdaten auf einem zentralen Server gespeichert. Hier wäre es wünschenswert, eine Lösung umzusetzen, die eine Speicherung auf unserem eigenen Informatik-Server zulässt.

Links:

• Run your own Sync-1.5 Server
• Neue Implementierung in RUST
• Run your own Firefox Accounts Server
• Ansible
• Eigener Sync-Server für Firefox

Mentoren: Wolf Müller, Robert Sombrutzki

Absicherung NFS

[Leon, David]

Bei NFS-Freigaben sind hohe Anforderungen an die Integrität des NFS-Clienten gestellt, da allein dieser über die Einhaltung der im exportierten Dateisystem gesetzten Rechte entscheidet. Daher ist es essenziell, dass sich bei dem mountenden Clienten wirklich um den beabsichtigten legitimen Rechner handelt. Der Normalfall ist eine simple Überprüfung der IP-Adresse, die in der /etc/exports angegeben ist.

Untersuchen Sie, welche Verbesserungen hier möglich sind und welchen Aufwand, welche Komplexität die von Ihnen erarbeitenden Lösungen haben. Die verlässlichere Prüfung könnte auf verschiedenen Schichten angesetzt werden. Wünschenswert wäre zumindest eine starke und persistente Authentisierung (z.B. basierend auf privaten Schlüsseln). Denkbar wäre eine Absicherung über SSL/TLS vielleicht mit einem performanten Modus mindestens zur Integritätssicherung (TLS_RSA_WITH_NULL_SHA, TLS_RSA_WITH_NULL_SHA256, ..., TLS_RSA_WITH_AES_128_GCM_SHA256), womit zumindest aktive Angriffe unterbunden werden könnten. Alternativ könnte auch die Verwendung von NFS mit Kerberos helfen. Betrachten Sie das Verhältnis von Sicherheit und Performance.

Ein interessanter Ansatz könnte eine Authentisierung auf Netzwerkebene gemäß 802.1X mit Bindung der verwendeten Schlüssel an die Hardware sein. Daher wäre es nett, wenn man die Server mit 802.1X über Radius mit EAP-TLS (also Client-Zertifikate) authentisiert. Die Idee, ist diese in das TPM (Version TPM 2.0) zu legen, bzw. sie dort zu erzeugen und dann den zugehörigen öffentlichen Schlüssel als CSR rauszugeben und zu signieren.

Links:

• 802.1X
• IEEE 802.1X mit Zertifikaten
• EAP-TLS@TPM2
• stunnel
• chiphers
• Startpunkt

Mentoren: Wolf Müller, Robert Sombrutzki

SIKE: Los, stop, schade!

Lange Zeit war SIKE "Supersingular Isogeny Key Encapsulation" ein heißer Kandidat im NIST-Wettbewerb für quantensichere Kryptoverfahren hier insbesondere für den asymmetrischen Diffie-Hellmann-artigen Schlüsselaustausch. Insbesondere interessant schienen die moderaten Längen der auszutauschenden Nachrichten, welche für Overhead in Protokollen wie TLS wichtig sind. Lange Zeit wurde der optimierte Algorithmus als sicher angesehen und schaffte es bis auf die Kandidatenliste für die vierte Runde. Dann wurde jedoch gezeigt, dass der private Schlüssel recht effizient (auf einem Laptop in einer Stunde) aus der Beobachtung von SIDH wiederhergestellt werden kann.

Versuchen Sie (im Groben) zu verstehen, wie der Algorithmus funktioniert. Versuchen Sie, die Idee des Angriffs nachzuvollziehen. Probieren Sie an einem eigenen Beispiel den Angriff mithilfe von SageMath.

... und jetzt die eigentliche Herausforderung: Versuchen Sie uns das im Vortrag zu erklären ;-).

Links:

• Golem
• SIKE
• NIST:PQC:4. Runde Kandidaten
• An efficient key recovery attack on SIDH
• PoC in Magma
• SIDH Key Recovery Attack in SageMath
• SageMath

Mentor: Wolf Müller

VaultProject

An vielen Stellen werden Credentials für eine Authentisierung oder Ver-/Entschlüsselung benötigt. So können im Institut für Praktika oder Forschung VMs aufgesetzt werden und die jedoch zur Nutzung Passworte oder private SSH-Schlüssel benötigen. Wie können diese vorbereitet und sinnvoll an die berechtigten Nutzer ausgegeben oder verwaltet werden. Wenn ein verschlüsseltes Backup angelegt werden soll, wäre es vielleicht wünschenswert, dass der Nutzer ein Passwort setzt oder Schlüssel generiert. Doch was passiert, wenn der Nutzer dies vergisst? Vielleicht wäre es (zumindest im Sinne der Verfügbarkeit) eine Idee, einen zusätzlichen Weg zur entschlüsselten Wiederherstellung mit vorzusehen? Hier könnte eine Idee eine Wiederherstellung im "virtuellen Mehraugenprinzip für Administratoren" sein, also mehrere Administratoren müssen kooperieren, indem sie Ihre Keyshares zusammenbringen, um in dieser Situation dennoch eine Entschlüsselung des Backups zu ermöglichen. Aus Anwendersicht wünscht man sich natürlich volle Transparenz, also insbesondere im Vorhinein die Information unter welchen Bedingungen eine Entschlüsselung möglich ist. Ein Startpunkt welcher hinsichtlich seiner Möglichkeiten untersucht werden könnte, wäre "Vault". Versuchen Sie in den zwei Wochen sowohl den Möglichkeiten als auch den potenziellen Risiken eines solchen Ansatzes auf den Grund zu gehen.

Links:

• Vault
• Binaries
• Erste Schritte

Mentor: Robert Sombrutzki, Wolf Müller

Tock (Rust&IoT)

[Daniel, Fabrice]

Tock ist ein Betriebssystem für Embeddedgeräte, welches helfen soll IoT-Anwendungen eine sicherere Plattform zu bieten. Die Idee ist verschiedene Anwendungen (ggf. verschiedener Hersteller), die sich nicht vertrauen auf einer gemeinsamen Plattform zu betreiben. Schutz soll vor potenziell bösartigen Anwendungen als auch vor Gerätetreibern geboten werden. Dazu sind Kernel und Gerätetreiber in Rust geschrieben. Zusätzlich nutzt Tock Speicherschutzeinheiten, um Anwendungen und den Kernel möglichst effektiv von einander zu isolieren.

Wir freuen uns, dass knapp vor dem Workshopbeginn ein Hail "open source IoT development board" eingetroffen ist und nun von Ihnen ausprobiert werden kann. Versuchen Sie, mit dem Board zu kommunizieren und vielleicht eine erste Applikation dafür zu finden, zu kompilieren, zu installieren oder schließlich selbst zu programmieren. Berichten Sie uns über Ihre Erfahrungen und gewonnenen Erkenntnisse.

Links:

• Tock
• Hail

Mentor: Wolf Müller, Dorian Weber

NTLM Relaying

NTLM Relaying ist eine Standardklasse von Angriffen, die bei Zugriffen auf das interne Netz möglich ist. Das Grundproblem ist, dass NTLM an sich keinen Schutz vor Relay-Angriffen liefert. Daraus lassen sich recht komplexe Angriffsketten bauen (z.B. der PrivExchange Angriff, bei dem das hochprivilegierte Computerkonto des Exchange-Servers weitergeleitet wird), aber auch vergleichsweise einfachere Angriffe sind häufig noch möglich. Es existieren zwei Standard-Tools für Relaying Angriffe:

• Responder und MultiRelay
• Impacket und NTLMRelayX

Die Projektaufgabe ist es zunächst den Angriff zu verstehen und einen Laboraufbau zu erstellen um diesen nachzuvollziehen. Anschließend können kleine Erweiterungen für die oben genannten (in Python geschriebenen) Werkzeuge programmiert werden:

• MultiRelayX erlaubt das Filtern von weiterzuleitenden Nutzern mittels des Parameters -u. Hier wäre es nützlich, wenn Wildcards unterstützt würden (z.B. -u adm*). Der Aufwand hierfür sollte gering sein.
• NTLMRelayX fehlt bisher ein entsprechendes Filter-Feature. Dieses nachzurüsten sollte mit mittlerem Aufwand möglich sein.
• SMB Relaying zielt meist darauf ab, Code auf dem Zielsystem auszuführen (über Zugriff auf den \\IPC$ Share auf dem Ziel und das Erzeugen und Starten eines Dienstes auf diesem Weg). Dies benötigt allerdings administrative Rechte auf dem Ziel. Ein Feature, welches es erlaubt, stattdessen im Kontext der weitergeleiteten Verbindung die vorhandenen SMB-Shares zu enumerieren und zuzugreifen (z.B. über das in Impacket enthaltene smbclient.py), wäre häufig sehr nützlich. Der Aufwand dieses Feature zu implementieren dürfte hoch sein.

Mentoren: Wolf Müller

WebAuthn / FIDO2

WebAuthn ist ein browserübergreifender Standard zur Authentisierung im Web. Die meisten modernen Browser Firefox, Chrome, Safari, Opera unterstützen die Verwendung von Sicherheitstoken zur Authentisierung gegenüber von besuchten Webdiensten ohne die Installation von weiterer Software oder Treibern. Während auch in WebAuthn aufgenommenen Standard FIDO-U2F ursprünglich dazu verwendet wurde, um eine Nutzername/Passwort-basierte Authentisierung durch die Nutzung eines universellen zweiten Faktors gegen automatisierte Angriffe entfernter Angreifer zu härten, ist es mit FIDO2 möglich, sich ganz ohne die Verwendung von Passwörtern zu authentisieren.

Probieren Sie es aus! Wo kann man sich mit FIDO2 authentisieren? (Interessante Webdienste). Versuchen Sie, einen Web-Service mit FIDO2-Authentisierung aufzusetzen! Obwohl WebAuthn/FIDO2 primär zur Nutzung mit Webdiensten entworfen wurde, sind ggf. auch andere Nutzungen (lokales Login, Windows Hello, Linux PAM, SSH, SCP, ...) denkbar. Was geht (schon)?

• WebAuthn
• Video
• FIDO2
• Security Key
• WireShark-dissector

Mentor: Wolf Müller

DNSSEC@Informatik

Eigentlich wird schon lange über die sichere Variante von DNS gesprochen. Dennoch ist die HU und auch unser Institut noch nicht über DNS-SEC von außen validierbar. Für die Domain hu-berlin.de hat das CMS schon Grundlagen geschaffen, aber die Einbindung nach oben ist noch nicht erfolgt.

Erarbeiten Sie ein Konzept und versuchen Sie, exemplarisch einige Schritte umzusetzen. Welche Software wird benötigt, um eine Zone zu signieren. Wie können Schlüssel sicher aufbewahrt werden. Was ist mit dynamischen Einträgen?

Welche Vorteile bietet DNSSEC bei erfolgreicher Validierung? Mit DANE können auch weitere Felder über DNSSEC ausgeliefert werden. Denkbar wäre zum Beispiel auch SMTP mithilfe von DANE stärker zu machen oder auch SSH-Fingerprints von Informatikrechnern automatisch ausliefern zu lassen und so Trust-on-First-Use oder das manuelle Vergleichen mit unserer Liste zu überwinden.

Links:

• Heise: DNSSEC&DANE
• Golem
• Heise: aktuell
• Erfahrungen Uni Greifswald
• Signaturverfahren

Mentoren: Robert Sombrutzki, Wolf Müller

Absicherung KNXD

Der Zugriff auf KNX-Komponenten im Heimnetzwerk (KNX-Bus) kann mithilfe der Open Source Software knxd vom Netzwerk erfolgen. Sinnvollerweise wird der Dienst so konfiguriert, dass er nur im Heimnetzwerk (also in der Regel in einem privaten Netzwerk) verfügbar ist. Dennoch eröffnet sich damit die Möglichkeit, ohne eine weitere Authentisierung auf KNX-Komponenten zuzugreifen. So könnte ein bösartiges Gerät (Fernseher, Staubsauger, Smarter Lautsprecher) die mit meinem Heim-IP-Netzwerk verbunden sind, diese Möglichkeit ausnutzen, um Zugriff auf beispielsweise die Heizungssteuerung oder Türschlösser zu erlangen. Wünschenswert wäre hier eine stärkere Authentisierung. Ideen/Priobleme:

• TLS mit Clientzertifikaten statt TCP-Socket?
• Geht da was mit Wireguard?
• TLS könnte in den Code von knxd integriert werden.
• ETS 5 kann nicht modifiziert werden, geht da was mit stunnel?
• Alternativ könnte man auch versuchen, eine Authentisierung gemäß KNX-IP-Secure Standard umzusetzen, was aber eher für eine Masterarbeit geeignet ist.

Links:

• KNXD (git)
• ETS (KNX Konfigurationssoftware
• KNXD_Tutorial
• OpenHAB_Tutorial

Mentoren: Wolf Müller

Sicherer und schneller SSL/TLS-Handshake

Nach den Enthüllungen von Edward Snowden haben wir verstanden, warum authentische und vertrauliche Kommunikation wichtig ist. Naiv betrachtet, könnte man denken, es ist ausreichend "s"-Protokolle wie https, imaps, pops ... zu verwenden und alles ist gut. Es ist in Praxis jedoch wesentlich komplexer eine unter dem gegenwärtigen Angreifermodell hinreichend starke SSL/TLS-Verbindung zu erzwingen.

In der Vergangenheit wurden zahlreiche teils sehr originelle Angriffe auf SSL/TLS entwickelt, die Seitenkanäle oder auch Probleme im Protokollentwurf oder der Implementierung adressieren. Weiterhin ist es wünschenswert, "forward secureness" zu nutzen, da auch nicht für jeden Server der private Schlüssel immer privat bleiben muss.

Versuchen Sie für einen aktuellen SSL/TLS-Server (z.B. Apache oder NGINX) eine möglichst sichere Konfiguration zu erstellen. Eine gute Orientierung bietet die Technische Richtlinie "BSI TR-02102-2" Behalten Sie dabei auch die Performance für den Handshake im Auge:

• Könnte die Nutzung von ECC hier weiter helfen?
• DH oder ECDH?
• Was muss ein sorgsamer Client alles prüfen, wie kann ihn der Server dabei unterstützen?
  • Kann man die gesamte Zertifikatskette auch ECC-signiert bekommen?
  • Was ist OCSP-stapling
  • Was bringen die einzelnen Maßnahmen?
• Kann Kernel-Level-TLS helfen?
• Wie kann eventuell die Hardwareunterstützung für AES (oder gar ChaCha20) aktiviert werden?

Links:

• BSI TR-02102-2
• Angriffe auf SSL/TLS
• (Web-)Server Test
• HOWTO OCSP stampling
• Kernel TLS

Mentor: Wolf Müller