TLS (SSL)

[Stable: 2 - Stable]

Stable: 2 Stabilité : 2 - Stable

Code source : lib/tls.js

Le module node:tls fournit une implémentation des protocoles TLS (Transport Layer Security) et SSL (Secure Socket Layer) qui est construite au-dessus d’OpenSSL. Le module est accessible à l’aide de :

ESM

import tls from 'node:tls'

CJS

const tls = require('node:tls')

Déterminer si la prise en charge de la cryptographie n’est pas disponible

Il est possible que Node.js soit construit sans inclure la prise en charge du module node:crypto. Dans de tels cas, toute tentative d’import depuis tls ou d’appel à require('node:tls') entraînera une erreur.

Lors de l’utilisation de CommonJS, l’erreur levée peut être interceptée à l’aide de try/catch :

let tls
try {
  tls = require('node:tls')
} catch (err) {
  console.error('la prise en charge de tls est désactivée !')
}

Lors de l’utilisation du mot-clé lexical ESM import, l’erreur ne peut être interceptée que si un gestionnaire pour process.on('uncaughtException') est enregistré avant toute tentative de chargement du module (en utilisant, par exemple, un module de préchargement).

Lors de l’utilisation d’ESM, s’il y a une chance que le code puisse être exécuté sur une version de Node.js où la prise en charge de la cryptographie n’est pas activée, envisagez d’utiliser la fonction import() au lieu du mot-clé lexical import :

let tls
try {
  tls = await import('node:tls')
} catch (err) {
  console.error('la prise en charge de tls est désactivée !')
}

Concepts TLS/SSL

TLS/SSL est un ensemble de protocoles qui s’appuient sur une infrastructure de clés publiques (PKI) pour permettre une communication sécurisée entre un client et un serveur. Dans la plupart des cas courants, chaque serveur doit avoir une clé privée.

Les clés privées peuvent être générées de plusieurs façons. L’exemple ci-dessous illustre l’utilisation de l’interface de ligne de commande OpenSSL pour générer une clé privée RSA de 2 048 bits :

openssl genrsa -out ryans-key.pem 2048

Avec TLS/SSL, tous les serveurs (et certains clients) doivent avoir un certificat. Les certificats sont des clés publiques qui correspondent à une clé privée et qui sont signées numériquement soit par une autorité de certification, soit par le propriétaire de la clé privée (ces certificats sont appelés « auto-signés »). La première étape pour obtenir un certificat consiste à créer un fichier de demande de signature de certificat (CSR).

L’interface de ligne de commande OpenSSL peut être utilisée pour générer une CSR pour une clé privée :

openssl req -new -sha256 -key ryans-key.pem -out ryans-csr.pem

Une fois le fichier CSR généré, il peut être envoyé à une autorité de certification pour signature ou utilisé pour générer un certificat auto-signé.

La création d’un certificat auto-signé à l’aide de l’interface de ligne de commande OpenSSL est illustrée dans l’exemple ci-dessous :

openssl x509 -req -in ryans-csr.pem -signkey ryans-key.pem -out ryans-cert.pem

Une fois le certificat généré, il peut être utilisé pour générer un fichier .pfx ou .p12 :

openssl pkcs12 -export -in ryans-cert.pem -inkey ryans-key.pem \
      -certfile ca-cert.pem -out ryans.pfx

Où :

• in : est le certificat signé
• inkey : est la clé privée associée
• certfile : est une concaténation de tous les certificats d’autorité de certification (CA) dans un seul fichier, par exemple cat ca1-cert.pem ca2-cert.pem \> ca-cert.pem

Perfect forward secrecy

Le terme forward secrecy ou perfect forward secrecy décrit une caractéristique des méthodes d'accord de clé (c'est-à-dire, d'échange de clé). C'est-à-dire que les clés du serveur et du client sont utilisées pour négocier de nouvelles clés temporaires qui sont utilisées spécifiquement et uniquement pour la session de communication en cours. Concrètement, cela signifie que même si la clé privée du serveur est compromise, la communication ne peut être déchiffrée par des écouteurs que si l'attaquant parvient à obtenir la paire de clés spécifiquement générée pour la session.

La perfect forward secrecy est atteinte en générant aléatoirement une paire de clés pour l'accord de clé lors de chaque handshake TLS/SSL (contrairement à l'utilisation de la même clé pour toutes les sessions). Les méthodes qui mettent en œuvre cette technique sont appelées "éphémères".

Actuellement, deux méthodes sont couramment utilisées pour atteindre la perfect forward secrecy (notez le caractère "E" ajouté aux abréviations traditionnelles) :

• ECDHE: Une version éphémère du protocole d'accord de clé Elliptic Curve Diffie-Hellman.
• DHE: Une version éphémère du protocole d'accord de clé Diffie-Hellman.

La perfect forward secrecy utilisant ECDHE est activée par défaut. L'option ecdhCurve peut être utilisée lors de la création d'un serveur TLS pour personnaliser la liste des courbes ECDH prises en charge à utiliser. Voir tls.createServer() pour plus d'informations.

DHE est désactivé par défaut mais peut être activé avec ECDHE en définissant l'option dhparam sur 'auto'. Des paramètres DHE personnalisés sont également pris en charge, mais déconseillés au profit de paramètres bien connus sélectionnés automatiquement.

La perfect forward secrecy était optionnelle jusqu'à TLSv1.2. Depuis TLSv1.3, (EC)DHE est toujours utilisé (à l'exception des connexions uniquement PSK).

ALPN et SNI

ALPN (Application-Layer Protocol Negotiation Extension) et SNI (Server Name Indication) sont des extensions de handshake TLS :

• ALPN : Permet l'utilisation d'un serveur TLS pour plusieurs protocoles (HTTP, HTTP/2)
• SNI : Permet l'utilisation d'un serveur TLS pour plusieurs noms d'hôtes avec des certificats différents.

Clés pré-partagées

La prise en charge de TLS-PSK est disponible comme alternative à l'authentification classique basée sur des certificats. Elle utilise une clé pré-partagée au lieu de certificats pour authentifier une connexion TLS, fournissant une authentification mutuelle. TLS-PSK et l'infrastructure à clés publiques ne s'excluent pas mutuellement. Les clients et les serveurs peuvent prendre en charge les deux, en choisissant l'un ou l'autre pendant l'étape normale de négociation du chiffrement.

TLS-PSK est un bon choix uniquement là où il existe des moyens de partager de manière sécurisée une clé avec chaque machine se connectant. Il ne remplace donc pas l'infrastructure à clés publiques (PKI) pour la majorité des utilisations de TLS. L'implémentation de TLS-PSK dans OpenSSL a connu de nombreuses failles de sécurité ces dernières années, principalement parce qu'elle n'est utilisée que par une minorité d'applications. Veuillez envisager toutes les solutions alternatives avant de passer aux chiffrements PSK. Lors de la génération de PSK, il est d'une importance capitale d'utiliser une entropie suffisante, comme indiqué dans la RFC 4086. La dérivation d'un secret partagé à partir d'un mot de passe ou d'autres sources à faible entropie n'est pas sûre.

Les chiffrements PSK sont désactivés par défaut, et l'utilisation de TLS-PSK nécessite donc de spécifier explicitement une suite de chiffrement avec l'option ciphers. La liste des chiffrements disponibles peut être récupérée via openssl ciphers -v 'PSK'. Tous les chiffrements TLS 1.3 sont éligibles pour PSK et peuvent être récupérés via openssl ciphers -v -s -tls1_3 -psk. Sur la connexion client, un checkServerIdentity personnalisé doit être passé car celui par défaut échouera en l'absence de certificat.

Selon la RFC 4279, les identités PSK jusqu'à 128 octets de longueur et les PSK jusqu'à 64 octets de longueur doivent être pris en charge. À partir d'OpenSSL 1.1.0, la taille maximale de l'identité est de 128 octets, et la longueur maximale du PSK est de 256 octets.

L'implémentation actuelle ne prend pas en charge les rappels PSK asynchrones en raison des limitations de l'API OpenSSL sous-jacente.

Pour utiliser TLS-PSK, le client et le serveur doivent spécifier l'option pskCallback, une fonction qui renvoie le PSK à utiliser (qui doit être compatible avec le digest du chiffrement sélectionné).

Elle sera d'abord appelée sur le client :

• hint : <string> message optionnel envoyé par le serveur pour aider le client à décider quelle identité utiliser pendant la négociation. Toujours null si TLS 1.3 est utilisé.
• Retourne : <Object> sous la forme { psk: \<Buffer|TypedArray|DataView\>, identity: \<string\> } ou null.

Ensuite, sur le serveur :

• socket : <tls.TLSSocket> l'instance de socket serveur, équivalente à this.
• identity : <string> paramètre d'identité envoyé par le client.
• Retourne : <Buffer> | <TypedArray> | <DataView> le PSK (ou null).

Une valeur de retour null arrête le processus de négociation et envoie un message d'alerte unknown_psk_identity à l'autre partie. Si le serveur souhaite masquer le fait que l'identité PSK n'était pas connue, le rappel doit fournir des données aléatoires comme psk pour faire échouer la connexion avec decrypt_error avant la fin de la négociation.

Atténuation des attaques de renégociation initiées par le client

Le protocole TLS permet aux clients de renégocier certains aspects de la session TLS. Malheureusement, la renégociation de session nécessite une quantité disproportionnée de ressources côté serveur, ce qui en fait un vecteur potentiel pour les attaques par déni de service.

Pour atténuer ce risque, la renégociation est limitée à trois fois toutes les dix minutes. Un événement 'error' est émis sur l'instance tls.TLSSocket lorsque ce seuil est dépassé. Les limites sont configurables :

• tls.CLIENT_RENEG_LIMIT <nombre> Spécifie le nombre de demandes de renégociation. Par défaut : 3.
• tls.CLIENT_RENEG_WINDOW <nombre> Spécifie la fenêtre de temps de renégociation en secondes. Par défaut : 600 (10 minutes).

Les limites de renégociation par défaut ne doivent pas être modifiées sans une compréhension complète des implications et des risques.

TLSv1.3 ne prend pas en charge la renégociation.

Reprise de session

L'établissement d'une session TLS peut être relativement lent. Le processus peut être accéléré en sauvegardant puis en réutilisant l'état de la session. Il existe plusieurs mécanismes pour ce faire, discutés ici du plus ancien au plus récent (et préféré).

Identificateurs de session

Les serveurs génèrent un identifiant unique pour les nouvelles connexions et l'envoient au client. Les clients et les serveurs enregistrent l'état de la session. Lors de la reconnexion, les clients envoient l'ID de leur état de session enregistré et si le serveur a également l'état pour cet ID, il peut accepter de l'utiliser. Sinon, le serveur créera une nouvelle session. Consultez la RFC 2246 pour plus d'informations, pages 23 et 30.

La reprise à l'aide d'identifiants de session est prise en charge par la plupart des navigateurs Web lors de la réalisation de requêtes HTTPS.

Pour Node.js, les clients attendent l'événement 'session' pour obtenir les données de session et fournissent les données à l'option session d'un tls.connect() ultérieur afin de réutiliser la session. Les serveurs doivent implémenter des gestionnaires pour les événements 'newSession' et 'resumeSession' afin d'enregistrer et de restaurer les données de session en utilisant l'identifiant de session comme clé de recherche pour réutiliser les sessions. Pour réutiliser les sessions sur plusieurs équilibreurs de charge ou workers de cluster, les serveurs doivent utiliser un cache de session partagé (tel que Redis) dans leurs gestionnaires de session.

Tickets de session

Les serveurs chiffrent l'intégralité de l'état de la session et l'envoient au client sous forme de "ticket". Lors de la reconnexion, l'état est envoyé au serveur lors de la connexion initiale. Ce mécanisme évite la nécessité d'un cache de session côté serveur. Si le serveur n'utilise pas le ticket, pour quelque raison que ce soit (impossibilité de le déchiffrer, il est trop ancien, etc.), il créera une nouvelle session et enverra un nouveau ticket. Voir RFC 5077 pour plus d'informations.

La reprise de session à l'aide de tickets de session est de plus en plus courante et prise en charge par de nombreux navigateurs web lors de requêtes HTTPS.

Pour Node.js, les clients utilisent les mêmes API pour la reprise avec des identificateurs de session que pour la reprise avec des tickets de session. Pour le débogage, si tls.TLSSocket.getTLSTicket() renvoie une valeur, les données de session contiennent un ticket, sinon elles contiennent l'état de la session côté client.

Avec TLSv1.3, sachez que plusieurs tickets peuvent être envoyés par le serveur, ce qui entraîne plusieurs événements 'session', voir 'session' pour plus d'informations.

