Fortschritte im Bereich des Quantencomputings gefährden die kryptografischen Mechanismen, die seit Langem von TLS verwendet werden. Google geht davon aus, dass die Sicherheit der asymmetrischen Kryptografie, die in TLS verwendet wird, bereits 2029 durch Quantencomputer gebrochen werden könnte, wenn die Forschung im aktuellen Tempo voranschreitet.
Um dieses Risiko zu minimieren,unterstützen Google Cloud Load-Balancer Post-Quanten-Schlüsselaustausch, der den theoretischen Fähigkeiten von Quantencomputern widerstehen soll. Diese Algorithmen wurden vom National Institute of Standards and Technology (NIST) entwickelt und geprüft. Ihre Verwendung in TLS entspricht den Standards, die von der IETF entwickelt werden.
Weitere Informationen finden Sie unter Post-Quanten-Kryptografie in Google Cloud.
Wie Quantencomputer die TLS-Sicherheit gefährden
Kryptografisch relevante Quantencomputer werden Angriffe auf zwei kritische Komponenten der TLS-Sicherheit ermöglichen: Schlüsselaustausch und Authentifizierung.
Angriffe auf den Schlüsselaustausch
Kryptografisch relevante Quantencomputer können die während des TLS-Handshakes verwendeten Algorithmen für den Schlüsselaustausch knacken. Dadurch werden die symmetrischen Schlüssel aufgedeckt, mit denen TLS-Sitzungen verschlüsselt werden, und der Traffic der Anwendungsebene wird im Klartext offengelegt. Das gilt auch für TLS-Verbindungen, bei denen Perfect Forward Secrecy-Schlüsselaustauschverfahren wie ECDHE verwendet werden. Ein Angreifer, der heute eine vollständige TLS-Sitzung aufzeichnet, könnte sie sogar Jahre später entschlüsseln, wenn Quantencomputer verfügbar sind. Dies wird als Harvest Now, Decrypt Later-Angriff bezeichnet.
Angriffe auf die Authentifizierung
Kryptografisch relevante Quantencomputer können die in TLS-Zertifikaten oder Zertifizierungsstellen verwendeten Schlüssel knacken, sodass ein Angreifer fälschlicherweise die Identität eines Clients oder Servers behaupten kann. In Kombination mit einem Man-in-the-Middle-Angriff könnte ein Angreifer so den Inhalt von TLS-verschlüsselten Sitzungen sehen und manipulieren. Im Gegensatz zu Angriffen auf den Schlüsselaustausch können Angriffe auf die Authentifizierung nicht nachträglich auf aufgezeichneten Traffic angewendet werden. Angriffe auf die Authentifizierung stellen jedoch eine erhebliche Bedrohung für die Integrität der Webauthentifizierung dar.
Symmetrische Verschlüsselungen sind nicht gefährdet
Die symmetrischen kryptografischen Chiffren wie AES-128, AES-256 und ChaCha20, die zum Verschlüsseln von TLS-Sitzungen verwendet werden, sobald der Handshake und die Authentifizierung abgeschlossen sind, sind durch Quantencomputer nicht gefährdet.
Post-Quanten-Schlüsselaustausch
Um das Risiko von „Harvest Now, Decrypt Later“-Angriffen zu minimieren, empfehlen wir, den Post-Quanten-Schlüsselaustausch für Verbindungen zwischen Clients und Load Balancern zu aktivieren.
Der Post-Quanten-Schlüsselaustausch wird nur für Frontend-TLS-Verbindungen unterstützt, d. h. für Verbindungen zwischen dem Client und dem Load Balancer.
Der Post-Quanten-Schlüsselaustausch kann für die folgenden Load Balancer aktiviert werden:
- Globale externe Application Load Balancer
- Klassische Application Load Balancer
- Regionale externe Application Load Balancer
- Regionsübergreifende interne Application Load Balancer
- Regionale interne Application Load Balancer
- Globale externe Proxy-Network Load Balancer
- Klassische Proxy-Network Load Balancer
X25519MLKEM768 ist die spezielle Form des Post-Quanten-Schlüsselaustauschs, die in Google Cloud Load-Balancern unterstützt wird. Dies ist eine hybride Methode für den Schlüsselaustausch, die sowohl durch klassische als auch durch Post-Quanten-Kryptografie gesichert ist.
Wenn der Post-Quanten-Schlüsselaustausch aktiviert ist, verwendet der Load Balancer ihn, wenn er eine Verbindung zu Clients herstellt, die die Unterstützung für TLS 1.3 und X25519MLKEM768 ankündigen. Verbindungen zu Clients, die TLS 1.3 oder X25519MLKEM768 nicht unterstützen, sind davon nicht betroffen.
Wenn der Post-Quanten-Schlüsselaustausch aktiviert ist, verwendet das Lastenausgleichsmodul ihn, wenn ein verbindender Client die Unterstützung für TLS 1.3 und den X25519MLKEM768-Schlüsselaustauschmechanismus ankündigt. Verbindungen von Clients, die TLS 1.3 oder X25519MLKEM768 nicht unterstützen, sind davon nicht betroffen.
Post-Quanten-Schlüsselaustausch aktivieren
Sie können den Post-Quantum-Schlüsselaustausch auf Ihrem Load-Balancer aktivieren, indem Sie die Einstellung post-quantum-key-exchange in einer SSL-Richtlinie verwenden. Dazu können Sie entweder eine neue SSL-Richtlinie an Ihren vorhandenen TargetHttpsProxy oder TargetSslProxy anhängen oder eine bereits angehängte SSL-Richtlinie ändern.
Weitere Informationen zum Erstellen von SSL-Richtlinien mit der Einstellung für den Post-Quantum-Schlüsselaustausch finden Sie unter SSL-Richtlinien erstellen.
Wir empfehlen, den Post-Quanten-Schlüsselaustausch jetzt zu aktivieren, da er sofortigen Schutz vor „Harvest Now, Decrypt Later“-Angriffen bietet. Bei korrekt implementierten Clients sollten keine Probleme auftreten. Wenn Ihre Clientanwendung jedoch nicht kompatibel ist, können Sie post-quantum-key-exchange auf DEFERRED festlegen. So können Sie die Aktivierung des Post-Quanten-Schlüsselaustauschs bis Oktober 2027 verzögern und haben Zeit, Ihre Anwendung kompatibel zu machen.
Einführung des Post-Quanten-Schlüsselaustauschs
Da die Sicherheit, die durch den Post-Quanten-Schlüsselaustausch geboten wird, wichtig ist, wird Google Cloud ab Oktober 2026 standardmäßig aktiviert. Dies betrifft Load-Balancer, denen keine SSL-Richtlinie zugewiesen ist oder die eine SSL-Richtlinie ohne Post-Quanten-Schlüsselaustausch verwenden. Bei Bedarf können Sie die Aktivierung des Post-Quanten-Schlüsselaustauschs mit der Einstellung DEFERRED bis Oktober 2027 aufschieben.
Die folgende Zeitachse zeigt die geplante Einführung der Unterstützung des Post-Quanten-Schlüsselaustauschs für Load Balancer.
| Zeitachse | Status des Post-Quanten-Schlüsselaustauschs |
|---|---|
| Jetzt | Standardmäßig deaktiviert, nur aktiviert, wenn auf ENABLED eingestellt |
| Nach Oktober 2026 | Standardmäßig aktiviert, deaktiviert, wenn auf DEFERRED gesetzt |
| Nach Oktober 2027 | Immer aktiviert |