Vor einigen Tagen habe ich einen Blogbeitrag über die Sitzungswiederaufnahme in Nginx gelesen.
In diesem Text behauptet der Autor, dass nginx keine Möglichkeit bietet, den Session-Cache regelmäßig zu leeren. Nach Ablauf von „ssl_session_timeout“ wird die Session zwar nicht mehr genutzt, die Datei liegt aber noch immer auf der Festplatte und könnte von einem Angreifer gelesen werden, weshalb „Forward Secrecy“ an dieser Stelle nutzlos wäre.
Anstatt Session-IDs zu verwenden, schlägt er vor, den Session-Cache zu deaktivieren und Session-Tickets zu verwenden. Dazu muss mindestens einmal am Tag ein „ticket_key“ mit 80 Bytes Zufallszahl erstellt werden.
Ich habe im Internet nach weiteren Informationen gesucht, konnte aber nichts Hilfreiches finden.
F1: Wo befindet sich der Nginx-Sitzungscache und wie kann ich überprüfen, ob sich TLS-Verbindungsdaten (Sitzungen) auf der Festplatte befinden?
F2: Ist es ratsam, Sitzungstickets zu verwenden?
Antwort1
Die erste Frage kann ich nicht beantworten, zur zweiten kann ich aber ein wenig sagen.
Dieser Blogbeitrag enthält einige gute Informationen zu Fehlern mit Sitzungstickets unter TLSv1.2:https://blog.filippo.io/wir-müssen-uber-sitzungstickets-reden/.
Wie Michael sagt, haben beide ihre Probleme und nur wenn Sie TLSv1.3 verwenden (buchstäblich gerade abgemeldetund ist daher zum Zeitpunkt des Schreibens gerade erst in Implementierungen verfügbar) können Sie die TLS-Wiederaufnahme völlig sicher verwenden.
Allerdings sind die Leistungseinbußen bei Nichtverwendung der TLS-Sitzungswiederaufnahme erheblich und meiner Meinung nach sind die Risiken relativ gering (wenn jemand Zugriff auf Ihren Server hat, ist das Spiel meiner Meinung nach vorbei). Daher empfehle ich vorerst, sowohl Sitzungs-IDs als auch Sitzungstickets zu verwenden. Insbesondere, da einige Clients (Safari und IE unter Windows 7 und früher) keine Sitzungstickets unterstützen. Insbesondere Safari hat immer noch viele Benutzer auf Mobilgeräten und Tablets – möchten Sie wirklich alle iOS-Benutzer deutlich verlangsamen?