Les serveurs à processus unique n'ont pas besoin d'implémentation spécifique pour utiliser les tickets de session. Pour utiliser les tickets de session lors de redémarrages de serveur ou d'équilibrages de charge, les serveurs doivent tous avoir les mêmes clés de ticket. Il existe trois clés de 16 octets en interne, mais l'API tls les expose sous la forme d'une seule mémoire tampon de 48 octets pour plus de commodité.

Il est possible d'obtenir les clés de ticket en appelant server.getTicketKeys() sur une instance de serveur, puis de les distribuer, mais il est plus raisonnable de générer de manière sécurisée 48 octets de données aléatoires sécurisées et de les définir avec l'option ticketKeys de tls.createServer(). Les clés doivent être régénérées régulièrement et les clés du serveur peuvent être réinitialisées avec server.setTicketKeys().

Les clés de ticket de session sont des clés cryptographiques, et elles doivent être stockées en toute sécurité. Avec TLS 1.2 et les versions antérieures, si elles sont compromises, toutes les sessions qui ont utilisé des tickets chiffrés avec elles peuvent être déchiffrées. Elles ne doivent pas être stockées sur disque et doivent être régénérées régulièrement.

Si les clients annoncent la prise en charge des tickets, le serveur les enverra. Le serveur peut désactiver les tickets en fournissant require('node:constants').SSL_OP_NO_TICKET dans secureOptions.

Les identificateurs de session et les tickets de session expirent, ce qui oblige le serveur à créer de nouvelles sessions. Le délai d'expiration peut être configuré avec l'option sessionTimeout de tls.createServer().

Pour tous les mécanismes, lorsque la reprise échoue, les serveurs créent de nouvelles sessions. Étant donné que l'échec de la reprise de la session ne provoque pas d'échecs de connexion TLS/HTTPS, il est facile de ne pas remarquer une performance TLS inutilement médiocre. L'interface de ligne de commande OpenSSL peut être utilisée pour vérifier que les serveurs reprennent des sessions. Utilisez l'option -reconnect de openssl s_client, par exemple :

openssl s_client -connect localhost:443 -reconnect

Lisez la sortie de débogage. La première connexion doit indiquer "New", par exemple :

New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256

Les connexions suivantes doivent indiquer "Reused", par exemple :

Reused, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256

Modification de la suite de chiffrement TLS par défaut

Node.js est construit avec une suite par défaut de chiffrements TLS activés et désactivés. Cette liste de chiffrement par défaut peut être configurée lors de la compilation de Node.js afin de permettre aux distributions de fournir leur propre liste par défaut.

La commande suivante peut être utilisée pour afficher la suite de chiffrement par défaut :

node -p crypto.constants.defaultCoreCipherList | tr ':' '\n'
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA256
HIGH
!aNULL
!eNULL
!EXPORT
!DES
!RC4
!MD5
!PSK
!SRP
!CAMELLIA

