QSslKeyingMaterial Class

Description détaillée

QSslKeyingMaterial représente une requête de matériel de chiffrement dérivé d'une connexion TLS établie à l'aide du mécanisme d'exportation TLS.

Le mécanisme d’exportation est défini dans la RFC 5705 pour TLS 1.2 et les versions antérieures, et dans la RFC 8446 pour TLS 1.3. Il permet aux applications de dériver du matériel de chiffrement cryptographiquement distinct de la session TLS sans exposer les clés de trafic de la session.

Chaque objet QSslKeyingMaterial spécifie :

• un libellé d’exportateur identifiant la finalité du matériel de chiffrement dérivé
• une valeur de contexte facultative liant le matériel de chiffrement à des données spécifiques à l’application
• la taille souhaitée du matériel de chiffrement exporté

Le matériel de chiffrement proprement dit est dérivé par le backend TLS après une négociation réussie et peut être lu à l’aide de la fonction ` value()`.

Les objets `QSslKeyingMaterial` sont généralement configurés via la fonction ` QSslConfiguration::setKeyingMaterial()` avant l'établissement d'une connexion TLS.

Exemple : exportation déterministe sur le client et le serveur

// 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);

Considérations de sécurité

Le matériel de chiffrement exporté est un secret. ` QByteArray ` est un conteneur de type « copy-on-write » ; ainsi, tous les objets `QSslKeyingMaterial` contenant une valeur partagent un même tampon, et le secret reste en mémoire tant que l’un de ces objets est actif. Une application qui doit garantir qu’elle détient la seule référence restante doit libérer explicitement les références internes à Qt.

Une fois la négociation d'identification réussie, la valeur réside à un seul et unique endroit au sein de Qt : l'entrée QSslKeyingMaterial dans l'QSslConfiguration interne du socket. Chaque objet QSslConfiguration renvoyé par la fonction QSslSocket::sslConfiguration() est une copie indépendante de cette configuration, partageant le tampon de la valeur avec celle-ci.

Les deux surcharges de la fonction ` QSslConfiguration::takeKeyingMaterial()` transmettent les valeurs au lieu de les partager : ce qu’elles renvoient contient la seule référence à la valeur, et les entrées qu’elles laissent derrière elles dans la configuration sur laquelle elles ont été appelées sont des ` clones` vides de sens. Copiez la valeur hors de l'objet renvoyé à l'aide de ` value()` et laissez l'objet lui-même sortir de la portée, puis réécrivez la configuration dans le socket : cela écrase l'entrée du socket par celle sans valeur, supprimant ainsi la dernière référence détenue par Qt.

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);

Les copies suivantes échappent au contrôle de la socket et doivent être traitées séparément :

• Toute autre copie d’ QSslConfiguration que l’application conserve encore, y compris celles stockées dans un QNetworkRequest ou installées avec QSslConfiguration::setDefaultConfiguration(). Retirer la valeur d’une copie n’affecte pas les autres.
• Une configuration qui n’a jamais été réécrite dans le socket. Extraire les valeurs d’une copie ` QSslConfiguration ` ne supprime que cette copie de la configuration ; le socket conserve la sienne jusqu’à ce qu’on lui transmette les entrées vides.
• Toute copie de QSslKeyingMaterial créée par l’application elle-même. Utilisez clone() lorsqu’une copie d’une requête est nécessaire sans sa valeur.

Le socket supprime également les valeurs lorsqu’il entame une nouvelle négociation de connexion, car ses entrées sont alors réinitialisées en clones sans valeur, ainsi que lorsqu’il est détruit. Aucune de ces deux situations ne remplace l’étape explicite décrite ci-dessus pour un socket qui reste actif.