QSslKeyingMaterial Class

Ausführliche Beschreibung

QSslKeyingMaterial stellt eine Anforderung an Schlüsselmaterial dar, das mithilfe des TLS-Exporter-Mechanismus aus einer bestehenden TLS-Verbindung abgeleitet wurde.

Der Exporter-Mechanismus ist in RFC 5705 für TLS 1.2 und frühere Versionen sowie in RFC 8446 für TLS 1.3 definiert. Er ermöglicht es Anwendungen, kryptografisch getrenntes Schlüsselmaterial aus der TLS-Sitzung abzuleiten, ohne die Verkehrsschlüssel der Sitzung offenzulegen.

Jedes QSslKeyingMaterial-Objekt gibt Folgendes an:

• eine Exporter-Kennung, die den Zweck des abgeleiteten Schlüsselmaterials angibt
• einen optionalen Kontextwert, der das Schlüsselmaterial an anwendungsspezifische Daten bindet
• die gewünschte Größe des exportierten Schlüsselmaterials

Das eigentliche Schlüsselmaterial wird vom TLS-Backend nach einem erfolgreichen Handshake abgeleitet und kann mit ` value()` ausgelesen werden.

QSslKeyingMaterial-Objekte werden in der Regel vor dem Aufbau einer TLS-Verbindung über ` QSslConfiguration::setKeyingMaterial()` konfiguriert.

Beispiel: Deterministischer Export auf Client und Server

// Both client and server configure the same label and optional context
QSslKeyingMaterial keying("session-label", 32, "app-specific-context");

// After the TLS handshake completes get data from QSslConfiguration.
QByteArray derived = sslConfiguration().takeKeyingMaterial(keying)->value();

// Both client and server will obtain the same 'derived' bytes
// even though they each performed the derivation independently.
use(derived);

Sicherheitshinweise

Exportiertes Schlüsselmaterial ist ein Geheimnis. ` QByteArray ` ist ein Copy-on-Write-Container, sodass sich jedes `QSslKeyingMaterial`-Objekt, das einen Wert enthält, einen gemeinsamen Puffer teilt und das Geheimnis so lange im Speicher verbleibt, wie eines dieser Objekte existiert. Eine Anwendung, die sicherstellen muss, dass sie die einzige verbleibende Referenz hält, muss die Qt-internen Referenzen explizit freigeben.

Nach einem erfolgreichen Handshake befindet sich der Wert an genau einer Stelle innerhalb von Qt: dem Eintrag „QSslKeyingMaterial“ in der internen „ QSslConfiguration “ des Sockets. Jedes von „ QSslSocket::sslConfiguration()“ zurückgegebene „ QSslConfiguration “ ist eine eigenständige Kopie dieser Konfiguration, die sich den Puffer des Werts mit ihr teilt.

Beide Überladungen von ` QSslConfiguration::takeKeyingMaterial()` übergeben die Werte, anstatt sie gemeinsam zu nutzen: Was sie zurückgeben, enthält die einzige Referenz auf den Wert, und die Einträge, die sie in der Konfiguration hinterlassen, in der sie aufgerufen wurden, sind wertlose ` clones`. Kopieren Sie den Wert mit ` value()` aus dem zurückgegebenen Objekt heraus und lassen Sie das Objekt selbst aus dem Gültigkeitsbereich verschwinden; schreiben Sie anschließend die Konfiguration zurück in den Socket: Dadurch wird der Eintrag des Sockets mit dem wertlosen Eintrag überschrieben, wodurch die letzte Referenz, die Qt hält, entfernt wird.

QSslConfiguration config = socket->sslConfiguration();

// Copy the value out of the temporary that owns it, and let it die:
QByteArray secret = config.takeKeyingMaterial(request)->value();

// Overwrite the socket's copy with the entry left behind, which has no value:
socket->setSslConfiguration(config);

Die folgenden Kopien liegen außerhalb der Kontrolle des Sockets und müssen separat behandelt werden:

• Jede andere Kopie von ` QSslConfiguration `, die die Anwendung noch hält, einschließlich einer, die in einem ` QNetworkRequest ` gespeichert oder mit ` QSslConfiguration::setDefaultConfiguration()` installiert wurde. Das Entnehmen des Werts aus einer Kopie hat keine Auswirkungen auf die anderen.
• Eine Konfiguration, die nie an den Socket zurückgeschrieben wurde. Das Abrufen der Werte aus einem ` QSslConfiguration ` entfernt nur diese Kopie der Konfiguration; der Socket behält seine eigene, bis er die wertlosen Einträge erhält.
• Jede von der Anwendung selbst erstellte Kopie von `QSslKeyingMaterial`. Verwenden Sie ` clone()` (), wenn eine Kopie einer Anforderung ohne deren Wert benötigt wird.

Der Socket verwirft die Werte außerdem, wenn er einen neuen Handshake startet – da seine Einträge dann auf wertlose Klone zurückgesetzt werden – sowie bei seiner Zerstörung. Beides ersetzt nicht den oben genannten expliziten Schritt für einen Socket, der aktiv bleibt.