Cette valeur par défaut peut être entièrement remplacée à l'aide de l'option de ligne de commande --tls-cipher-list (directement, ou via la variable d'environnement NODE_OPTIONS). Par exemple, ce qui suit fait de ECDHE-RSA-AES128-GCM-SHA256:!RC4 la suite de chiffrement TLS par défaut :

node --tls-cipher-list='ECDHE-RSA-AES128-GCM-SHA256:!RC4' server.js

export NODE_OPTIONS=--tls-cipher-list='ECDHE-RSA-AES128-GCM-SHA256:!RC4'
node server.js

Pour vérifier, utilisez la commande suivante pour afficher la liste de chiffrement définie, notez la différence entre defaultCoreCipherList et defaultCipherList :

node --tls-cipher-list='ECDHE-RSA-AES128-GCM-SHA256:!RC4' -p crypto.constants.defaultCipherList | tr ':' '\n'
ECDHE-RSA-AES128-GCM-SHA256
!RC4

c'est-à-dire que la liste defaultCoreCipherList est définie au moment de la compilation et que defaultCipherList est définie au moment de l'exécution.

Pour modifier les suites de chiffrement par défaut à partir de l'exécution, modifiez la variable tls.DEFAULT_CIPHERS, cela doit être effectué avant d'écouter sur les sockets, cela n'affectera pas les sockets déjà ouverts. Par exemple :

// Supprimer les chiffrements CBC obsolètes et les chiffrements basés sur l'échange de clés RSA car ils n'assurent pas la confidentialité persistante
tls.DEFAULT_CIPHERS +=
  ':!ECDHE-RSA-AES128-SHA:!ECDHE-RSA-AES128-SHA256:!ECDHE-RSA-AES256-SHA:!ECDHE-RSA-AES256-SHA384' +
  ':!ECDHE-ECDSA-AES128-SHA:!ECDHE-ECDSA-AES128-SHA256:!ECDHE-ECDSA-AES256-SHA:!ECDHE-ECDSA-AES256-SHA384' +
  ':!kRSA'

La valeur par défaut peut également être remplacée pour chaque client ou serveur à l'aide de l'option ciphers de tls.createSecureContext(), qui est également disponible dans tls.createServer(), tls.connect(), et lors de la création de nouveaux tls.TLSSocket.

La liste des chiffrements peut contenir un mélange de noms de suites de chiffrement TLSv1.3, ceux qui commencent par 'TLS_', et des spécifications pour les suites de chiffrement TLSv1.2 et inférieures. Les chiffrements TLSv1.2 prennent en charge un format de spécification hérité, consultez la documentation format de liste de chiffrements d'OpenSSL pour plus de détails, mais ces spécifications ne s'appliquent pas aux chiffrements TLSv1.3. Les suites TLSv1.3 ne peuvent être activées qu'en incluant leur nom complet dans la liste de chiffrement. Ils ne peuvent pas, par exemple, être activés ou désactivés en utilisant la spécification TLSv1.2 héritée 'EECDH' ou '!EECDH'.

Malgré l'ordre relatif des suites de chiffrement TLSv1.3 et TLSv1.2, le protocole TLSv1.3 est beaucoup plus sécurisé que TLSv1.2 et sera toujours choisi de préférence à TLSv1.2 si la négociation indique qu'il est pris en charge et si des suites de chiffrement TLSv1.3 sont activées.

La suite de chiffrement par défaut incluse dans Node.js a été soigneusement sélectionnée pour refléter les meilleures pratiques de sécurité actuelles et l'atténuation des risques. La modification de la suite de chiffrement par défaut peut avoir un impact significatif sur la sécurité d'une application. L'option --tls-cipher-list et l'option ciphers ne doivent être utilisées qu'en cas de nécessité absolue.

La suite de chiffrement par défaut préfère les chiffrements GCM pour le paramètre « cryptographie moderne » de Chrome et préfère également les chiffrements ECDHE et DHE pour une confidentialité persistante parfaite, tout en offrant une certaine rétrocompatibilité.

Les anciens clients qui s'appuient sur des chiffrements RC4 ou DES non sécurisés et obsolètes (comme Internet Explorer 6) ne peuvent pas terminer le processus de négociation avec la configuration par défaut. Si ces clients doivent être pris en charge, les recommandations TLS peuvent offrir une suite de chiffrement compatible. Pour plus de détails sur le format, consultez la documentation OpenSSL format de liste de chiffrement.

Il n'existe que cinq suites de chiffrement TLSv1.3 :

• 'TLS_AES_256_GCM_SHA384'
• 'TLS_CHACHA20_POLY1305_SHA256'
• 'TLS_AES_128_GCM_SHA256'
• 'TLS_AES_128_CCM_SHA256'
• 'TLS_AES_128_CCM_8_SHA256'

Les trois premières sont activées par défaut. Les deux suites basées sur CCM sont prises en charge par TLSv1.3, car elles peuvent être plus performantes sur les systèmes contraints, mais elles ne sont pas activées par défaut car elles offrent moins de sécurité.

Niveau de sécurité OpenSSL

La bibliothèque OpenSSL applique des niveaux de sécurité pour contrôler le niveau minimum acceptable de sécurité pour les opérations cryptographiques. Les niveaux de sécurité d'OpenSSL vont de 0 à 5, chaque niveau imposant des exigences de sécurité plus strictes. Le niveau de sécurité par défaut est 1, ce qui convient généralement à la plupart des applications modernes. Cependant, certaines fonctionnalités et protocoles hérités, tels que TLSv1, nécessitent un niveau de sécurité inférieur (SECLEVEL=0) pour fonctionner correctement. Pour des informations plus détaillées, veuillez consulter la documentation d'OpenSSL sur les niveaux de sécurité.

Définition des niveaux de sécurité

Pour ajuster le niveau de sécurité dans votre application Node.js, vous pouvez inclure @SECLEVEL=X dans une chaîne de chiffrement, où X est le niveau de sécurité souhaité. Par exemple, pour définir le niveau de sécurité à 0 tout en utilisant la liste de chiffrement OpenSSL par défaut, vous pouvez utiliser :

ESM

import { createServer, connect } from 'node:tls'
const port = 443

createServer({ ciphers: 'DEFAULT@SECLEVEL=0', minVersion: 'TLSv1' }, function (socket) {
  console.log('Client connecté avec le protocole :', socket.getProtocol())
  socket.end()
  this.close()
}).listen(port, () => {
  connect(port, { ciphers: 'DEFAULT@SECLEVEL=0', maxVersion: 'TLSv1' })
})

CJS

const { createServer, connect } = require('node:tls')
const port = 443

createServer({ ciphers: 'DEFAULT@SECLEVEL=0', minVersion: 'TLSv1' }, function (socket) {
  console.log('Client connecté avec le protocole :', socket.getProtocol())
  socket.end()
  this.close()
}).listen(port, () => {
  connect(port, { ciphers: 'DEFAULT@SECLEVEL=0', maxVersion: 'TLSv1' })
})

Cette approche définit le niveau de sécurité à 0, permettant l’utilisation de fonctionnalités héritées tout en tirant parti des chiffrements OpenSSL par défaut.

Utilisation

Vous pouvez également définir le niveau de sécurité et les chiffrements à partir de la ligne de commande à l’aide de --tls-cipher-list=DEFAULT@SECLEVEL=X comme décrit dans Modification de la suite de chiffrement TLS par défaut. Cependant, il est généralement déconseillé d’utiliser l’option de ligne de commande pour définir les chiffrements et il est préférable de configurer les chiffrements pour des contextes individuels dans votre code d’application, car cette approche offre un contrôle plus fin et réduit le risque de rétrograder globalement le niveau de sécurité.

Codes d'erreur de certificat X509

Plusieurs fonctions peuvent échouer en raison d'erreurs de certificat signalées par OpenSSL. Dans ce cas, la fonction fournit une <Error> via son rappel qui a la propriété code qui peut prendre l'une des valeurs suivantes :

• 'UNABLE_TO_GET_ISSUER_CERT' : Impossible d'obtenir le certificat de l'émetteur.
• 'UNABLE_TO_GET_CRL' : Impossible d'obtenir la liste de révocation de certificat (CRL).
• 'UNABLE_TO_DECRYPT_CERT_SIGNATURE' : Impossible de déchiffrer la signature du certificat.
• 'UNABLE_TO_DECRYPT_CRL_SIGNATURE' : Impossible de déchiffrer la signature de la CRL.
• 'UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY' : Impossible de décoder la clé publique de l'émetteur.
• 'CERT_SIGNATURE_FAILURE' : Échec de la signature du certificat.
• 'CRL_SIGNATURE_FAILURE' : Échec de la signature de la CRL.
• 'CERT_NOT_YET_VALID' : Le certificat n'est pas encore valide.
• 'CERT_HAS_EXPIRED' : Le certificat a expiré.
• 'CRL_NOT_YET_VALID' : La CRL n'est pas encore valide.
• 'CRL_HAS_EXPIRED' : La CRL a expiré.
• 'ERROR_IN_CERT_NOT_BEFORE_FIELD' : Erreur de format dans le champ notBefore du certificat.
• 'ERROR_IN_CERT_NOT_AFTER_FIELD' : Erreur de format dans le champ notAfter du certificat.
• 'ERROR_IN_CRL_LAST_UPDATE_FIELD' : Erreur de format dans le champ lastUpdate de la CRL.
• 'ERROR_IN_CRL_NEXT_UPDATE_FIELD' : Erreur de format dans le champ nextUpdate de la CRL.
• 'OUT_OF_MEM' : Mémoire insuffisante.
• 'DEPTH_ZERO_SELF_SIGNED_CERT' : Certificat auto-signé.
• 'SELF_SIGNED_CERT_IN_CHAIN' : Certificat auto-signé dans la chaîne de certificats.
• 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY' : Impossible d'obtenir le certificat de l'émetteur localement.
• 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' : Impossible de vérifier le premier certificat.
• 'CERT_CHAIN_TOO_LONG' : Chaîne de certificats trop longue.
• 'CERT_REVOKED' : Certificat révoqué.
• 'INVALID_CA' : Certificat d'autorité de certification invalide.
• 'PATH_LENGTH_EXCEEDED' : Contrainte de longueur du chemin dépassée.
• 'INVALID_PURPOSE' : Utilisation du certificat non prise en charge.
• 'CERT_UNTRUSTED' : Certificat non approuvé.
• 'CERT_REJECTED' : Certificat rejeté.
• 'HOSTNAME_MISMATCH' : Incompatibilité de nom d'hôte.

Classe : tls.CryptoStream

Ajouté dans : v0.3.4

Déprécié depuis : v0.11.3

[Stable: 0 - Déprécié]

Stable: 0 Stabilité : 0 - Déprécié : utilisez plutôt tls.TLSSocket.

La classe tls.CryptoStream représente un flux de données chiffrées. Cette classe est dépréciée et ne doit plus être utilisée.

cryptoStream.bytesWritten

Ajouté dans : v0.3.4

Déprécié depuis : v0.11.3

La propriété cryptoStream.bytesWritten renvoie le nombre total d’octets écrits dans le socket sous-jacent, y compris les octets nécessaires à la mise en œuvre du protocole TLS.

Classe : tls.SecurePair

Ajouté dans : v0.3.2

Déprécié depuis : v0.11.3

[Stable: 0 - Déprécié]

Stable: 0 Stabilité : 0 - Déprécié : utilisez plutôt tls.TLSSocket.

Retourné par tls.createSecurePair().

Événement : 'secure'

Ajouté dans : v0.3.2

Déprécié depuis : v0.11.3

L’événement 'secure' est émis par l’objet SecurePair une fois qu’une connexion sécurisée a été établie.

Comme lors de la vérification de l’événement 'secureConnection' du serveur, pair.cleartext.authorized doit être inspecté pour confirmer si le certificat utilisé est correctement autorisé.

Classe : tls.Server

Ajouté dans : v0.3.2

• S’étend : <net.Server>

Accepte les connexions chiffrées à l’aide de TLS ou SSL.

Événement : 'connection'

Ajouté dans : v0.3.2

• socket <stream.Duplex>

Cet événement est émis lorsqu’un nouveau flux TCP est établi, avant que la négociation TLS ne commence. socket est généralement un objet de type net.Socket, mais ne recevra pas d’événements contrairement au socket créé à partir de l’événement 'connection' de net.Server. En général, les utilisateurs ne voudront pas accéder à cet événement.

Cet événement peut également être émis explicitement par les utilisateurs pour injecter des connexions dans le serveur TLS. Dans ce cas, tout flux Duplex peut être transmis.

Événement : 'keylog'

Ajouté dans : v12.3.0, v10.20.0

• line <Buffer> Ligne de texte ASCII, au format NSS SSLKEYLOGFILE.
• tlsSocket <tls.TLSSocket> L’instance tls.TLSSocket sur laquelle elle a été générée.

L’événement keylog est émis lorsque des données de clé sont générées ou reçues par une connexion à ce serveur (généralement avant que la négociation ne soit terminée, mais pas nécessairement). Ces données de clé peuvent être stockées à des fins de débogage, car elles permettent de déchiffrer le trafic TLS capturé. Il peut être émis plusieurs fois pour chaque socket.

Un cas d’utilisation typique consiste à ajouter les lignes reçues à un fichier texte commun, qui est ensuite utilisé par un logiciel (tel que Wireshark) pour déchiffrer le trafic :

const logFile = fs.createWriteStream('/tmp/ssl-keys.log', { flags: 'a' })
// ...
server.on('keylog', (line, tlsSocket) => {
  if (tlsSocket.remoteAddress !== '...') return // Enregistrer uniquement les clés pour une adresse IP particulière
  logFile.write(line)
})

Événement : 'newSession'

[Historique]

Version	Modifications
v0.11.12	L’argument callback est désormais pris en charge.
v0.9.2	Ajouté dans : v0.9.2

L’événement 'newSession' est émis lors de la création d’une nouvelle session TLS. Il peut être utilisé pour stocker des sessions dans un stockage externe. Les données doivent être fournies au rappel 'resumeSession'.

Le rappel de l’écouteur reçoit trois arguments lors de son appel :

• sessionId <Buffer> L’identificateur de session TLS
• sessionData <Buffer> Les données de session TLS
• callback <Function> Une fonction de rappel ne prenant aucun argument qui doit être appelée pour que les données soient envoyées ou reçues via la connexion sécurisée.

L’écoute de cet événement n’aura d’effet que sur les connexions établies après l’ajout de l’écouteur d’événement.

Événement : 'OCSPRequest'

Ajouté dans : v0.11.13

L’événement 'OCSPRequest' est émis lorsque le client envoie une demande d’état de certificat. Le rappel de l’écouteur reçoit trois arguments lors de son appel :

• certificate <Buffer> Le certificat du serveur
• issuer <Buffer> Le certificat de l’émetteur
• callback <Function> Une fonction de rappel qui doit être appelée pour fournir les résultats de la requête OCSP.

Le certificat actuel du serveur peut être analysé pour obtenir l’URL OCSP et l’ID du certificat ; après avoir obtenu une réponse OCSP, callback(null, resp) est ensuite appelé, où resp est une instance Buffer contenant la réponse OCSP. certificate et issuer sont tous deux des représentations DER Buffer des certificats principal et de l’émetteur. Elles peuvent être utilisées pour obtenir l’ID du certificat OCSP et l’URL du point de terminaison OCSP.

Alternativement, callback(null, null) peut être appelé, indiquant qu’il n’y a pas eu de réponse OCSP.

L’appel de callback(err) entraînera un appel socket.destroy(err).

Le flux typique d’une requête OCSP est le suivant :

L’issuer peut être null si le certificat est auto-signé ou si l’émetteur ne figure pas dans la liste des certificats racine. (Un émetteur peut être fourni via l’option ca lors de l’établissement de la connexion TLS.)

L’écoute de cet événement n’aura d’effet que sur les connexions établies après l’ajout de l’écouteur d’événement.

Un module npm tel que asn1.js peut être utilisé pour analyser les certificats.

Événement : 'resumeSession'

Ajouté dans : v0.9.2

L’événement 'resumeSession' est émis lorsque le client demande la reprise d’une session TLS précédente. Le rappel de l’écouteur reçoit deux arguments lorsqu’il est appelé :

• sessionId <Buffer> L’identifiant de la session TLS
• callback <Function> Une fonction de rappel à appeler lorsque la session précédente a été récupérée : callback([err[, sessionData]])
  • err <Error>
  • sessionData <Buffer>

L’écouteur d’événement doit effectuer une recherche dans un stockage externe pour les sessionData enregistrées par le gestionnaire d’événement 'newSession' à l’aide du sessionId donné. S’il est trouvé, appelez callback(null, sessionData) pour reprendre la session. S’il n’est pas trouvé, la session ne peut pas être reprise. callback() doit être appelé sans sessionData afin que l’établissement de liaison puisse continuer et qu’une nouvelle session puisse être créée. Il est possible d’appeler callback(err) pour mettre fin à la connexion entrante et détruire le socket.

L’écoute de cet événement n’aura d’effet que sur les connexions établies après l’ajout de l’écouteur d’événement.

Ce qui suit illustre la reprise d’une session TLS :

const tlsSessionStore = {}
server.on('newSession', (id, data, cb) => {
  tlsSessionStore[id.toString('hex')] = data
  cb()
})
server.on('resumeSession', (id, cb) => {
  cb(null, tlsSessionStore[id.toString('hex')] || null)
})

Événement : 'secureConnection'

Ajouté dans : v0.3.2

L’événement 'secureConnection' est émis une fois le processus d’établissement de liaison pour une nouvelle connexion terminé avec succès. Le rappel de l’écouteur reçoit un seul argument lorsqu’il est appelé :

• tlsSocket <tls.TLSSocket> Le socket TLS établi.

La propriété tlsSocket.authorized est une valeur booléenne indiquant si le client a été vérifié par l’une des autorités de certification fournies pour le serveur. Si tlsSocket.authorized est false, socket.authorizationError est défini pour décrire la raison de l’échec de l’autorisation. En fonction des paramètres du serveur TLS, les connexions non autorisées peuvent tout de même être acceptées.

La propriété tlsSocket.alpnProtocol est une chaîne qui contient le protocole ALPN sélectionné. Lorsque ALPN n’a aucun protocole sélectionné parce que le client ou le serveur n’a pas envoyé d’extension ALPN, tlsSocket.alpnProtocol est égal à false.

La propriété tlsSocket.servername est une chaîne contenant le nom du serveur demandé via SNI.

Événement : 'tlsClientError'

Ajouté dans : v6.0.0

L’événement 'tlsClientError' est émis lorsqu’une erreur se produit avant qu’une connexion sécurisée ne soit établie. Le rappel de l’écouteur reçoit deux arguments lors de son appel :

• exception <Error> L’objet Error décrivant l’erreur.
• tlsSocket <tls.TLSSocket> L’instance tls.TLSSocket d’où provient l’erreur.

server.addContext(hostname, context)

Ajouté dans : v0.5.3

• hostname <string> Un nom d’hôte SNI ou caractère générique (par ex., '*').
• context <Object> | <tls.SecureContext> Un objet contenant l’une des propriétés possibles des arguments options de tls.createSecureContext() (par ex., key, cert, ca, etc.) ou un objet de contexte TLS créé avec tls.createSecureContext() lui-même.

La méthode server.addContext() ajoute un contexte sécurisé qui sera utilisé si le nom SNI de la requête du client correspond au hostname (ou caractère générique) fourni.

Lorsqu’il existe plusieurs contextes correspondants, le plus récemment ajouté est utilisé.

server.address()

Ajouté dans : v0.6.0

• Retourne : <Object>

Retourne l’adresse liée, le nom de la famille d’adresses et le port du serveur tels que signalés par le système d’exploitation. Consultez net.Server.address() pour plus d’informations.

server.close([callback])

Ajouté dans : v0.3.2

• callback <Function> Un rappel d’écouteur qui sera enregistré pour écouter l’événement 'close' de l’instance du serveur.
• Retourne : <tls.Server>

La méthode server.close() empêche le serveur d’accepter de nouvelles connexions.

Cette fonction fonctionne de manière asynchrone. L’événement 'close' sera émis lorsque le serveur n’aura plus de connexions ouvertes.

server.getTicketKeys()

Ajouté dans : v3.0.0

• Retourne : <Buffer> Un tampon de 48 octets contenant les clés de ticket de session.

Retourne les clés de ticket de session.

Voir Reprise de session pour plus d’informations.

server.listen()

Démarre l’écoute du serveur pour les connexions chiffrées. Cette méthode est identique à server.listen() de net.Server.

server.setSecureContext(options)

Ajouté dans : v11.0.0

• options <Object> Un objet contenant n’importe laquelle des propriétés possibles à partir des arguments options de tls.createSecureContext() (par ex., key, cert, ca, etc.).

La méthode server.setSecureContext() remplace le contexte sécurisé d’un serveur existant. Les connexions existantes au serveur ne sont pas interrompues.

server.setTicketKeys(keys)

Ajouté dans : v3.0.0

• keys <Buffer> | <TypedArray> | <DataView> Un tampon de 48 octets contenant les clés de ticket de session.

Définit les clés de ticket de session.

Les changements apportés aux clés de ticket ne sont effectifs que pour les futures connexions au serveur. Les connexions de serveur existantes ou actuellement en attente utiliseront les clés précédentes.

Voir Reprise de session pour plus d’informations.

Classe : tls.TLSSocket

Ajouté dans : v0.11.4

• Hérite de : <net.Socket>

Effectue un chiffrement transparent des données écrites et toute la négociation TLS requise.

Les instances de tls.TLSSocket implémentent l’interface Stream duplex.

Les méthodes qui retournent des métadonnées de connexion TLS (par ex., tls.TLSSocket.getPeerCertificate()) ne retourneront des données que pendant que la connexion est ouverte.

new tls.TLSSocket(socket[, options])

[Historique]

Version	Modifications
v12.2.0	L'option enableTrace est désormais prise en charge.
v5.0.0	Les options ALPN sont désormais prises en charge.
v0.11.4	Ajouté dans : v0.11.4

• socket <net.Socket> | <stream.Duplex> Côté serveur, tout flux Duplex. Côté client, toute instance de net.Socket (pour une prise en charge générique des flux Duplex côté client, tls.connect() doit être utilisé).
• options <Object>
  • enableTrace : Voir tls.createServer()
  • isServer : Le protocole SSL/TLS est asymétrique, les TLSSockets doivent savoir s'ils doivent se comporter comme un serveur ou un client. Si true, le socket TLS sera instancié comme un serveur. Par défaut : false.
  • server <net.Server> Une instance de net.Server.
  • requestCert : Indique s'il faut authentifier le pair distant en demandant un certificat. Les clients demandent toujours un certificat de serveur. Les serveurs (isServer est vrai) peuvent définir requestCert à true pour demander un certificat client.
  • rejectUnauthorized : Voir tls.createServer()
  • ALPNProtocols : Voir tls.createServer()
  • SNICallback : Voir tls.createServer()
  • session <Buffer> Une instance de Buffer contenant une session TLS.
  • requestOCSP <boolean> Si true, spécifie que l'extension de requête de statut OCSP sera ajoutée au client hello et qu'un événement 'OCSPResponse' sera émis sur le socket avant d'établir une communication sécurisée.
  • secureContext : Objet de contexte TLS créé avec tls.createSecureContext(). Si un secureContext n'est pas fourni, un sera créé en passant l'objet options entier à tls.createSecureContext().
  • ...: Options de tls.createSecureContext() qui sont utilisées si l'option secureContext est manquante. Sinon, elles sont ignorées.

Construit un nouvel objet tls.TLSSocket à partir d'un socket TCP existant.

Événement : 'keylog'

Ajouté dans : v12.3.0, v10.20.0

• line <Buffer> Ligne de texte ASCII, au format NSS SSLKEYLOGFILE.

L'événement keylog est émis sur un tls.TLSSocket lorsque des données clés sont générées ou reçues par le socket. Ces données clés peuvent être stockées à des fins de débogage, car elles permettent de déchiffrer le trafic TLS capturé. Il peut être émis plusieurs fois, avant ou après la fin de la négociation.

Un cas d'utilisation typique consiste à ajouter les lignes reçues à un fichier texte commun, qui est ensuite utilisé par un logiciel (tel que Wireshark) pour déchiffrer le trafic :

const logFile = fs.createWriteStream('/tmp/ssl-keys.log', { flags: 'a' })
// ...
tlsSocket.on('keylog', line => logFile.write(line))

Événement : 'OCSPResponse'

Ajouté dans : v0.11.13

L'événement 'OCSPResponse' est émis si l'option requestOCSP a été définie lors de la création du tls.TLSSocket et qu'une réponse OCSP a été reçue. La fonction de rappel de l'écouteur reçoit un seul argument lors de son appel :

• response <Buffer> La réponse OCSP du serveur

Généralement, la response est un objet signé numériquement provenant de l'autorité de certification du serveur et contenant des informations sur l'état de révocation du certificat du serveur.

Événement : 'secureConnect'

Ajouté dans : v0.11.4

L'événement 'secureConnect' est émis après que le processus de négociation pour une nouvelle connexion s'est terminé avec succès. La fonction de rappel de l'écouteur sera appelée que le certificat du serveur ait été autorisé ou non. Il incombe au client de vérifier la propriété tlsSocket.authorized pour déterminer si le certificat du serveur a été signé par l'une des autorités de certification spécifiées. Si tlsSocket.authorized === false, l'erreur peut être trouvée en examinant la propriété tlsSocket.authorizationError. Si ALPN a été utilisé, la propriété tlsSocket.alpnProtocol peut être vérifiée pour déterminer le protocole négocié.

L'événement 'secureConnect' n'est pas émis lorsqu'un <tls.TLSSocket> est créé à l'aide du constructeur new tls.TLSSocket().

Événement : 'session'

Ajouté dans : v11.10.0

• session <Buffer>

L'événement 'session' est émis sur un client tls.TLSSocket lorsqu'une nouvelle session ou un nouveau ticket TLS est disponible. Cela peut se produire avant ou après la fin de la négociation, en fonction de la version du protocole TLS qui a été négociée. L'événement n'est pas émis sur le serveur, ou si une nouvelle session n'a pas été créée, par exemple, lorsque la connexion a été reprise. Pour certaines versions du protocole TLS, l'événement peut être émis plusieurs fois, auquel cas toutes les sessions peuvent être utilisées pour la reprise.

Sur le client, la session peut être fournie à l'option session de tls.connect() pour reprendre la connexion.

Voir Reprise de Session pour plus d'informations.

Pour TLSv1.2 et les versions antérieures, tls.TLSSocket.getSession() peut être appelé une fois la négociation terminée. Pour TLSv1.3, seule la reprise basée sur les tickets est autorisée par le protocole, plusieurs tickets sont envoyés, et les tickets ne sont envoyés qu'après la fin de la négociation. Il est donc nécessaire d'attendre l'événement 'session' pour obtenir une session réutilisable. Les applications doivent utiliser l'événement 'session' au lieu de getSession() pour s'assurer qu'elles fonctionneront pour toutes les versions TLS. Les applications qui ne s'attendent à obtenir ou utiliser qu'une seule session doivent écouter cet événement une seule fois :

tlsSocket.once('session', session => {
  // La session peut être utilisée immédiatement ou plus tard.
  tls.connect({
    session: session,
    // Autres options de connexion...
  })
})

tlsSocket.address()

[Historique]

Version	Modifications
v18.4.0	La propriété family renvoie désormais une chaîne de caractères au lieu d'un nombre.
v18.0.0	La propriété family renvoie désormais un nombre au lieu d'une chaîne de caractères.
v0.11.4	Ajouté dans : v0.11.4

• Retourne : <Object>

Retourne l'adresse liée, le nom de famille d'adresse et le port du socket sous-jacent tel que rapporté par le système d'exploitation : { port: 12346, family: 'IPv4', address: '127.0.0.1' }.

tlsSocket.authorizationError

Ajouté dans : v0.11.4

Renvoie la raison pour laquelle le certificat du pair n'a pas été vérifié. Cette propriété n'est définie que lorsque tlsSocket.authorized === false.

tlsSocket.authorized

Ajouté dans : v0.11.4

• <boolean>

Cette propriété est true si le certificat du pair a été signé par l'une des AC spécifiées lors de la création de l'instance tls.TLSSocket, sinon false.

tlsSocket.disableRenegotiation()

Ajouté dans : v8.4.0

Désactive la renégociation TLS pour cette instance TLSSocket. Une fois appelé, les tentatives de renégociation déclencheront un événement 'error' sur le TLSSocket.

tlsSocket.enableTrace()

Ajouté dans : v12.2.0

Lorsqu'elle est activée, les informations de trace des paquets TLS sont écrites dans stderr. Cela peut être utilisé pour déboguer les problèmes de connexion TLS.

Le format de la sortie est identique à la sortie de openssl s_client -trace ou openssl s_server -trace. Bien qu'elle soit produite par la fonction SSL_trace() d'OpenSSL, le format n'est pas documenté, peut changer sans préavis et ne doit pas être utilisé.

tlsSocket.encrypted

Ajouté dans : v0.11.4

Renvoie toujours true. Cela peut être utilisé pour distinguer les sockets TLS des instances net.Socket ordinaires.

tlsSocket.exportKeyingMaterial(length, label[, context])

Ajouté dans : v13.10.0, v12.17.0

• length <number> nombre d'octets à récupérer à partir du matériel de clés
• label <string> une étiquette spécifique à l'application, il s'agira généralement d'une valeur du Registre des étiquettes d'exportateur de l'IANA.
• context <Buffer> Fournit éventuellement un contexte.
• Retourne : <Buffer> octets demandés du matériel de clés

Le matériel de clés est utilisé pour les validations afin d'empêcher différents types d'attaques dans les protocoles réseau, par exemple dans les spécifications d'IEEE 802.1X.

Exemple

const keyingMaterial = tlsSocket.exportKeyingMaterial(128, 'client finished')

/*
 Exemple de valeur de retour de keyingMaterial :
 <Buffer 76 26 af 99 c5 56 8e 42 09 91 ef 9f 93 cb ad 6c 7b 65 f8 53 f1 d8 d9
    12 5a 33 b8 b5 25 df 7b 37 9f e0 e2 4f b8 67 83 a3 2f cd 5d 41 42 4c 91
    74 ef 2c ... 78 octets de plus>
*/

Consultez la documentation OpenSSL SSL_export_keying_material pour plus d'informations.

tlsSocket.getCertificate()

Ajouté dans : v11.2.0

• Retourne : <Object>

Retourne un objet représentant le certificat local. L'objet retourné possède des propriétés correspondant aux champs du certificat.

Consultez tls.TLSSocket.getPeerCertificate() pour un exemple de la structure du certificat.

S'il n'y a pas de certificat local, un objet vide sera retourné. Si le socket a été détruit, null sera retourné.

tlsSocket.getCipher()

[Historique]

Version	Modifications
v13.4.0, v12.16.0	Retourne le nom de chiffrement IETF comme standardName.
v12.0.0	Retourne la version minimale de chiffrement, au lieu d'une chaîne fixe ('TLSv1/SSLv3').
v0.11.4	Ajouté dans : v0.11.4

• Retourne : <Object>
  • name <string> Nom OpenSSL pour la suite de chiffrement.
  • standardName <string> Nom IETF pour la suite de chiffrement.
  • version <string> La version minimale du protocole TLS prise en charge par cette suite de chiffrement. Pour le protocole négocié réel, consultez tls.TLSSocket.getProtocol().

Retourne un objet contenant des informations sur la suite de chiffrement négociée.

Par exemple, un protocole TLSv1.2 avec chiffrement AES256-SHA :

{
  "name": "AES256-SHA",
  "standardName": "TLS_RSA_WITH_AES_256_CBC_SHA",
  "version": "SSLv3"
}

Consultez SSL_CIPHER_get_name pour plus d'informations.

tlsSocket.getEphemeralKeyInfo()

Ajouté dans : v5.0.0

• Retourne : <Object>

Retourne un objet représentant le type, le nom et la taille du paramètre d'un échange de clé éphémère dans secret de transmission parfait sur une connexion client. Il retourne un objet vide lorsque l'échange de clé n'est pas éphémère. Comme cela n'est pris en charge que sur un socket client ; null est retourné s'il est appelé sur un socket serveur. Les types pris en charge sont 'DH' et 'ECDH'. La propriété name n'est disponible que lorsque le type est 'ECDH'.

Par exemple : { type: 'ECDH', name: 'prime256v1', size: 256 }.

tlsSocket.getFinished()

Ajouté dans : v9.9.0

• Retourne : <Buffer> | <undefined> Le dernier message Finished qui a été envoyé à la socket dans le cadre d'une négociation SSL/TLS, ou undefined si aucun message Finished n'a encore été envoyé.

Comme les messages Finished sont des condensés de message de la négociation complète (avec un total de 192 bits pour TLS 1.0 et plus pour SSL 3.0), ils peuvent être utilisés pour des procédures d'authentification externes lorsque l'authentification fournie par SSL/TLS n'est pas souhaitée ou n'est pas suffisante.

Correspond à la routine SSL_get_finished dans OpenSSL et peut être utilisé pour implémenter la liaison de canal tls-unique depuis RFC 5929.

tlsSocket.getPeerCertificate([detailed])

Ajouté dans : v0.11.4

• detailed <boolean> Inclure la chaîne de certificats complète si true, sinon inclure uniquement le certificat du pair.
• Retourne : <Object> Un objet certificat.

Retourne un objet représentant le certificat du pair. Si le pair ne fournit pas de certificat, un objet vide sera retourné. Si la socket a été détruite, null sera retourné.

Si la chaîne de certificats complète a été demandée, chaque certificat inclura une propriété issuerCertificate contenant un objet représentant le certificat de son émetteur.

Objet certificat

[Historique]

Version	Modifications
v19.1.0, v18.13.0	Ajout de la propriété « ca ».
v17.2.0, v16.14.0	Ajout de fingerprint512.
v11.4.0	Prise en charge des informations de clé publique Elliptic Curve.

Un objet certificat a des propriétés correspondant aux champs du certificat.

• ca <boolean> true s'il s'agit d'une autorité de certification (CA), false sinon.
• raw <Buffer> Les données du certificat X.509 encodées DER.
• subject <Object> Le sujet du certificat, décrit en termes de pays (C), État ou province (ST), localité (L), organisation (O), unité organisationnelle (OU) et nom commun (CN). Le nom commun est généralement un nom DNS avec des certificats TLS. Exemple : {C: 'UK', ST: 'BC', L: 'Metro', O: 'Node Fans', OU: 'Docs', CN: 'example.com'}.
• issuer <Object> L'émetteur du certificat, décrit dans les mêmes termes que le subject.
• valid_from <string> La date et l'heure à partir desquelles le certificat est valide.
• valid_to <string> La date et l'heure jusqu'auxquelles le certificat est valide.
• serialNumber <string> Le numéro de série du certificat, sous forme de chaîne hexadécimale. Exemple : 'B9B0D332A1AA5635'.
• fingerprint <string> Le condensé SHA-1 du certificat encodé DER. Il est retourné sous forme de chaîne hexadécimale séparée par « : ». Exemple : '2A:7A:C2:DD:...'.
• fingerprint256 <string> Le condensé SHA-256 du certificat encodé DER. Il est retourné sous forme de chaîne hexadécimale séparée par « : ». Exemple : '2A:7A:C2:DD:...'.
• fingerprint512 <string> Le condensé SHA-512 du certificat encodé DER. Il est retourné sous forme de chaîne hexadécimale séparée par « : ». Exemple : '2A:7A:C2:DD:...'.
• ext_key_usage <Array> (Facultatif) L'utilisation de la clé étendue, un ensemble d'OID.
• subjectaltname <string> (Facultatif) Une chaîne contenant les noms concaténés pour le sujet, une alternative aux noms de subject.
• infoAccess <Array> (Facultatif) Un tableau décrivant l'AuthorityInfoAccess, utilisé avec OCSP.
• issuerCertificate <Object> (Facultatif) L'objet certificat de l'émetteur. Pour les certificats auto-signés, cela peut être une référence circulaire.

Le certificat peut contenir des informations sur la clé publique, en fonction du type de clé.

Pour les clés RSA, les propriétés suivantes peuvent être définies :

• bits <number> La taille du bit RSA. Exemple : 1024.
• exponent <string> L'exposant RSA, sous forme de chaîne en notation de nombre hexadécimal. Exemple : '0x010001'.
• modulus <string> Le module RSA, sous forme de chaîne hexadécimale. Exemple : 'B56CE45CB7...'.
• pubkey <Buffer> La clé publique.

Pour les clés EC, les propriétés suivantes peuvent être définies :

• pubkey <Buffer> La clé publique.
• bits <number> La taille de la clé en bits. Exemple : 256.
• asn1Curve <string> (Facultatif) Le nom ASN.1 de l'OID de la courbe elliptique. Les courbes connues sont identifiées par un OID. Bien que cela soit inhabituel, il est possible que la courbe soit identifiée par ses propriétés mathématiques, auquel cas elle n'aura pas d'OID. Exemple : 'prime256v1'.
• nistCurve <string> (Facultatif) Le nom NIST de la courbe elliptique, s'il en a un (toutes les courbes connues n'ont pas été assignées à un nom par le NIST). Exemple : 'P-256'.

Exemple de certificat :

{ subject:
   { OU: [ 'Domain Control Validated', 'PositiveSSL Wildcard' ],
     CN: '*.nodejs.org' },
  issuer:
   { C: 'GB',
     ST: 'Greater Manchester',
     L: 'Salford',
     O: 'COMODO CA Limited',
     CN: 'COMODO RSA Domain Validation Secure Server CA' },
  subjectaltname: 'DNS:*.nodejs.org, DNS:nodejs.org',
  infoAccess:
   { 'CA Issuers - URI':
      [ 'http://crt.comodoca.com/COMODORSADomainValidationSecureServerCA.crt' ],
     'OCSP - URI': [ 'http://ocsp.comodoca.com' ] },
  modulus: 'B56CE45CB740B09A13F64AC543B712FF9EE8E4C284B542A1708A27E82A8D151CA178153E12E6DDA15BF70FFD96CB8A88618641BDFCCA03527E665B70D779C8A349A6F88FD4EF6557180BD4C98192872BCFE3AF56E863C09DDD8BC1EC58DF9D94F914F0369102B2870BECFA1348A0838C9C49BD1C20124B442477572347047506B1FCD658A80D0C44BCC16BC5C5496CFE6E4A8428EF654CD3D8972BF6E5BFAD59C93006830B5EB1056BBB38B53D1464FA6E02BFDF2FF66CD949486F0775EC43034EC2602AEFBF1703AD221DAA2A88353C3B6A688EFE8387811F645CEED7B3FE46E1F8B9F59FAD028F349B9BC14211D5830994D055EEA3D547911E07A0ADDEB8A82B9188E58720D95CD478EEC9AF1F17BE8141BE80906F1A339445A7EB5B285F68039B0F294598A7D1C0005FC22B5271B0752F58CCDEF8C8FD856FB7AE21C80B8A2CE983AE94046E53EDE4CB89F42502D31B5360771C01C80155918637490550E3F555E2EE75CC8C636DDE3633CFEDD62E91BF0F7688273694EEEBA20C2FC9F14A2A435517BC1D7373922463409AB603295CEB0BB53787A334C9CA3CA8B30005C5A62FC0715083462E00719A8FA3ED0A9828C3871360A73F8B04A4FC1E71302844E9BB9940B77E745C9D91F226D71AFCAD4B113AAF68D92B24DDB4A2136B55A1CD1ADF39605B63CB639038ED0F4C987689866743A68769CC55847E4A06D6E2E3F1',
  exponent: '0x10001',
  pubkey: <Buffer ... >,
  valid_from: 'Aug 14 00:00:00 2017 GMT',
  valid_to: 'Nov 20 23:59:59 2019 GMT',
  fingerprint: '01:02:59:D9:C3:D2:0D:08:F7:82:4E:44:A4:B4:53:C5:E2:3A:87:4D',
  fingerprint256: '69:AE:1A:6A:D4:3D:C6:C1:1B:EA:C6:23:DE:BA:2A:14:62:62:93:5C:7A:EA:06:41:9B:0B:BC:87:CE:48:4E:02',
  fingerprint512: '19:2B:3E:C3:B3:5B:32:E8:AE:BB:78:97:27:E4:BA:6C:39:C9:92:79:4F:31:46:39:E2:70:E5:5F:89:42:17:C9:E8:64:CA:FF:BB:72:56:73:6E:28:8A:92:7E:A3:2A:15:8B:C2:E0:45:CA:C3:BC:EA:40:52:EC:CA:A2:68:CB:32',
  ext_key_usage: [ '1.3.6.1.5.5.7.3.1', '1.3.6.1.5.5.7.3.2' ],
  serialNumber: '66593D57F20CBC573E433381B5FEC280',
  raw: <Buffer ... > }

tlsSocket.getPeerFinished()

Ajouté dans : v9.9.0

• Retourne : <Buffer> | <undefined> Le dernier message Finished qui est attendu ou qui a été effectivement reçu du socket dans le cadre d’une négociation SSL/TLS, ou undefined s’il n’y a pas de message Finished jusqu’à présent.

Étant donné que les messages Finished sont des condensés de message de la négociation complète (avec un total de 192 bits pour TLS 1.0 et plus pour SSL 3.0), ils peuvent être utilisés pour des procédures d’authentification externe lorsque l’authentification fournie par SSL/TLS n’est pas souhaitée ou n’est pas suffisante.

Correspond à la routine SSL_get_peer_finished dans OpenSSL et peut être utilisé pour implémenter la liaison de canal tls-unique de RFC 5929.

tlsSocket.getPeerX509Certificate()

Ajouté dans : v15.9.0

• Retourne : <X509Certificate>

Retourne le certificat de l’homologue sous la forme d’un objet <X509Certificate>.

S’il n’y a pas de certificat homologue, ou si le socket a été détruit, undefined sera retourné.

tlsSocket.getProtocol()

Ajouté dans : v5.7.0

• Retourne : <string> | <null>

Retourne une chaîne de caractères contenant la version du protocole SSL/TLS négociée de la connexion actuelle. La valeur 'unknown' sera retournée pour les sockets connectés qui n’ont pas terminé le processus de négociation. La valeur null sera retournée pour les sockets serveur ou les sockets client déconnectés.

Les versions de protocole sont :

• 'SSLv3'
• 'TLSv1'
• 'TLSv1.1'
• 'TLSv1.2'
• 'TLSv1.3'

Consultez la documentation OpenSSL SSL_get_version pour plus d’informations.

tlsSocket.getSession()

Ajouté dans : v0.11.4

• <Buffer>

Retourne les données de session TLS ou undefined si aucune session n’a été négociée. Sur le client, les données peuvent être fournies à l’option session de tls.connect() pour reprendre la connexion. Sur le serveur, cela peut être utile pour le débogage.

Voir Reprise de Session pour plus d’informations.

Remarque : getSession() ne fonctionne que pour TLSv1.2 et les versions antérieures. Pour TLSv1.3, les applications doivent utiliser l’événement 'session' (il fonctionne également pour TLSv1.2 et les versions antérieures).

tlsSocket.getSharedSigalgs()

Ajouté dans : v12.11.0

• Retourne : <Array> Liste des algorithmes de signature partagés entre le serveur et le client par ordre de préférence décroissante.

Voir SSL_get_shared_sigalgs pour plus d'informations.

tlsSocket.getTLSTicket()

Ajouté dans : v0.11.4

• <Buffer>

Pour un client, retourne le ticket de session TLS s'il est disponible, ou undefined. Pour un serveur, retourne toujours undefined.

Cela peut être utile pour le débogage.

Voir Reprise de Session pour plus d'informations.

tlsSocket.getX509Certificate()

Ajouté dans : v15.9.0

• Retourne : <X509Certificate>

Retourne le certificat local comme un objet <X509Certificate>.

S'il n'y a pas de certificat local, ou que le socket a été détruit, undefined sera retourné.

tlsSocket.isSessionReused()

Ajouté dans : v0.5.6

• Retourne : <boolean> true si la session a été réutilisée, false sinon.

Voir Reprise de Session pour plus d'informations.

tlsSocket.localAddress

Ajouté dans : v0.11.4

• <string>

Retourne la représentation sous forme de chaîne de l'adresse IP locale.

tlsSocket.localPort

Ajouté dans : v0.11.4

• <integer>

Retourne la représentation numérique du port local.

tlsSocket.remoteAddress

Ajouté dans : v0.11.4

• <string>

Retourne la représentation sous forme de chaîne de l'adresse IP distante. Par exemple, '74.125.127.100' ou '2001:4860:a005::68'.

tlsSocket.remoteFamily

Ajouté dans : v0.11.4

• <string>

Retourne la représentation sous forme de chaîne de caractères de la famille d'adresses IP distante. 'IPv4' ou 'IPv6'.

tlsSocket.remotePort

Ajouté dans : v0.11.4

• <integer>

Retourne la représentation numérique du port distant. Par exemple, 443.

tlsSocket.renegotiate(options, callback)

[Historique]

Version	Modifications
v18.0.0	Le passage d'un rappel invalide à l'argument callback génère désormais ERR_INVALID_ARG_TYPE au lieu de ERR_INVALID_CALLBACK.
v0.11.8	Ajouté dans : v0.11.8

• options <Object>

  • rejectUnauthorized <boolean> Si la valeur n'est pas false, le certificat du serveur est vérifié par rapport à la liste des autorités de certification fournies. Un événement 'error' est émis si la vérification échoue ; err.code contient le code d'erreur OpenSSL. Par défaut: true.
  • requestCert

• callback <Function> Si renegotiate() a retourné true, le rappel est attaché une seule fois à l'événement 'secure'. Si renegotiate() a retourné false, callback sera appelé dans le prochain cycle avec une erreur, sauf si le tlsSocket a été détruit, auquel cas callback ne sera pas appelé du tout.

• Retourne: <boolean> true si la renégociation a été initiée, false sinon.

La méthode tlsSocket.renegotiate() initie un processus de renégociation TLS. Une fois terminée, la fonction callback recevra un seul argument qui est soit une Error (si la demande a échoué) soit null.

Cette méthode peut être utilisée pour demander le certificat d'un pair après que la connexion sécurisée a été établie.

Lorsqu'il est exécuté en tant que serveur, le socket sera détruit avec une erreur après le délai d'attente handshakeTimeout.

Pour TLSv1.3, la renégociation ne peut pas être initiée, elle n'est pas prise en charge par le protocole.

tlsSocket.setKeyCert(context)

Ajouté dans : v22.5.0, v20.17.0

• context <Object> | <tls.SecureContext> Un objet contenant au moins les propriétés key et cert des options de tls.createSecureContext(), ou un objet de contexte TLS créé avec tls.createSecureContext() lui-même.

La méthode tlsSocket.setKeyCert() définit la clé privée et le certificat à utiliser pour le socket. Ceci est principalement utile si vous souhaitez sélectionner un certificat de serveur à partir de la ALPNCallback d'un serveur TLS.

tlsSocket.setMaxSendFragment(size)

Ajouté dans : v0.11.11

• size <number> La taille maximale du fragment TLS. La valeur maximale est 16384. Par défaut : 16384.
• Renvoie : <boolean>

La méthode tlsSocket.setMaxSendFragment() définit la taille maximale du fragment TLS. Renvoie true si la définition de la limite a réussi ; false sinon.

Des tailles de fragment plus petites diminuent la latence de mise en mémoire tampon sur le client : les fragments plus grands sont mis en mémoire tampon par la couche TLS jusqu'à ce que l'ensemble du fragment soit reçu et que son intégrité soit vérifiée ; les grands fragments peuvent s'étendre sur plusieurs allers-retours et leur traitement peut être retardé en raison d'une perte ou d'un réordonnancement de paquets. Cependant, des fragments plus petits ajoutent des octets de trame TLS supplémentaires et une surcharge CPU, ce qui peut diminuer le débit global du serveur.

tls.checkServerIdentity(hostname, cert)

[Historique]

Version	Changements
v17.3.1, v16.13.2, v14.18.3, v12.22.9	La prise en charge des noms alternatifs de sujet uniformResourceIdentifier a été désactivée en réponse à la CVE-2021-44531.
v0.8.4	Ajouté dans : v0.8.4

• hostname <string> Le nom d'hôte ou l'adresse IP par rapport auquel vérifier le certificat.
• cert <Object> Un objet de certificat représentant le certificat de l'homologue.
• Renvoie : <Error> | <undefined>

Vérifie que le certificat cert est émis pour hostname.

Renvoie un objet <Error>, en le remplissant avec reason, host et cert en cas d'échec. En cas de succès, renvoie <undefined>.

Cette fonction est destinée à être utilisée en combinaison avec l'option checkServerIdentity qui peut être passée à tls.connect() et fonctionne donc sur un objet de certificat. Pour d'autres objectifs, envisagez d'utiliser plutôt x509.checkHost().

Cette fonction peut être remplacée en fournissant une fonction alternative comme option options.checkServerIdentity qui est passée à tls.connect(). La fonction de remplacement peut bien sûr appeler tls.checkServerIdentity() pour augmenter les vérifications effectuées avec une vérification supplémentaire.

Cette fonction n'est appelée que si le certificat a passé toutes les autres vérifications, telles que l'émission par une autorité de certification de confiance (options.ca).

Les versions antérieures de Node.js acceptaient de manière incorrecte les certificats pour un hostname donné si un nom alternatif de sujet uniformResourceIdentifier correspondant était présent (voir CVE-2021-44531). Les applications qui souhaitent accepter les noms alternatifs de sujet uniformResourceIdentifier peuvent utiliser une fonction options.checkServerIdentity personnalisée qui implémente le comportement souhaité.

tls.connect(options[, callback])

[Historique]

Version	Changements
v15.1.0, v14.18.0	Ajout de l'option onread.
v14.1.0, v13.14.0	L'option highWaterMark est désormais acceptée.
v13.6.0, v12.16.0	L'option pskCallback est désormais prise en charge.
v12.9.0	Prise en charge de l'option allowHalfOpen.
v12.4.0	L'option hints est désormais prise en charge.
v12.2.0	L'option enableTrace est désormais prise en charge.
v11.8.0, v10.16.0	L'option timeout est désormais prise en charge.
v8.0.0	L'option lookup est désormais prise en charge.
v8.0.0	L'option ALPNProtocols peut désormais être un TypedArray ou un DataView.
v5.0.0	Les options ALPN sont désormais prises en charge.
v5.3.0, v4.7.0	L'option secureContext est désormais prise en charge.
v0.11.3	Ajoutée dans : v0.11.3

• options <Object>

  • enableTrace: Voir tls.createServer()
  • host <string> Hôte auquel le client doit se connecter. Par défaut : 'localhost'.
  • port <number> Port auquel le client doit se connecter.
  • path <string> Crée une connexion de socket Unix vers le chemin spécifié. Si cette option est spécifiée, host et port sont ignorés.
  • socket <stream.Duplex> Établit une connexion sécurisée sur un socket donné au lieu de créer un nouveau socket. Il s'agit généralement d'une instance de net.Socket, mais tout flux Duplex est autorisé. Si cette option est spécifiée, path, host et port sont ignorés, à l'exception de la validation du certificat. Habituellement, un socket est déjà connecté lorsqu'il est passé à tls.connect(), mais il peut être connecté ultérieurement. La connexion/déconnexion/destruction du socket est la responsabilité de l'utilisateur ; l'appel de tls.connect() n'entraînera pas l'appel de net.connect().
  • allowHalfOpen <boolean> Si la valeur est définie sur false, le socket terminera automatiquement le côté inscriptible lorsque le côté lisible se termine. Si l'option socket est définie, cette option n'a aucun effet. Voir l'option allowHalfOpen de net.Socket pour plus de détails. Par défaut : false.
  • rejectUnauthorized <boolean> Si la valeur n'est pas false, le certificat du serveur est vérifié par rapport à la liste des autorités de certification fournies. Un événement 'error' est émis si la vérification échoue ; err.code contient le code d'erreur OpenSSL. Par défaut : true.
  • pskCallback <Function> Pour la négociation TLS-PSK, voir Clés pré-partagées.
  • ALPNProtocols : <string[]> | <Buffer[]> | <TypedArray[]> | <DataView[]> | <Buffer> | <TypedArray> | <DataView> Un tableau de chaînes, de Buffers, de TypedArrays ou de DataViews, ou un seul Buffer, TypedArray ou DataView contenant les protocoles ALPN pris en charge. Les Buffers doivent avoir le format [len][nom][len][nom]... par exemple '\x08http/1.1\x08http/1.0', où l'octet len est la longueur du nom du protocole suivant. Il est généralement beaucoup plus simple de passer un tableau, par exemple ['http/1.1', 'http/1.0']. Les protocoles situés plus haut dans la liste ont une préférence plus élevée que ceux situés plus bas.
  • servername: <string> Nom du serveur pour l'extension TLS SNI (Server Name Indication). Il s'agit du nom de l'hôte auquel la connexion est établie et doit être un nom d'hôte et non une adresse IP. Il peut être utilisé par un serveur multi-hébergé pour choisir le certificat correct à présenter au client. Voir l'option SNICallback pour tls.createServer().
  • checkServerIdentity(servername, cert) <Function> Une fonction de rappel à utiliser (au lieu de la fonction intégrée tls.checkServerIdentity()) lors de la vérification du nom d'hôte du serveur (ou du servername fourni lorsque celui-ci est explicitement défini) par rapport au certificat. Elle doit renvoyer une <Error> si la vérification échoue. La méthode doit renvoyer undefined si le servername et le cert sont vérifiés.
  • session <Buffer> Une instance Buffer contenant la session TLS.
  • minDHSize <number> Taille minimale du paramètre DH en bits pour accepter une connexion TLS. Lorsqu'un serveur propose un paramètre DH dont la taille est inférieure à minDHSize, la connexion TLS est détruite et une erreur est levée. Par défaut : 1024.
  • highWaterMark : <number> Cohérent avec le paramètre highWaterMark du flux lisible. Par défaut : 16 * 1024.
  • secureContext : Objet de contexte TLS créé avec tls.createSecureContext(). Si un secureContext n'est pas fourni, un sera créé en passant l'objet options entier à tls.createSecureContext().
  • onread <Object> Si l'option socket est manquante, les données entrantes sont stockées dans un seul buffer et transmises au callback fourni lorsque des données arrivent sur le socket. Sinon, l'option est ignorée. Voir l'option onread de net.Socket pour plus de détails.
  • ... : options de tls.createSecureContext() qui sont utilisées si l'option secureContext est manquante, sinon elles sont ignorées.
  • ... : Toute option de socket.connect() qui n'est pas déjà répertoriée.

• callback <Function>

• Retourne : <tls.TLSSocket>

La fonction callback, si elle est spécifiée, sera ajoutée comme écouteur de l'événement 'secureConnect'.

tls.connect() retourne un objet tls.TLSSocket.

Contrairement à l'API https, tls.connect() n'active pas l'extension SNI (Server Name Indication) par défaut, ce qui peut amener certains serveurs à renvoyer un certificat incorrect ou à rejeter complètement la connexion. Pour activer SNI, définissez l'option servername en plus de host.

L'exemple suivant illustre un client pour l'exemple de serveur d'écho de tls.createServer() :

ESM

// Suppose qu'un serveur d'écho écoute sur le port 8000.
import { connect } from 'node:tls'
import { readFileSync } from 'node:fs'
import { stdin } from 'node:process'

const options = {
  // Nécessaire uniquement si le serveur exige l'authentification par certificat client.
  key: readFileSync('client-key.pem'),
  cert: readFileSync('client-cert.pem'),

  // Nécessaire uniquement si le serveur utilise un certificat auto-signé.
  ca: [readFileSync('server-cert.pem')],

  // Nécessaire uniquement si le certificat du serveur n'est pas pour « localhost ».
  checkServerIdentity: () => {
    return null
  },
}

const socket = connect(8000, options, () => {
  console.log('client connected', socket.authorized ? 'authorized' : 'unauthorized')
  stdin.pipe(socket)
  stdin.resume()
})
socket.setEncoding('utf8')
socket.on('data', data => {
  console.log(data)
})
socket.on('end', () => {
  console.log('server ends connection')
})

CJS

// Suppose qu'un serveur d'écho écoute sur le port 8000.
const { connect } = require('node:tls')
const { readFileSync } = require('node:fs')

const options = {
  // Nécessaire uniquement si le serveur exige l'authentification par certificat client.
  key: readFileSync('client-key.pem'),
  cert: readFileSync('client-cert.pem'),

  // Nécessaire uniquement si le serveur utilise un certificat auto-signé.
  ca: [readFileSync('server-cert.pem')],

  // Nécessaire uniquement si le certificat du serveur n'est pas pour « localhost ».
  checkServerIdentity: () => {
    return null
  },
}

const socket = connect(8000, options, () => {
  console.log('client connected', socket.authorized ? 'authorized' : 'unauthorized')
  process.stdin.pipe(socket)
  process.stdin.resume()
})
socket.setEncoding('utf8')
socket.on('data', data => {
  console.log(data)
})
socket.on('end', () => {
  console.log('server ends connection')
})

Pour générer le certificat et la clé pour cet exemple, exécutez :

openssl req -x509 -newkey rsa:2048 -nodes -sha256 -subj '/CN=localhost' \
  -keyout client-key.pem -out client-cert.pem

Ensuite, pour générer le certificat server-cert.pem pour cet exemple, exécutez :

openssl pkcs12 -certpbe AES-256-CBC -export -out server-cert.pem \
  -inkey client-key.pem -in client-cert.pem

tls.connect(path[, options][, callback])

Ajouté dans : v0.11.3

• path <string> Valeur par défaut pour options.path.
• options <Object> Voir tls.connect().
• callback <Function> Voir tls.connect().
• Retourne : <tls.TLSSocket>

Identique à tls.connect() sauf que path peut être fourni en argument au lieu d'une option.

Une option de chemin, si spécifiée, aura priorité sur l'argument de chemin.

tls.connect(port[, host][, options][, callback])

Ajouté dans : v0.11.3

• port <number> Valeur par défaut pour options.port.
• host <string> Valeur par défaut pour options.host.
• options <Object> Voir tls.connect().
• callback <Function> Voir tls.connect().
• Retourne : <tls.TLSSocket>

Identique à tls.connect() sauf que port et host peuvent être fournis en arguments au lieu d'options.

Une option de port ou d'hôte, si spécifiée, aura priorité sur tout argument de port ou d'hôte.

tls.createSecureContext([options])

[Historique]

Version	Modifications
v22.9.0, v20.18.0	L'option allowPartialTrustChain a été ajoutée.
v22.4.0, v20.16.0	Les options clientCertEngine, privateKeyEngine et privateKeyIdentifier dépendent de la prise en charge du moteur personnalisé dans OpenSSL, ce qui est obsolète dans OpenSSL 3.
v19.8.0, v18.16.0	L'option dhparam peut maintenant être définie sur 'auto' pour activer DHE avec des paramètres connus appropriés.
v12.12.0	Ajout des options privateKeyIdentifier et privateKeyEngine pour obtenir la clé privée d'un moteur OpenSSL.
v12.11.0	Ajout de l'option sigalgs pour remplacer les algorithmes de signature pris en charge.
v12.0.0	Prise en charge de TLSv1.3 ajoutée.
v11.5.0	L'option ca: prend maintenant en charge BEGIN TRUSTED CERTIFICATE.
v11.4.0, v10.16.0	minVersion et maxVersion peuvent être utilisés pour restreindre les versions de protocole TLS autorisées.
v10.0.0	ecdhCurve ne peut plus être défini sur false en raison d'un changement dans OpenSSL.
v9.3.0	Le paramètre options peut maintenant inclure clientCertEngine.
v9.0.0	L'option ecdhCurve peut maintenant être plusieurs noms de courbe séparés par des ':' ou 'auto'.
v7.3.0	Si l'option key est un tableau, les entrées individuelles n'ont plus besoin d'une propriété passphrase. Les entrées Array peuvent également être simplement des string ou des Buffer maintenant.
v5.2.0	L'option ca peut maintenant être une seule chaîne contenant plusieurs certificats CA.
v0.11.13	Ajouté dans : v0.11.13

• options <Object>
  • allowPartialTrustChain <boolean> Traiter les certificats intermédiaires (non auto-signés) de la liste des certificats CA de confiance comme étant approuvés.
  • ca <string> | <string[]> | <Buffer> | <Buffer[]> Remplacer éventuellement les certificats CA approuvés. Par défaut, les CA bien connues gérées par Mozilla sont approuvées. Les CA de Mozilla sont complètement remplacées lorsque les CA sont explicitement spécifiées à l'aide de cette option. La valeur peut être une chaîne ou un Buffer, ou un Array de chaînes et/ou de Buffer. Toute chaîne ou Buffer peut contenir plusieurs CA PEM concaténées. Le certificat du pair doit être chaînable à une CA approuvée par le serveur pour que la connexion soit authentifiée. Lorsque vous utilisez des certificats qui ne sont pas chaînables à une CA bien connue, la CA du certificat doit être explicitement spécifiée comme approuvée, sinon la connexion ne pourra pas s'authentifier. Si le pair utilise un certificat qui ne correspond pas ou ne fait pas référence à l'une des CA par défaut, utilisez l'option ca pour fournir un certificat CA auquel le certificat du pair peut correspondre ou se rattacher. Pour les certificats auto-signés, le certificat est sa propre CA et doit être fourni. Pour les certificats codés PEM, les types pris en charge sont "TRUSTED CERTIFICATE", "X509 CERTIFICATE" et "CERTIFICATE". Voir aussi tls.rootCertificates.
  • cert <string> | <string[]> | <Buffer> | <Buffer[]> Chaînes de certificats au format PEM. Une chaîne de certificats doit être fournie par clé privée. Chaque chaîne de certificats doit comprendre le certificat au format PEM pour une clé privée fournie, suivi des certificats intermédiaires (le cas échéant), dans l'ordre, et sans inclure l'autorité de certification racine (l'autorité de certification racine doit être préalablement connue du pair, voir ca). Lorsque vous fournissez plusieurs chaînes de certificats, elles ne doivent pas nécessairement être dans le même ordre que leurs clés privées dans key. Si les certificats intermédiaires ne sont pas fournis, le pair ne pourra pas valider le certificat et la négociation échouera.
  • sigalgs <string> Liste d'algorithmes de signature pris en charge séparés par des deux-points. La liste peut contenir des algorithmes de hachage (SHA256, MD5, etc.), des algorithmes de clé publique (RSA-PSS, ECDSA, etc.), une combinaison des deux (par exemple : 'RSA+SHA384') ou des noms de schémas TLS v1.3 (par exemple : rsa_pss_pss_sha512). Consultez les pages de manuel OpenSSL pour plus d'informations.
  • ciphers <string> Spécification de la suite de chiffrement, remplaçant la valeur par défaut. Pour plus d'informations, consultez Modification de la suite de chiffrement TLS par défaut. Les chiffrements autorisés peuvent être obtenus via tls.getCiphers(). Les noms de chiffrement doivent être en majuscules pour qu'OpenSSL les accepte.
  • clientCertEngine <string> Nom d'un moteur OpenSSL qui peut fournir le certificat client. Déprécié.
  • crl <string> | <string[]> | <Buffer> | <Buffer[]> CRL (listes de révocation de certificats) au format PEM.
  • dhparam <string> | <Buffer> 'auto' ou paramètres Diffie-Hellman personnalisés, requis pour les secret direct parfait non ECDHE. S'il est omis ou non valide, les paramètres sont silencieusement ignorés et les chiffrements DHE ne seront pas disponibles. Le secret direct parfait basé sur ECDHE sera toujours disponible.
  • ecdhCurve <string> Une chaîne décrivant une courbe nommée ou une liste de NID ou de noms de courbe séparés par des deux-points, par exemple : P-521:P-384:P-256, à utiliser pour l'accord de clé ECDH. Défini sur auto pour sélectionner la courbe automatiquement. Utilisez crypto.getCurves() pour obtenir une liste des noms de courbe disponibles. Sur les versions récentes, openssl ecparam -list_curves affichera également le nom et la description de chaque courbe elliptique disponible. Par défaut : tls.DEFAULT_ECDH_CURVE.
  • honorCipherOrder <boolean> Essayer d'utiliser les préférences de suite de chiffrement du serveur au lieu de celles du client. Lorsque true, entraîne la définition de SSL_OP_CIPHER_SERVER_PREFERENCE dans secureOptions, voir Options OpenSSL pour plus d'informations.
  • key <string> | <string[]> | <Buffer> | <Buffer[]> | <Object[]> Clés privées au format PEM. PEM permet aux clés privées d'être cryptées. Les clés cryptées seront décryptées avec options.passphrase. Plusieurs clés utilisant différents algorithmes peuvent être fournies sous forme de tableau de chaînes ou de tampons de clés non cryptés, ou sous forme de tableau d'objets de la forme {pem: \<string|buffer\>[, passphrase: \<string\>]}. La forme objet ne peut se produire que dans un tableau. object.passphrase est facultatif. Les clés cryptées seront décryptées avec object.passphrase si fourni, ou options.passphrase si ce n'est pas le cas.
  • privateKeyEngine <string> Nom d'un moteur OpenSSL pour obtenir la clé privée. Doit être utilisé avec privateKeyIdentifier. Déprécié.
  • privateKeyIdentifier <string> Identifiant d'une clé privée gérée par un moteur OpenSSL. Doit être utilisé avec privateKeyEngine. Ne doit pas être défini avec key, car les deux options définissent une clé privée de différentes manières. Déprécié.
  • maxVersion <string> Définir éventuellement la version TLS maximale à autoriser. L'une des valeurs 'TLSv1.3', 'TLSv1.2', 'TLSv1.1' ou 'TLSv1'. Ne peut pas être spécifiée avec l'option secureProtocol ; utilisez l'une ou l'autre. Par défaut : tls.DEFAULT_MAX_VERSION.
  • minVersion <string> Définir éventuellement la version TLS minimale à autoriser. L'une des valeurs 'TLSv1.3', 'TLSv1.2', 'TLSv1.1' ou 'TLSv1'. Ne peut pas être spécifiée avec l'option secureProtocol ; utilisez l'une ou l'autre. Évitez de définir une valeur inférieure à TLSv1.2, mais cela peut être nécessaire pour l'interopérabilité. Les versions antérieures à TLSv1.2 peuvent nécessiter une rétrogradation du niveau de sécurité OpenSSL. Par défaut : tls.DEFAULT_MIN_VERSION.
  • passphrase <string> Mot de passe partagé utilisé pour une seule clé privée et/ou un PFX.
  • pfx <string> | <string[]> | <Buffer> | <Buffer[]> | <Object[]> Clé privée et chaîne de certificats codées PFX ou PKCS12. pfx est une alternative à la fourniture de key et cert individuellement. PFX est généralement crypté, si c'est le cas, passphrase sera utilisé pour le décrypter. Plusieurs PFX peuvent être fournis sous forme de tableau de tampons PFX non cryptés, ou sous forme de tableau d'objets de la forme {buf: \<string|buffer\>[, passphrase: \<string\>]}. La forme objet ne peut se produire que dans un tableau. object.passphrase est facultatif. Les PFX cryptés seront décryptés avec object.passphrase si fourni, ou options.passphrase si ce n'est pas le cas.
  • secureOptions <number> Affecter éventuellement le comportement du protocole OpenSSL, ce qui n'est généralement pas nécessaire. Cela doit être utilisé avec précaution, voire pas du tout ! La valeur est un masque de bits numérique des options SSL_OP_* des options OpenSSL.
  • secureProtocol <string> Mécanisme hérité pour sélectionner la version du protocole TLS à utiliser, il ne prend pas en charge le contrôle indépendant de la version minimale et maximale, et ne prend pas en charge la limitation du protocole à TLSv1.3. Utilisez minVersion et maxVersion à la place. Les valeurs possibles sont répertoriées comme SSL_METHODS, utilisez les noms de fonction comme chaînes. Par exemple, utilisez 'TLSv1_1_method' pour forcer la version TLS 1.1, ou 'TLS_method' pour autoriser n'importe quelle version du protocole TLS jusqu'à TLSv1.3. Il n'est pas recommandé d'utiliser des versions TLS inférieures à 1.2, mais cela peut être nécessaire pour l'interopérabilité. Par défaut : aucune, voir minVersion.
  • sessionIdContext <string> Identifiant opaque utilisé par les serveurs pour garantir que l'état de la session n'est pas partagé entre les applications. Inutilisé par les clients.
  • ticketKeys: <Buffer> 48 octets de données pseudo-aléatoires cryptographiquement robustes. Consultez Reprise de session pour plus d'informations.
  • sessionTimeout <number> Le nombre de secondes après lequel une session TLS créée par le serveur ne sera plus réutilisable. Consultez Reprise de session pour plus d'informations. Par défaut : 300.

tls.createServer() définit la valeur par défaut de l'option honorCipherOrder sur true, les autres API qui créent des contextes sécurisés la laissent non définie.

tls.createServer() utilise une valeur de hachage SHA1 tronquée de 128 bits générée à partir de process.argv comme valeur par défaut de l'option sessionIdContext, les autres API qui créent des contextes sécurisés n'ont pas de valeur par défaut.

La méthode tls.createSecureContext() crée un objet SecureContext. Il peut être utilisé comme argument pour plusieurs API tls, telles que server.addContext(), mais n'a aucune méthode publique. Le constructeur tls.Server et la méthode tls.createServer() ne prennent pas en charge l'option secureContext.

Une clé est nécessaire pour les chiffrements qui utilisent des certificats. key ou pfx peut être utilisé pour la fournir.

Si l'option ca n'est pas donnée, Node.js utilisera par défaut la liste d'autorités de certification publiquement approuvées par Mozilla.

Les paramètres DHE personnalisés sont déconseillés en faveur de la nouvelle option dhparam: 'auto'. Lorsqu'elle est définie sur 'auto', des paramètres DHE bien connus d'une résistance suffisante seront sélectionnés automatiquement. Sinon, si nécessaire, openssl dhparam peut être utilisé pour créer des paramètres personnalisés. La longueur de la clé doit être supérieure ou égale à 1024 bits, sinon une erreur sera levée. Bien que 1024 bits soient autorisés, utilisez 2048 bits ou plus pour une sécurité accrue.

tls.createSecurePair([context][, isServer][, requestCert][, rejectUnauthorized][, options])

[Historique]

Version	Modifications
v5.0.0	Les options ALPN sont désormais prises en charge.
v0.11.3	Déprécié depuis : v0.11.3
v0.3.2	Ajouté dans : v0.3.2

[Stable : 0 - Déprécié]

Stable : 0 Stabilité : 0 - Déprécié : Utilisez tls.TLSSocket à la place.

• context <Objet> Un objet de contexte sécurisé tel que renvoyé par tls.createSecureContext()
• isServer <booléen> true pour spécifier que cette connexion TLS doit être ouverte en tant que serveur.
• requestCert <booléen> true pour spécifier si un serveur doit demander un certificat à un client qui se connecte. S'applique uniquement lorsque isServer est true.
• rejectUnauthorized <booléen> Si ce n'est pas false, un serveur rejette automatiquement les clients ayant des certificats invalides. S'applique uniquement lorsque isServer est true.
• options
  • enableTrace: Voir tls.createServer()
  • secureContext: Un objet de contexte TLS provenant de tls.createSecureContext()
  • isServer: Si true, la socket TLS sera instanciée en mode serveur. Par défaut : false.
  • server <net.Server> Une instance net.Server
  • requestCert: Voir tls.createServer()
  • rejectUnauthorized: Voir tls.createServer()
  • ALPNProtocols: Voir tls.createServer()
  • SNICallback: Voir tls.createServer()
  • session <Buffer> Une instance Buffer contenant une session TLS.
  • requestOCSP <booléen> Si true, spécifie que l'extension de requête d'état OCSP sera ajoutée au client hello et qu'un événement 'OCSPResponse' sera émis sur la socket avant d'établir une communication sécurisée.

Crée un nouvel objet de paire sécurisée avec deux flux, dont l'un lit et écrit les données chiffrées et l'autre lit et écrit les données en clair. Généralement, le flux chiffré est redirigé vers/depuis un flux de données chiffrées entrant et celui en clair est utilisé en remplacement du flux chiffré initial.

tls.createSecurePair() renvoie un objet tls.SecurePair avec les propriétés de flux cleartext et encrypted.

L'utilisation de cleartext a la même API que tls.TLSSocket.

La méthode tls.createSecurePair() est désormais dépréciée au profit de tls.TLSSocket(). Par exemple, le code :

pair = tls.createSecurePair(/* ... */)
pair.encrypted.pipe(socket)
socket.pipe(pair.encrypted)

peut être remplacé par :

secureSocket = tls.TLSSocket(socket, options)

où secureSocket a la même API que pair.cleartext.

tls.createServer([options][, secureConnectionListener])

[Historique]

Version	Modifications
v22.4.0, v20.16.0	L'option clientCertEngine dépend de la prise en charge des moteurs personnalisés dans OpenSSL, ce qui est obsolète dans OpenSSL 3.
v19.0.0	Si ALPNProtocols est défini, les connexions entrantes qui envoient une extension ALPN sans protocoles compatibles sont terminées par une alerte fatale no_application_protocol.
v20.4.0, v18.19.0	Le paramètre options peut désormais inclure ALPNCallback.
v12.3.0	Le paramètre options prend désormais en charge les options net.createServer().
v9.3.0	Le paramètre options peut désormais inclure clientCertEngine.
v8.0.0	L'option ALPNProtocols peut désormais être un TypedArray ou un DataView.
v5.0.0	Les options ALPN sont désormais prises en charge.
v0.3.2	Ajouté dans : v0.3.2

• options <Objet>

  • ALPNProtocols: <tableau de chaînes de caractères> | <tableau de Buffer> | <tableau de TypedArray> | <tableau de DataView> | <Buffer> | <TypedArray> | <DataView> Un tableau de chaînes de caractères, de Buffer, de TypedArray ou de DataView, ou un seul Buffer, TypedArray ou DataView contenant les protocoles ALPN compatibles. Les Buffer doivent avoir le format [longueur][nom][longueur][nom]... par exemple : 0x05hello0x05world, où le premier octet est la longueur du nom du protocole suivant. Utiliser un tableau est généralement beaucoup plus simple, par exemple : ['hello', 'world']. (Les protocoles doivent être ordonnés par priorité.)
  • ALPNCallback: <Fonction> Si défini, cette fonction sera appelée lorsqu'un client ouvre une connexion en utilisant l'extension ALPN. Un argument sera passé à la fonction de rappel : un objet contenant les champs servername et protocols, contenant respectivement le nom du serveur de l'extension SNI (le cas échéant) et un tableau de chaînes de noms de protocoles ALPN. La fonction de rappel doit retourner l'une des chaînes listées dans protocols, qui sera renvoyée au client comme protocole ALPN sélectionné, ou undefined pour rejeter la connexion avec une alerte fatale. Si une chaîne renvoyée ne correspond à aucun des protocoles ALPN du client, une erreur sera levée. Cette option ne peut pas être utilisée avec l'option ALPNProtocols, et la définition des deux options lèvera une erreur.
  • clientCertEngine <chaîne de caractères> Nom d'un moteur OpenSSL pouvant fournir le certificat client. Déprécié.
  • enableTrace <booléen> Si true, tls.TLSSocket.enableTrace() sera appelé sur les nouvelles connexions. La trace peut être activée après l'établissement de la connexion sécurisée, mais cette option doit être utilisée pour tracer la configuration de la connexion sécurisée. Défaut : false.
  • handshakeTimeout <nombre> Annule la connexion si l'échange de clés SSL/TLS ne se termine pas dans le nombre de millisecondes spécifié. Un événement 'tlsClientError' est émis sur l'objet tls.Server lorsqu'un échange de clés dépasse le délai imparti. Défaut : 120000 (120 secondes).
  • rejectUnauthorized <booléen> Si ce n'est pas false, le serveur rejettera toute connexion non autorisée avec la liste des autorités de certification fournies. Cette option n'a d'effet que si requestCert est true. Défaut : true.
  • requestCert <booléen> Si true, le serveur demandera un certificat aux clients qui se connectent et tentera de vérifier ce certificat. Défaut : false.
  • sessionTimeout <nombre> Le nombre de secondes après lequel une session TLS créée par le serveur ne sera plus réutilisable. Voir Reprise de session pour plus d'informations. Défaut : 300.
  • SNICallback(servername, callback) <Fonction> Une fonction qui sera appelée si le client prend en charge l'extension TLS SNI. Deux arguments seront passés lors de l'appel : servername et callback. callback est une fonction de rappel avec gestion des erreurs qui prend deux arguments optionnels : error et ctx. ctx, s'il est fourni, est une instance SecureContext. tls.createSecureContext() peut être utilisé pour obtenir un SecureContext approprié. Si callback est appelé avec un argument ctx faux, le contexte sécurisé par défaut du serveur sera utilisé. Si SNICallback n'a pas été fourni, la fonction de rappel par défaut avec l'API de haut niveau sera utilisée (voir ci-dessous).
  • ticketKeys: <Buffer> 48 octets de données pseudo-aléatoires cryptographiquement robustes. Voir Reprise de session pour plus d'informations.
  • pskCallback <Fonction> Pour la négociation TLS-PSK, voir Clés pré-partagées.
  • pskIdentityHint <chaîne de caractères> indice facultatif à envoyer à un client pour l'aider à sélectionner l'identité pendant la négociation TLS-PSK. Sera ignoré dans TLS 1.3. En cas d'échec de la définition de pskIdentityHint, 'tlsClientError' sera émis avec le code 'ERR_TLS_PSK_SET_IDENTITY_HINT_FAILED'.
  • ... : Toute option tls.createSecureContext() peut être fournie. Pour les serveurs, les options d'identité (pfx, key/cert ou pskCallback) sont généralement nécessaires.
  • ... : Toute option net.createServer() peut être fournie.

• secureConnectionListener <Fonction>

• Retourne : <tls.Server>

Crée un nouveau tls.Server. La fonction secureConnectionListener, si elle est fournie, est automatiquement définie comme écouteur pour l'événement 'secureConnection'.

L'option ticketKeys est automatiquement partagée entre les processus du module node:cluster.

Voici un exemple de serveur echo simple :

ESM

import { createServer } from 'node:tls'
import { readFileSync } from 'node:fs'

const options = {
  key: readFileSync('server-key.pem'),
  cert: readFileSync('server-cert.pem'),

  // Ceci est nécessaire uniquement si l'authentification par certificat client est utilisée.
  requestCert: true,

  // Ceci est nécessaire uniquement si le client utilise un certificat auto-signé.
  ca: [readFileSync('client-cert.pem')],
}

const server = createServer(options, socket => {
  console.log('serveur connecté', socket.authorized ? 'autorisé' : 'non autorisé')
  socket.write('bienvenue !\n')
  socket.setEncoding('utf8')
  socket.pipe(socket)
})
server.listen(8000, () => {
  console.log('serveur lié')
})

CJS

const { createServer } = require('node:tls')
const { readFileSync } = require('node:fs')

const options = {
  key: readFileSync('server-key.pem'),
  cert: readFileSync('server-cert.pem'),

  // Ceci est nécessaire uniquement si l'authentification par certificat client est utilisée.
  requestCert: true,

  // Ceci est nécessaire uniquement si le client utilise un certificat auto-signé.
  ca: [readFileSync('client-cert.pem')],
}

const server = createServer(options, socket => {
  console.log('serveur connecté', socket.authorized ? 'autorisé' : 'non autorisé')
  socket.write('bienvenue !\n')
  socket.setEncoding('utf8')
  socket.pipe(socket)
})
server.listen(8000, () => {
  console.log('serveur lié')
})

Pour générer le certificat et la clé pour cet exemple, exécutez :

openssl req -x509 -newkey rsa:2048 -nodes -sha256 -subj '/CN=localhost' \
  -keyout server-key.pem -out server-cert.pem

Ensuite, pour générer le certificat client-cert.pem pour cet exemple, exécutez :

openssl pkcs12 -certpbe AES-256-CBC -export -out client-cert.pem \
  -inkey server-key.pem -in server-cert.pem

Le serveur peut être testé en s'y connectant en utilisant le client exemple de tls.connect().

tls.getCiphers()

Ajouté dans : v0.10.2

• Retourne : <string[]>

Retourne un tableau contenant les noms des chiffrements TLS pris en charge. Les noms sont en minuscules pour des raisons historiques, mais doivent être en majuscules pour être utilisés dans l’option ciphers de tls.createSecureContext().

Tous les chiffrements pris en charge ne sont pas activés par défaut. Voir Modification de la suite de chiffrements TLS par défaut.

Les noms de chiffrements commençant par 'tls_' sont pour TLSv1.3, tous les autres sont pour TLSv1.2 et versions antérieures.

console.log(tls.getCiphers()) // ['aes128-gcm-sha256', 'aes128-sha', ...]

tls.rootCertificates

Ajouté dans : v12.3.0

• <string[]>

Un tableau immuable de chaînes représentant les certificats racines (au format PEM) du magasin d’autorités de certification Mozilla fourni avec la version actuelle de Node.js.

Le magasin d’autorités de certification fourni par Node.js est un instantané du magasin d’autorités de certification Mozilla figé au moment de la publication. Il est identique sur toutes les plates-formes prises en charge.

tls.DEFAULT_ECDH_CURVE

[Historique]

Version	Modifications
v10.0.0	Valeur par défaut changée en 'auto'.
v0.11.13	Ajouté dans : v0.11.13

Le nom de courbe par défaut à utiliser pour l’accord de clé ECDH sur un serveur tls. La valeur par défaut est 'auto'. Voir tls.createSecureContext() pour plus d’informations.

tls.DEFAULT_MAX_VERSION

Ajouté dans : v11.4.0

• <string> La valeur par défaut de l’option maxVersion de tls.createSecureContext(). Elle peut prendre l’une des versions de protocole TLS prises en charge, 'TLSv1.3', 'TLSv1.2', 'TLSv1.1', ou 'TLSv1'. Par défaut : 'TLSv1.3', sauf modification via les options CLI. L’utilisation de --tls-max-v1.2 définit la valeur par défaut sur 'TLSv1.2'. L’utilisation de --tls-max-v1.3 définit la valeur par défaut sur 'TLSv1.3'. Si plusieurs options sont fournies, la valeur maximale la plus élevée est utilisée.

tls.DEFAULT_MIN_VERSION

Ajouté dans : v11.4.0

• <string> La valeur par défaut de l'option minVersion de tls.createSecureContext(). Elle peut prendre n'importe laquelle des versions de protocole TLS prises en charge, 'TLSv1.3', 'TLSv1.2', 'TLSv1.1', ou 'TLSv1'. Les versions antérieures à TLSv1.2 peuvent nécessiter une rétrogradation du niveau de sécurité OpenSSL. Valeur par défaut : 'TLSv1.2', sauf modification via les options CLI. L'utilisation de --tls-min-v1.0 définit la valeur par défaut sur 'TLSv1'. L'utilisation de --tls-min-v1.1 définit la valeur par défaut sur 'TLSv1.1'. L'utilisation de --tls-min-v1.3 définit la valeur par défaut sur 'TLSv1.3'. Si plusieurs options sont fournies, la plus petite valeur minimale est utilisée.

tls.DEFAULT_CIPHERS

Ajouté dans : v19.8.0, v18.16.0

• <string> La valeur par défaut de l'option ciphers de tls.createSecureContext(). Elle peut prendre n'importe lequel des chiffrements OpenSSL pris en charge. La valeur par défaut correspond au contenu de crypto.constants.defaultCoreCipherList, sauf modification via les options CLI utilisant --tls-default-ciphers.