Концепции TLS/SSL

TLS/SSL — это инфраструктура открытых/закрытых ключей (PKI). В большинстве случаев каждый клиент и сервер должен иметь закрытый ключ.

Закрытые ключи можно генерировать различными способами. Пример ниже демонстрирует использование командной строки OpenSSL для генерации закрытого ключа RSA длиной 2048 бит:

openssl genrsa -out ryans-key.pem 2048

В TLS/SSL все серверы (и некоторые клиенты) должны иметь сертификат. Сертификаты являются открытыми ключами, соответствующими закрытому ключу, и подписаны цифровой подписью либо центром сертификации (ЦС), либо владельцем закрытого ключа (такие сертификаты называются «самоподписанными»). Первым шагом получения сертификата является создание файла запроса на подпись сертификата (CSR).

Для генерации CSR для закрытого ключа можно использовать командную строку OpenSSL:

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

После генерации файла CSR его можно отправить в центр сертификации для подписания или использовать для создания самоподписанного сертификата.

Создание самоподписанного сертификата с помощью командной строки OpenSSL показано в примере ниже:

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

После генерации сертификата его можно использовать для создания файла .pfx или .p12:

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

Где:

• in: подписанный сертификат
• inkey: связанный закрытый ключ
• certfile: объединение всех сертификатов ЦС (Certificate Authority) в один файл, например, cat ca1-cert.pem ca2-cert.pem > ca-cert.pem

Совершенная прямая секретность

Термин прямая секретность или совершенная прямая секретность описывает функцию методов согласования ключей (т. е. обмена ключами). То есть ключи сервера и клиента используются для согласования новых временных ключей, которые используются только для текущего сеанса связи. Практически это означает, что даже если закрытый ключ сервера скомпрометирован, перехваченная информация может быть расшифрована злоумышленниками только в том случае, если им удастся получить конкретную пару ключей, сгенерированных специально для этого сеанса.

Совершенная прямая секретность достигается случайной генерацией пары ключей для согласования ключей во время каждого рукопожатия TLS/SSL (в отличие от использования одного ключа для всех сеансов). Методы, реализующие эту технику, называются «эпизодическими».

В настоящее время для достижения совершенной прямой секретности обычно используются два метода (обратите внимание на добавленную букву «E» к традиционным аббревиатурам):

• DHE: Эпизодическая версия протокола согласования ключей Диффи-Хеллмана.
• ECDHE: Эпизодическая версия протокола согласования ключей Диффи-Хеллмана на эллиптических кривых.

Эпизодические методы могут иметь некоторые недостатки производительности, поскольку генерация ключей является ресурсоемкой операцией.

Для использования совершенной прямой секретности с DHE с помощью модуля tls необходимо сгенерировать параметры Диффи-Хеллмана и указать их с помощью параметра dhparam к tls.createSecureContext(). Следующий пример демонстрирует использование командной строки OpenSSL для генерации таких параметров:

openssl dhparam -outform PEM -out dhparam.pem 2048

Если используется совершенная прямая секретность с ECDHE, параметры Диффи-Хеллмана не требуются, и будет использоваться кривая ECDHE по умолчанию. Свойство ecdhCurve можно использовать при создании сервера TLS для указания списка поддерживаемых кривых, см. tls.createServer() для получения дополнительной информации.

Совершенная прямая секретность была необязательной до TLSv1.2, но не является необязательной для TLSv1.3, поскольку все наборы шифров TLSv1.3 используют ECDHE.

ALPN и SNI

ALPN (расширение для согласования протоколов прикладного уровня) и SNI (указание имени сервера) являются расширениями рукопожатия TLS:

• ALPN: позволяет использовать один сервер TLS для нескольких протоколов (HTTP, HTTP/2)
• SNI: позволяет использовать один сервер TLS для нескольких имен хостов с разными сертификатами SSL.

Предварительно общие ключи

Поддержка TLS-PSK доступна как альтернатива стандартной аутентификации на основе сертификатов. Она использует предварительно общий ключ вместо сертификатов для аутентификации соединения TLS, обеспечивая взаимную аутентификацию. TLS-PSK и инфраструктура открытых ключей не являются взаимоисключающими. Клиенты и серверы могут поддерживать оба, выбирая любой из них во время обычной фазы согласования шифров.

TLS-PSK является хорошим выбором только в том случае, если есть возможность безопасно обменяться ключом с каждым подключенным устройством, поэтому он не заменяет инфраструктуру открытых ключей (PKI) для большинства случаев использования TLS. Реализация TLS-PSK в OpenSSL в последние годы показала множество уязвимостей в безопасности, в основном потому, что она используется только небольшой частью приложений. Пожалуйста, рассмотрите все альтернативные решения перед переходом к шифрам PSK. При генерации PSK крайне важно использовать достаточную энтропию, как описано в RFC 4086. Получение общего секрета из пароля или других источников с низкой энтропией небезопасно.

Шифры PSK по умолчанию отключены, и для использования TLS-PSK необходимо явно указать набор шифров с параметром ciphers. Список доступных шифров можно получить с помощью openssl ciphers -v 'PSK'. Все шифры TLS 1.3 применимы к PSK, но в настоящее время поддерживаются только те, которые используют хеш-функцию SHA256. Их можно получить с помощью openssl ciphers -v -s -tls1_3 -psk.

Согласно RFC 4279, должны поддерживаться идентификаторы PSK длиной до 128 байт и PSK длиной до 64 байт. По состоянию на OpenSSL 1.1.0 максимальный размер идентификатора составляет 128 байт, а максимальная длина PSK составляет 256 байт.

Текущая реализация не поддерживает асинхронные обратные вызовы PSK из-за ограничений базового API OpenSSL.

Смягчение атак с переподключением по инициативе клиента

Протокол TLS позволяет клиентам переподключаться к определенным аспектам сеанса TLS. К сожалению, переподключение сеанса требует значительных ресурсов на стороне сервера, что делает его потенциальным вектором атак типа «отказ в обслуживании».

Для минимизации рисков переподключение ограничено тремя разами в течение десяти минут. Событие 'error' генерируется на экземпляре tls.TLSSocket, когда этот порог превышен. Пределы настраиваются:

• tls.CLIENT_RENEG_LIMIT <число> Указывает количество запросов переподключения. По умолчанию: 3.
• tls.CLIENT_RENEG_WINDOW <число> Указывает временной интервал переподключения в секундах. По умолчанию: 600 (10 минут).

Не следует изменять значения по умолчанию для ограничений переподключения без полного понимания последствий и рисков.

TLSv1.3 не поддерживает переподключение.

Возобновление сеанса

Установление сеанса TLS может быть относительно медленным. Этот процесс можно ускорить, сохранив и повторно использовав состояние сеанса. Существует несколько механизмов для этого, описанных здесь от старых к новым (и предпочтительным).

Идентификаторы сеанса

Серверы генерируют уникальный идентификатор для новых подключений и отправляют его клиенту. Клиенты и серверы сохраняют состояние сеанса. При повторном подключении клиенты отправляют идентификатор сохраненного состояния сеанса, и если сервер также имеет состояние для этого идентификатора, он может согласиться использовать его. В противном случае сервер создаст новый сеанс. Дополнительная информация содержится в RFC 2246 на страницах 23 и 30.

Возобновление с помощью идентификаторов сеанса поддерживается большинством веб-браузеров при выполнении запросов HTTPS.

В Node.js клиенты ожидают события 'session' для получения данных сеанса и передают эти данные в параметр session последующего tls.connect() для повторного использования сеанса. Серверы должны реализовывать обработчики событий 'newSession' и 'resumeSession' для сохранения и восстановления данных сеанса, используя идентификатор сеанса в качестве ключа поиска для повторного использования сеансов. Для повторного использования сеансов через балансировщики нагрузки или рабочие процессы кластера серверы должны использовать общую кэш-память сеансов (такую как Redis) в своих обработчиках сеансов.

Жетоны сеанса

Серверы шифруют все состояние сеанса и отправляют его клиенту в виде «жетона». При повторном подключении состояние отправляется серверу в начальном соединении. Этот механизм позволяет избежать необходимости кэширования сеансов на стороне сервера. Если сервер не использует жетон по какой-либо причине (не удалось его расшифровать, он слишком старый и т. д.), он создаст новый сеанс и отправит новый жетон. Дополнительная информация содержится в RFC 5077.

Возобновление с помощью жетонов сеанса становится все более распространенным в веб-браузерах при выполнении запросов HTTPS.

В Node.js клиенты используют те же API для возобновления с идентификаторами сеансов, что и для возобновления с жетонами сеансов. Для отладки, если tls.TLSSocket.getTLSTicket() возвращает значение, данные сеанса содержат жетон, в противном случае они содержат состояние сеанса на стороне клиента.

В TLSv1.3 следует учитывать, что сервер может отправить несколько жетонов, что приведет к нескольким событиям 'session'. См. 'session' для получения дополнительной информации.

Серверам, работающим в одном процессе, не нужна специальная реализация для использования жетонов сеанса. Для использования жетонов сеанса через перезапуск сервера или балансировщики нагрузки все серверы должны иметь одинаковые ключи жетонов. Внутренне есть три 16-байтовых ключа, но API TLS предоставляет их в виде одного 48-байтового буфера для удобства.

Ключи жетонов можно получить, вызвав server.getTicketKeys() на одном экземпляре сервера, а затем распределить их, но более разумно сгенерировать 48 байт безопасных случайных данных и установить их с помощью параметра ticketKeys опции tls.createServer(). Ключи следует регулярно перегенерировать, а ключи сервера можно сбросить с помощью server.setTicketKeys().

Ключи жетонов сеанса являются криптографическими ключами и должны храниться безопасно. В TLS 1.2 и ниже, если они скомпрометированы, все сеансы, которые использовали зашифрованные ими жетоны, могут быть расшифрованы. Их не следует хранить на диске, и их следует регулярно перегенерировать.

Если клиенты объявляют о поддержке жетонов, сервер отправит их. Сервер может отключить жетоны, передав require('constants').SSL_OP_NO_TICKET в secureOptions.

Идентификаторы сеансов и билеты сеансов также имеют таймаут, что заставляет сервер создавать новые сеансы. Таймаут можно настроить с помощью параметра sessionTimeout в tls.createServer().

Во всех механизмах, когда возобновление сеанса завершается неудачно, серверы будут создавать новые сеансы. Так как неудачное возобновление сеанса не приводит к ошибкам соединения TLS/HTTPS, легко не заметить излишне плохую производительность TLS. Командная строка OpenSSL может использоваться для проверки того, что серверы возобновляют сеансы. Используйте параметр -reconnect для openssl s_client, например:

$ openssl s_client -connect localhost:443 -reconnect

Прочитайте вывод отладки. Первое соединение должно указывать "Новый", например:

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

Последующие соединения должны указывать "Использован", например:

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

Изменение по умолчанию набора шифров TLS

Node.js создаётся с предустановленным набором включённых и отключённых шифров TLS. Этот список шифров по умолчанию можно настроить при создании Node.js, чтобы дистрибутивы могли предоставить свой собственный список по умолчанию.

Следующая команда может быть использована для отображения набора шифров по умолчанию:

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

Этот список можно полностью заменить с помощью переключателя командной строки --tls-cipher-list (непосредственно или через переменную окружения NODE_OPTIONS). Например, следующее делает ECDHE-RSA-AES128-GCM-SHA256:!RC4 набором шифров TLS по умолчанию:

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

По умолчанию также можно заменить на основе каждого клиента или сервера с помощью параметра ciphers из tls.createSecureContext(), который также доступен в tls.createServer(), tls.connect() и при создании новых tls.TLSSocket.

Список шифров может содержать смесь имён наборов шифров TLSv1.3, начинающихся с 'TLS_', и спецификаций для наборов шифров TLSv1.2 и ниже. Шифры TLSv1.2 поддерживают устаревшую спецификацию формата, ознакомьтесь с документацией OpenSSL формата списка шифров для получения подробностей, но эти спецификации не применяются к шифрам TLSv1.3. Наборы TLSv1.3 можно включить только, включив их полное имя в список шифров. Например, их нельзя включать или отключать, используя устаревшую спецификацию TLSv1.2 'EECDH' или '!EECDH'.

Несмотря на относительный порядок наборов шифров TLSv1.3 и TLSv1.2, протокол TLSv1.3 значительно безопаснее, чем TLSv1.2, и всегда будет выбран вместо TLSv1.2, если рукопожатие указывает на его поддержку, и если включены какие-либо наборы шифров TLSv1.3.

Набор шифров по умолчанию, включённый в Node.js, тщательно подобран для соответствия текущим рекомендациям по безопасности и минимизации рисков. Изменение набора шифров по умолчанию может существенно повлиять на безопасность приложения. Переключатель --tls-cipher-list и параметр ciphers следует использовать только в случае крайней необходимости.

Набор шифров по умолчанию отдаёт предпочтение шифрам GCM для настройки "современной криптографии" в Chrome, а также отдаёт предпочтение шифрам ECDHE и DHE для обеспечения совершенной прямой секретности, предлагая некоторую обратную совместимость.

128-битный AES предпочтительнее 192 и 256-битного AES в свете конкретных атак, затрагивающих более крупные размеры ключей AES.

Старые клиенты, которые полагаются на небезопасные и устаревшие шифры RC4 или DES (например, Internet Explorer 6), не могут завершить процесс рукопожатия с настройками по умолчанию. Если необходимо поддерживать таких клиентов, рекомендации по TLS TLS recommendations могут предложить совместимый набор шифров. Более подробную информацию о формате см. в документации OpenSSL по формату списка шифров.

Существует только 5 наборов шифров 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'

Первые 3 включены по умолчанию. Последние 2 набора шифров, использующие CCM, поддерживаются TLSv1.3, так как они могут быть более производительными на ограниченных системах, но они не включены по умолчанию, поскольку обеспечивают меньшую безопасность.

Коды ошибок сертификатов X509

Несколько функций могут завершиться неудачно из-за ошибок сертификатов, которые сообщаются OpenSSL. В таком случае функция предоставляет <Error> через свой обратный вызов с свойством code, которое может принимать одно из следующих значений:

• 'UNABLE_TO_GET_ISSUER_CERT': Невозможно получить сертификат издателя.
• 'UNABLE_TO_GET_CRL': Невозможно получить CRL сертификата.
• 'UNABLE_TO_DECRYPT_CERT_SIGNATURE': Невозможно расшифровать подпись сертификата.
• 'UNABLE_TO_DECRYPT_CRL_SIGNATURE': Невозможно расшифровать подпись CRL.
• 'UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY': Невозможно декодировать открытый ключ издателя.
• 'CERT_SIGNATURE_FAILURE': Ошибка подписи сертификата.
• 'CRL_SIGNATURE_FAILURE': Ошибка подписи CRL.
• 'CERT_NOT_YET_VALID': Сертификат ещё не действителен.
• 'CERT_HAS_EXPIRED': Сертификат просрочен.
• 'CRL_NOT_YET_VALID': CRL ещё не действителен.
• 'CRL_HAS_EXPIRED': CRL просрочен.
• 'ERROR_IN_CERT_NOT_BEFORE_FIELD': Ошибка формата в поле notBefore сертификата.
• 'ERROR_IN_CERT_NOT_AFTER_FIELD': Ошибка формата в поле notAfter сертификата.
• 'ERROR_IN_CRL_LAST_UPDATE_FIELD': Ошибка формата в поле lastUpdate CRL.
• 'ERROR_IN_CRL_NEXT_UPDATE_FIELD': Ошибка формата в поле nextUpdate CRL.
• 'OUT_OF_MEM': Отсутствие памяти.
• 'DEPTH_ZERO_SELF_SIGNED_CERT': Сертификат самоподписанный.
• 'SELF_SIGNED_CERT_IN_CHAIN': Самоподписанный сертификат в цепочке сертификатов.
• 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY': Невозможно получить локальный сертификат издателя.
• 'UNABLE_TO_VERIFY_LEAF_SIGNATURE': Невозможно проверить первый сертификат.
• 'CERT_CHAIN_TOO_LONG': Цепочка сертификатов слишком длинная.
• 'CERT_REVOKED': Сертификат отозван.
• 'INVALID_CA': Недействительный сертификат CA.
• 'PATH_LENGTH_EXCEEDED': Превышен ограничитель длины пути.
• 'INVALID_PURPOSE': Неподдерживаемое назначение сертификата.
• 'CERT_UNTRUSTED': Сертификат ненадёжный.
• 'CERT_REJECTED': Сертификат отклонён.
• 'HOSTNAME_MISMATCH': Несоответствие имени хоста.

Класс: tls.CryptoStream

Класс tls.CryptoStream представляет собой поток зашифрованных данных. Этот класс устарел и больше не должен использоваться.

cryptoStream.bytesWritten

Свойство cryptoStream.bytesWritten возвращает общее количество байтов, записанных в подлежащий сокет, включая байты, необходимые для реализации протокола TLS.

Класс: tls.SecurePair

Возвращается функцией tls.createSecurePair().

Событие: 'secure'

Событие 'secure' генерируется объектом SecurePair после установления безопасного соединения.

Как и при проверке события сервера 'secureConnection', следует проверить pair.cleartext.authorized, чтобы подтвердить, что используемый сертификат надёжно авторизован.

Класс: tls.Server

• Расширяет: <net.Server>

Принимает защищённые соединения с использованием TLS или SSL.

Событие: 'connection'

• socket <stream.Duplex>

Это событие генерируется, когда устанавливается новый TCP-поток, перед началом рукопожатия TLS. socket обычно является объектом типа net.Socket. Пользователи обычно не будут взаимодействовать с этим событием.

Это событие также может быть явно сгенерировано пользователем для ввода подключений в сервер TLS. В этом случае может быть передан любой поток Duplex.

Событие: 'keylog'

• line <Buffer> Строка ASCII-текста в формате NSS SSLKEYLOGFILE.
• tlsSocket <tls.TLSSocket> Экземпляр tls.TLSSocket, для которого оно было сгенерировано.

Событие keylog генерируется при создании или получении ключей материала соединением с этим сервером (обычно перед завершением рукопожатия, но не обязательно). Этот материал ключей может быть сохранён для отладки, так как он позволяет расшифровать перехваченный TLS-трафик. Оно может быть сгенерировано несколько раз для каждого сокета.

Типичный случай использования — добавление полученных строк в общий текстовый файл, который позже используется программным обеспечением (например, Wireshark) для расшифровки трафика:

const logFile = fs.createWriteStream('/tmp/ssl-keys.log', { flags: 'a' });
// ...
server.on('keylog', (line, tlsSocket) => {
  if (tlsSocket.remoteAddress !== '...')
    return; // Only log keys for a particular IP
  logFile.write(line);
});

Событие: 'newSession'

Событие 'newSession' генерируется при создании новой TLS-сессии. Это может быть использовано для хранения сессий во внешнем хранилище. Данные должны быть предоставлены в обратный вызов 'resumeSession'.

Обратный вызов обработчика вызывается с тремя аргументами:

• sessionId <Buffer> Идентификатор TLS-сессии
• sessionData <Buffer> Данные TLS-сессии
• callback <Function> Обратный вызов, не принимающий аргументов, который должен быть вызван для отправки или получения данных по защищённому соединению.

Прослушивание этого события оказывает влияние только на подключения, установленные после добавления обработчика.

Событие: 'OCSPRequest'

Событие 'OCSPRequest' генерируется, когда клиент отправляет запрос состояния сертификата. Обратный вызов обработчика вызывается с тремя аргументами:

• certificate <Buffer> Сертификат сервера
• issuer <Buffer> Сертификат издателя
• callback <Function> Обратный вызов, который должен быть вызван для предоставления результатов запроса OCSP.

Текущий сертификат сервера можно разобрать для получения OCSP-URL и идентификатора сертификата; после получения ответа OCSP, вызывается callback(null, resp), где resp — экземпляр Buffer, содержащий ответ OCSP. И certificate, и issuer являются Buffer DER-представлениями основных и издательских сертификатов. Их можно использовать для получения идентификатора OCSP-сертификата и URL-адреса конечной точки OCSP.

В противном случае, вызывается callback(null, null), указывая, что ответа OCSP не было.

Вызов callback(err) приведёт к вызову socket.destroy(err).

Типичный поток запроса OCSP:

1. Клиент подключается к серверу и отправляет запрос 'OCSPRequest' (через расширение информации о состоянии в ClientHello).
2. Сервер получает запрос и генерирует событие 'OCSPRequest', вызывая обработчик, если он зарегистрирован.
3. Сервер извлекает OCSP-URL из либо certificate, либо issuer и выполняет запрос OCSP к центру сертификации.
4. Сервер получает 'OCSPResponse' от центра сертификации и отправляет его обратно клиенту через аргумент callback
5. Клиент проверяет ответ и либо уничтожает сокет, либо выполняет рукопожатие.

OCSP-запрос может быть issuer, если сертификат самоподписанный или издатель не входит в список корневых сертификатов. (Издатель может быть предоставлен через опцию ca при установлении TLS-соединения).

Прослушивание этого события оказывает влияние только на подключения, установленные после добавления обработчика события.

Модуль npm, такой как asn1.js, может быть использован для разбора сертификатов.

Событие: 'resumeSession'

Событие 'resumeSession' генерируется, когда клиент запрашивает возобновление предыдущей TLS-сессии. Обратный вызов обработчика вызывается с двумя аргументами:

• sessionId <Buffer> Идентификатор TLS-сессии
• callback <Function> Обратный вызов, который будет вызван при восстановлении предыдущей сессии: callback([err[, sessionData]])
  • err <Error>
  • sessionData <Buffer>

Обработчик события должен выполнить поиск во внешнем хранилище сохранённой sessionData, сохранённой обработчиком события 'newSession' с помощью данного sessionId. Если найдена, вызовите callback(null, sessionData) для возобновления сессии. Если не найдена, возобновить сессию нельзя. callback() должен быть вызван без sessionData, чтобы рукопожатие могло продолжить и создать новую сессию. Возможно, вызвать callback(err) для завершения входящего соединения и уничтожения сокета.

Прослушивание этого события оказывает влияние только на подключения, установленные после добавления обработчика события.

Следующее демонстрирует возобновление 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);
});

Событие: 'secureConnection'

Событие 'secureConnection' генерируется после успешного завершения процесса рукопожатия для нового подключения. Обратный вызов обработчика вызывается с одним аргументом:

• tlsSocket <tls.TLSSocket> Установленный TLS-сокет.

Свойство tlsSocket.authorized — boolean, указывающее, был ли клиент проверен одним из предоставленных центров сертификации для сервера. Если tlsSocket.authorized имеет значение false, тогда socket.authorizationError задаётся, чтобы описать, как авторизация не удалась. В зависимости от настроек сервера TLS, незащищённые соединения всё равно могут приниматься.

Свойство tlsSocket.alpnProtocol — строка, содержащая выбранный протокол ALPN. Когда ALPN не выбирает протокол, то tlsSocket.alpnProtocol равно false.

Свойство tlsSocket.servername — строка, содержащая имя сервера, запрошенное через SNI.

Событие: 'tlsClientError'

Событие 'tlsClientError' генерируется, когда происходит ошибка перед установлением защищённого соединения. Обратный вызов обработчика вызывается с двумя аргументами:

• exception <Error> Объект Error, описывающий ошибку
• tlsSocket <tls.TLSSocket> Экземпляр tls.TLSSocket, из которого возникла ошибка.

server.addContext(hostname, context)

• hostname <string> Имя хоста SNI или подстановка (например, '*')
• context <Object> Объект, содержащий любые возможные свойства из tls.createSecureContext() аргументов options (например, key, cert, ca и т. д.).

Метод server.addContext() добавляет контекст безопасности, который будет использоваться, если имя SNI запроса клиента совпадает с предоставленным hostname (или подстановкой).

Если совпадений несколько, используется добавленный контекст последним.

server.address()

• Возвращает: <Object>

Возвращает связанный адрес, имя семейства адресов и порт сервера, как указано операционной системой. См. net.Server.address() для получения дополнительной информации.

server.close([callback])

• callback <Функция> Обратный вызов обработчика, который будет зарегистрирован для прослушивания события 'close' экземпляра сервера.
• Возвращает: <tls.Сервер>

Метод server.close() останавливает сервер от принятия новых подключений.

Эта функция работает асинхронно. Событие 'close' будет излучено, когда у сервера больше нет открытых подключений.

server.getTicketKeys()

• Возвращает: <Буфер> Буфер размером 48 байт, содержащий ключи сессионных билетов.

Возвращает ключи сессионных билетов.

См. Возобновление сеанса для получения дополнительной информации.

server.listen()

Запускает сервер, прослушивающий зашифрованные подключения. Этот метод идентичен методу server.listen() из net.Server.

server.setSecureContext(options)

• options <Объект> Объект, содержащий любые возможные свойства из tls.createSecureContext() options аргументов (например, key, cert, ca и т. д.).

Метод server.setSecureContext() заменяет защищённый контекст существующего сервера. Существующие подключения к серверу не прерываются.

server.setTicketKeys(keys)

• keys <Буфер> | <Массив типов> | <DataView> Буфер размером 48 байт, содержащий ключи сессионных билетов.

Устанавливает ключи сессионных билетов.

Изменения ключей билетов вступают в силу только для будущих подключений к серверу. Существующие или текущие подключения к серверу будут использовать предыдущие ключи.

См. Возобновление сеанса для получения дополнительной информации.

Класс: tls.TLSSocket

• Расширяет: <net.Socket>

Выполняет прозрачное шифрование записанных данных и все необходимые переговоры TLS.

Экземпляры tls.TLSSocket реализуют интерфейс дуплексного потока Stream.

Методы, возвращающие метаданные соединения TLS (например, tls.TLSSocket.getPeerCertificate()), будут возвращать данные только пока соединение открыто.

new tls.TLSSocket(socket[, options])

• socket <net.Socket> | <stream.Duplex> На стороне сервера, любой поток Duplex. На стороне клиента, любой экземпляр net.Socket (для поддержки потоков Duplex на стороне клиента, необходимо использовать tls.connect()).
• options <Object>
  • enableTrace: См. tls.createServer()
  • isServer: Протокол SSL/TLS ассиметричен, TLSSockets должны знать, будут ли они работать как сервер или клиент. Если true, сокет TLS будет создан как сервер. По умолчанию: false.
  • server <net.Server> Экземпляр net.Server.
  • requestCert: Требовать ли аутентификацию удаленного узла, запросив сертификат. Клиенты всегда запрашивают сертификат сервера. Сервера (если isServer равно true) могут установить requestCert в true, чтобы запросить сертификат клиента.
  • rejectUnauthorized: См. tls.createServer()
  • ALPNProtocols: См. tls.createServer()
  • SNICallback: См. tls.createServer()
  • session <Buffer> Экземпляр Buffer, содержащий сеанс TLS.
  • requestOCSP <boolean> Если true, указывает, что расширение запроса статуса OCSP будет добавлено к клиенту hello и событие 'OCSPResponse' будет излучено в сокете перед установлением защищённого соединения.
  • secureContext: Объект контекста TLS, созданный с помощью tls.createSecureContext(). Если secureContext не указан, он будет создан, передав весь объект options в tls.createSecureContext().
  • ...: tls.createSecureContext() опции, которые используются, если опция secureContext отсутствует. В противном случае они игнорируются.

Создаёт новый объект tls.TLSSocket из существующего TCP сокета.

Событие: 'keylog'

• line <Buffer> Строка ASCII текста в формате NSS SSLKEYLOGFILE.

Событие keylog излучается на tls.TLSSocket, когда сокет генерирует или получает ключевой материал. Этот ключевой материал можно сохранить для отладки, так как он позволяет расшифровать перехваченный трафик TLS. Может излучаться несколько раз, до или после завершения рукопожатия.

Типичный пример использования — добавить полученные строки в общий текстовый файл, который позже используется программным обеспечением (таким как Wireshark) для расшифровки трафика:

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

Событие: 'OCSPResponse'

Событие 'OCSPResponse' излучается, если опция requestOCSP была установлена при создании tls.TLSSocket и получен ответ OCSP. Функция обратного вызова слушателя получает один аргумент:

• response <Buffer> Ответ OCSP сервера

Обычно response — это цифрово подписанный объект от CA сервера, который содержит информацию о статусе отзыва сертификата сервера.

Событие: 'secureConnect'

Событие 'secureConnect' излучается после успешного завершения процесса рукопожатия для нового соединения. Функция обратного вызова вызывается независимо от того, был ли серверный сертификат авторизован. Клиент отвечает за проверку свойства tlsSocket.authorized, чтобы определить, был ли серверный сертификат подписан одним из указанных CA. Если tlsSocket.authorized === false, ошибка может быть найдена, проверив свойство tlsSocket.authorizationError. Если использовался ALPN, свойство tlsSocket.alpnProtocol может быть проверено, чтобы определить согласованный протокол.

Событие 'secureConnect' не излучается, когда <tls.TLSSocket> создаётся с помощью конструктора new tls.TLSSocket().

Событие: 'session'

• session <Buffer>

Событие 'session' излучается на клиенте tls.TLSSocket, когда новый сеанс или TLS-токен доступны. Это может произойти до или после завершения рукопожатия, в зависимости от версии протокола TLS, которая была согласована. Событие не излучается на сервере или если новый сеанс не был создан, например, при возобновлении соединения. Для некоторых версий протокола TLS событие может излучаться несколько раз, в этом случае все сеансы могут быть использованы для возобновления.

На клиенте session можно предоставить в опцию session tls.connect() для возобновления соединения.

См. Возобновление сеансов для получения дополнительной информации.

Для TLSv1.2 и ниже tls.TLSSocket.getSession() можно вызвать после завершения рукопожатия. Для TLSv1.3 разрешено только возобновление на основе токенов, отправляются несколько токенов, и токены не отправляются до завершения рукопожатия. Поэтому необходимо дождаться события 'session', чтобы получить возобновляемый сеанс. Приложения должны использовать событие 'session' вместо getSession(), чтобы они работали для всех версий TLS. Приложения, которые ожидают получить или использовать только один сеанс, должны прослушивать это событие только один раз:

tlsSocket.once('session', (session) => {
  // The session can be used immediately or later.
  tls.connect({
    session: session,
    // Other connect options...
  });
});

tlsSocket.address()

• Возвращает: <Object>

Возвращает привязанный address, адрес family имя и port базового сокета, как сообщается операционной системой: { port: 12346, family: 'IPv4', address: '127.0.0.1' }.

tlsSocket.authorizationError

Возвращает причину, по которой сертификат узла не был проверен. Это свойство устанавливается только при tlsSocket.authorized === false.

tlsSocket.authorized

• Возвращает: <boolean>

Возвращает true, если сертификат узла был подписан одним из CA, указанных при создании экземпляра tls.TLSSocket, в противном случае false.

tlsSocket.disableRenegotiation()

Отключает возобновление TLS для этого экземпляра TLSSocket. После вызова попытки возобновить вызовут событие 'error' на TLSSocket.

tlsSocket.enableTrace()

При включении информация о трассировке пакетов TLS записывается в stderr. Это можно использовать для отладки проблем с TLS-соединением.

Формат вывода идентичен выводу openssl s_client -trace или openssl s_server -trace. Хотя он генерируется функцией OpenSSL's SSL_trace(), формат не документирован, может изменяться без предварительного уведомления и не должен использоваться.

tlsSocket.encrypted

Всегда возвращает true. Это может быть использовано для различения TLS-сокетов от обычных экземпляров net.Socket.

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

• length <number> количество байтов для извлечения из ключевого материала

• label <string> метка, специфичная для приложения, обычно это значение из реестра меток экспортеров IANA.

• context <Buffer> Опционально укажите контекст.

• Возвращает: <Buffer> запрошенные байты ключевого материала

Ключевой материал используется для проверок, чтобы предотвратить различные виды атак в сетевых протоколах, например, в спецификациях IEEE 802.1X.

Пример

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

/**
 Example return value of 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 more bytes>
*/

См. документацию OpenSSL SSL_export_keying_material для получения дополнительной информации.

tlsSocket.getCertificate()

• Возвращает: <Объект>

Возвращает объект, представляющий локальный сертификат. Возвращаемый объект имеет некоторые свойства, соответствующие полям сертификата.

См. tls.TLSSocket.getPeerCertificate() для примера структуры сертификата.

Если локального сертификата нет, будет возвращён пустой объект. Если сокет был уничтожен, будет возвращено null.

tlsSocket.getCipher()

• Возвращает: <Объект>
  • name <строка> Имя шифра по OpenSSL.
  • standardName <строка> Имя шифра по IETF.
  • version <строка> Минимальная версия протокола TLS, поддерживаемая данным набором шифров.

Возвращает объект, содержащий информацию о согласованном наборе шифров.

Например:

{
    "name": "AES128-SHA256",
    "standardName": "TLS_RSA_WITH_AES_128_CBC_SHA256",
    "version": "TLSv1.2"
}

См. SSL_CIPHER_get_name для получения дополнительной информации.

tlsSocket.getEphemeralKeyInfo()

• Возвращает: <Объект>

Возвращает объект, представляющий тип, имя и размер параметра обмена эфемерными ключами в режиме совершенной прямой секретности при клиентском подключении. Возвращает пустой объект, когда обмен ключами не эфемерный. Так как эта функция поддерживается только для клиентских сокетов, null будет возвращено, если её вызвать на серверном сокете. Поддерживаемые типы — 'DH' и 'ECDH'. Свойство name доступно только когда тип равен 'ECDH'.

Например: { type: 'ECDH', name: 'prime256v1', size: 256 }.

tlsSocket.getFinished()

• Возвращает: <Буфер> | <неопределено> Последнее сообщение Finished, которое было отправлено в сокет в рамках рукопожатия SSL/TLS, или undefined, если ещё не было отправлено сообщение Finished.

Так как сообщения Finished являются хешами всего процесса рукопожатия (с общим размером 192 бита для TLS 1.0 и больше для SSL 3.0), их можно использовать для внешних процедур аутентификации, когда аутентификация, предоставляемая SSL/TLS, не требуется или недостаточна.

Соответствует функции SSL_get_finished в OpenSSL и может быть использована для реализации привязки канала tls-unique из RFC 5929.

tlsSocket.getPeerCertificate([detailed])

• detailed <булево> Включить полную цепочку сертификатов, если true, в противном случае включить только сертификат клиента.
• Возвращает: <Объект> Объект сертификата.

Возвращает объект, представляющий сертификат клиента. Если клиент не предоставляет сертификат, возвращается пустой объект. Если сокет был уничтожен, возвращается null.

Если была запрошена полная цепочка сертификатов, каждый сертификат будет содержать свойство issuerCertificate, содержащее объект, представляющий сертификат его издателя.

Объект сертификата

Объект сертификата имеет свойства, соответствующие полям сертификата.

• raw <Буфер> Данные сертификата X.509 в кодировке DER.
• subject <Объект> Субъект сертификата, описанный в терминах Страны (C:), Области (ST), Места (L), Организации (O), Подразделения организации (OU) и Общего имени (CN). Общее имя обычно является именем DNS в сертификатах TLS. Пример: {C: 'UK', ST: 'BC', L: 'Metro', O: 'Node Fans', OU: 'Docs', CN: 'example.com'}.
• issuer <Объект> Издатель сертификата, описанный в тех же терминах, что и subject.
• valid_from <строка> Дата начала действия сертификата.
• valid_to <строка> Дата окончания действия сертификата.
• serialNumber <строка> Серийный номер сертификата в шестнадцатеричном формате. Пример: 'B9B0D332A1AA5635'.
• fingerprint <строка> SHA-1 дайджест сертификата в кодировке DER, возвращается как шестнадцатеричная строка, разделённая :. Пример: '2A:7A:C2:DD:...'.
• fingerprint256 <строка> SHA-256 дайджест сертификата в кодировке DER, возвращается как шестнадцатеричная строка, разделённая :. Пример: '2A:7A:C2:DD:...'.
• ext_key_usage <Массив> (Необязательно) Расширенное использование ключа, набор OID.
• subjectaltname <строка> (Необязательно) Строка, содержащая конкатенированные имена субъекта, альтернатива именам subject.
• infoAccess <Массив> (Необязательно) Массив, описывающий AuthorityInfoAccess, используемый с OCSP.
• issuerCertificate <Объект> (Необязательно) Объект сертификата издателя. Для самоподписанных сертификатов это может быть циклическая ссылка.

Сертификат может содержать информацию об открытом ключе, в зависимости от типа ключа.

Для ключей RSA могут быть определены следующие свойства:

• bits <число> Размер ключа RSA в битах. Пример: 1024.
• exponent <строка> Показатель RSA в шестнадцатеричном формате. Пример: '0x010001'.
• modulus <строка> Модуль RSA в шестнадцатеричном формате. Пример: 'B56CE45CB7...'.
• pubkey <Буфер> Открытый ключ.

Для ключей EC могут быть определены следующие свойства:

• pubkey <Буфер> Открытый ключ.
• bits <число> Размер ключа в битах. Пример: 256.
• asn1Curve <строка> (Необязательно) Имя OID эллиптической кривой в ASN.1. Известные кривые идентифицируются по OID. Хотя это редкость, кривая может быть идентифицирована по своим математическим свойствам, в этом случае у неё нет OID. Пример: 'prime256v1'.
• nistCurve <строка> (Необязательно) Имя NIST для эллиптической кривой, если оно есть (не все известные кривые имеют имена NIST). Пример: 'P-256'.

Пример сертификата:

{ 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',
  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()

• Возвращает: <Буфер> | <неопределено> Последнее сообщение Finished, ожидаемое или фактически полученное от сокета в рамках рукопожатия SSL/TLS, или undefined, если такого сообщения Finished пока нет.

Поскольку сообщения Finished представляют собой дайджесты сообщения всего рукопожатия (с общим объёмом 192 бита для TLS 1.0 и более для SSL 3.0), их можно использовать для внешних процедур аутентификации, когда аутентификация, предоставляемая SSL/TLS, нежелательна или недостаточна.

Соответствует процедуре SSL_get_peer_finished в OpenSSL и может использоваться для реализации привязки канала tls-unique из RFC 5929.

tlsSocket.getPeerX509Certificate()

• Возвращает: <X509Certificate>

Возвращает сертификат удалённого узла в виде объекта <X509Certificate>.

Если сертификат удалённого узла отсутствует или сокет был уничтожен, будет возвращено undefined.

tlsSocket.getProtocol()

• Возвращает: <строка> | <null>

Возвращает строку, содержащую переговорённую версию протокола SSL/TLS текущего соединения. Значение 'unknown' будет возвращено для подключённых сокетов, которые не завершили процесс рукопожатия. Значение null будет возвращено для серверных сокетов или отключённых клиентских сокетов.

Версии протоколов:

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

См. документацию OpenSSL SSL_get_version для получения дополнительной информации.

tlsSocket.getSession()

• <Буфер>

Возвращает данные сеанса TLS или undefined, если сеанс не был переговорён. В клиенте данные могут быть предоставлены параметру session опции tls.connect() для возобновления соединения. На сервере это может быть полезно для отладки.

См. Возобновление сеанса для получения дополнительной информации.

Примечание: getSession() работает только для TLSv1.2 и ниже. Для TLSv1.3 приложения должны использовать событие 'session' (оно также работает для TLSv1.2 и ниже).

tlsSocket.getSharedSigalgs()

• Возвращает: <Массив> Список алгоритмов подписи, общих для сервера и клиента в порядке убывания приоритета.

См. SSL_get_shared_sigalgs для получения дополнительной информации.

tlsSocket.getTLSTicket()

• <Буфер>

Для клиента возвращает билет сеанса TLS, если он доступен, или undefined. Для сервера всегда возвращает undefined.

Это может быть полезно для отладки.

См. Возобновление сеанса для получения дополнительной информации.

tlsSocket.getX509Certificate()

• Возвращает: <X509Certificate>

Возвращает локальный сертификат в виде объекта <X509Certificate>.

Если локальный сертификат отсутствует или сокет был уничтожен, будет возвращено undefined.

tlsSocket.isSessionReused()

• Возвращает: <логическое значение> true, если сеанс был повторно использован, false в противном случае.

См. Возобновление сеанса для получения дополнительной информации.

tlsSocket.localAddress

• <строка>

Возвращает строковое представление локального IP-адреса.

tlsSocket.localPort

• <число>

Возвращает числовое представление локального порта.

tlsSocket.remoteAddress

• <строка>

Возвращает строковое представление удалённого IP-адреса. Например, '74.125.127.100' или '2001:4860:a005::68'.

tlsSocket.remoteFamily

• <строка>

Возвращает строковое представление семейства удалённого IP-адреса. 'IPv4' или 'IPv6'.

tlsSocket.remotePort

• <число>

Возвращает числовое представление удалённого порта. Например, 443.

tlsSocket.renegotiate(options, callback)

• options <Объект>

  • rejectUnauthorized <логическое значение> Если не false, сертификат сервера проверяется по списку предоставленных CA. Событие 'error' генерируется в случае ошибки проверки; err.code содержит код ошибки OpenSSL. По умолчанию: true.
  • requestCert

• callback <Функция> Если renegotiate() возвращает true, callback прикрепляется один раз к событию 'secure'. Если renegotiate() возвращает false, callback будет вызвана в следующем такте с ошибкой, если сокет tlsSocket не был уничтожен, в противном случае callback не будет вызвана вовсе.

• Возвращает: <логическое значение> true, если переподключение было инициировано, false в противном случае.

Метод tlsSocket.renegotiate() инициирует процесс переподключения TLS. После завершения функция callback будет передана с единственным аргументом, который представляет собой либо Error (если запрос не удался), либо null.

Этот метод может использоваться для запроса сертификата удалённого узла после установления защищённого соединения.

При работе в качестве сервера сокет будет уничтожен с ошибкой после таймаута handshakeTimeout.

Для TLSv1.3 переподключение инициировать нельзя, оно не поддерживается протоколом.

tlsSocket.setMaxSendFragment(size)

• size <число> Максимальный размер фрагмента TLS. Максимальное значение составляет 16384. По умолчанию: 16384.
• Возвращает: <логическое значение>

Метод tlsSocket.setMaxSendFragment() устанавливает максимальный размер фрагмента TLS. Возвращает true, если ограничение было успешно установлено; false в противном случае.

Меньшие размеры фрагментов уменьшают задержку буферизации на клиенте: большие фрагменты буферизуются слоем TLS до тех пор, пока весь фрагмент не будет получен и проверен на целостность; большие фрагменты могут охватывать несколько запросов и их обработка может быть замедлена из-за потери или переупорядочения пакетов. Однако меньшие фрагменты добавляют дополнительные байты фрейминга TLS и накладные расходы на ЦП, что может уменьшить общую пропускную способность сервера.

tls.checkServerIdentity(hostname, cert)

• hostname <строка> Имя хоста или IP-адрес для проверки сертификата.
• cert <Объект> Объект сертификата, представляющий сертификат партнера.
• Возвращает: <Ошибка> | <неопределено>

Проверяет, что сертификат cert выдан hostname.

Возвращает объект <Ошибка>, заполняя его reason, host и cert при ошибке. В случае успеха возвращает <неопределено>.

Эту функцию можно переопределить, предоставив альтернативную функцию в качестве части опции options.checkServerIdentity, переданной в tls.connect(). Функция переопределения может вызывать tls.checkServerIdentity(), чтобы дополнить проверки дополнительной проверкой.

Эта функция вызывается только в том случае, если сертификат прошел все другие проверки, такие как проверка, выдан ли он доверенной ЦС (options.ca).

Более ранние версии Node.js неправильно принимали сертификаты для заданного hostname, если присутствовало соответствующее uniformResourceIdentifier альтернативное имя субъекта (см. CVE-2021-44531). Приложения, которые хотят принимать uniformResourceIdentifier альтернативные имена субъектов, могут использовать пользовательскую функцию options.checkServerIdentity, реализующую желаемое поведение.

tls.connect(options[, callback])

• options <Объект>

  • enableTrace: См. tls.createServer()

  • host <строка> Хост, к которому должен подключиться клиент. По умолчанию: 'localhost'.

  • port <число> Порт, к которому должен подключиться клиент.

  • path <строка> Создаёт подключение к сокету Unix по указанному пути. Если этот параметр указан, host и port игнорируются.

  • socket <stream.Duplex> Устанавливает защищённое соединение на заданном сокете вместо создания нового сокета. Обычно это экземпляр net.Socket, но допускается любой Duplex поток. Если этот параметр указан, path, host и port игнорируются, за исключением проверки сертификата. Обычно сокет уже подключён, когда он передаётся в tls.connect(), но он может быть подключён позже. Подключение/отключение/разрушение socket — ответственность пользователя; вызов tls.connect() не вызовет net.connect().

  • allowHalfOpen <логическое значение> Если установлено в false, то сокет автоматически завершит запись, когда закончится чтение. Если параметр socket установлен, этот параметр не имеет эффекта. См. параметр allowHalfOpen объекта net.Socket для деталей. По умолчанию: false.

  • rejectUnauthorized <логическое значение> Если не false, серверный сертификат проверяется по списку предоставленных ЦС. Событие 'error' генерируется при неудачной проверке; err.code содержит код ошибки OpenSSL. По умолчанию: true.

  • pskCallback <Функция>

    • Подсказка: <строка> необязательное сообщение, отправляемое сервером, чтобы помочь клиенту определить, какую идентичность использовать во время переговоров. Всегда null, если используется TLS 1.3.
    • Возвращает: <Объект> в формате { psk: <Buffer|TypedArray|DataView>, identity: <string> } или null для остановки процесса переговоров. psk должен соответствовать выбранному хэш-алгоритму. identity должен использовать кодировку UTF-8.

    При переговорах TLS-PSK (предварительно заданные ключи) эта функция вызывается с необязательной идентификацией hint, предоставленной сервером, или null в случае TLS 1.3, где hint был удалён. Необходимо будет предоставить настраиваемый tls.checkServerIdentity() для соединения, так как по умолчанию он попытается проверить имя хоста/IP-адрес сервера по сертификату, но это не применимо к PSK, так как сертификат отсутствует. Более подробную информацию можно найти в RFC 4279.

  • ALPNProtocols: <массив строк> | <массив буферов> | <массив TypedArray> | <массив DataView> | <буфер> | <TypedArray> | <DataView> Массив строк, Buffer или TypedArray или DataView, или один Buffer или TypedArray или DataView, содержащий поддерживаемые протоколы ALPN. Buffer должны иметь формат [len][name][len][name]..., например, '\x08http/1.1\x08http/1.0', где len байт — длина следующего имени протокола. Передача массива обычно намного проще, например, ['http/1.1', 'http/1.0']. Протоколы, стоящие раньше в списке, имеют больший приоритет, чем те, которые стоят позже.

  • servername: <строка> Имя сервера для расширения TLS SNI (Server Name Indication). Это имя хоста, к которому выполняется подключение, и должно быть именем хоста, а не IP-адресом. Может использоваться многоадресным сервером для выбора правильного сертификата, который нужно представить клиенту, см. параметр SNICallback объекта tls.createServer().

  • checkServerIdentity(servername, cert) <Функция> Функция обратного вызова, которая должна использоваться (вместо встроенной функции tls.checkServerIdentity()) для проверки имени хоста сервера (или предоставленного servername при явном указании) по отношению к сертификату. Если проверка не пройдена, метод должен вернуть <Ошибка>. Метод должен возвращать undefined, если servername и cert проверены.

  • session <Буфер> Экземпляр Buffer, содержащий сеанс TLS.

  • minDHSize <число> Минимальный размер параметра DH в битах для принятия соединения TLS. Если сервер предложит параметр DH с размером меньше minDHSize, соединение TLS разрушается, и выбрасывается ошибка. По умолчанию: 1024.

  • highWaterMark: <число> Соответствует параметру highWaterMark потока на чтение. По умолчанию: 16 * 1024.

  • secureContext: Объект контекста TLS, созданный с помощью tls.createSecureContext(). Если secureContext не указан, он будет создан путём передачи всего объекта options в tls.createSecureContext().

  • onread <Объект> Если параметр socket отсутствует, входящие данные хранятся в одном buffer и передаются предоставленной callback при поступлении данных на сокет, в противном случае параметр игнорируется. См. параметр onread объекта net.Socket для деталей.

  • ...: tls.createSecureContext() параметры, которые используются, если параметр secureContext отсутствует, в противном случае они игнорируются.

  • ...: Любой параметр socket.connect(), который ещё не указан.

• callback <Функция>
• Возвращает: <tls.TLSSocket>

Функция callback, если указана, будет добавлена в качестве обработчика события 'secureConnect'.

Функция tls.connect() возвращает объект tls.TLSSocket.

В отличие от API https, tls.connect() не включает расширение SNI (Server Name Indication) по умолчанию, что может привести к тому, что некоторые серверы вернут неправильный сертификат или вообще отклонят подключение. Для включения SNI установите параметр servername дополнительно к параметру host.

Следующий пример иллюстрирует клиента для сервера эха из примера tls.createServer():

// Assumes an echo server that is listening on port 8000.
const tls = require('tls');
const fs = require('fs');

const options = {
  // Necessary only if the server requires client certificate authentication.
  key: fs.readFileSync('client-key.pem'),
  cert: fs.readFileSync('client-cert.pem'),

  // Necessary only if the server uses a self-signed certificate.
  ca: [ fs.readFileSync('server-cert.pem') ],

  // Necessary only if the server's cert isn't for "localhost".
  checkServerIdentity: () => { return null; },
};

const socket = tls.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');
});

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

• path <string> Значение по умолчанию для options.path.
• options <Object> См. tls.connect().
• callback <Function> См. tls.connect().
• Возвращает: <tls.TLSSocket>

Аналогично tls.connect(), за исключением того, что path может быть предоставлен в качестве аргумента вместо опции.

Если указана опция пути, она будет иметь приоритет над аргументом пути.

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

• port <number> Значение по умолчанию для options.port.
• host <string> Значение по умолчанию для options.host.
• options <Object> См. tls.connect().
• callback <Function> См. tls.connect().
• Возвращает: <tls.TLSSocket>

Аналогично tls.connect(), за исключением того, что port и host могут быть предоставлены в качестве аргументов вместо опций.

Если указана опция порта или хоста, она будет иметь приоритет над любым аргументом порта или хоста.

tls.createSecureContext([options])

• options <Object>

• • ca <строка> | <массив строк> | <Буфер> | <массив буферов> Необязательно переопределите доверенные сертификаты CA. По умолчанию доверяются известные CA, собранные Mozilla. Сертификаты CA Mozilla полностью заменяются, когда CA явно заданы с помощью этого параметра. Значение может быть строкой или Buffer, или Array массивом строк и/или Buffer. Любая строка или Buffer может содержать несколько PEM-сертификатов CA, соединённых вместе. Сертификат узла должен быть связан с CA, которому доверяет сервер, для аутентификации подключения. При использовании сертификатов, которые не могут быть связаны с известным CA, CA сертификата необходимо явно указать как доверенный, иначе подключение не будет аутентифицировано. Если у узла используется сертификат, который не соответствует или не связан с одним из стандартных CA, используйте параметр ca, чтобы предоставить сертификат CA, с которым может быть связан или связан сертификат узла. Для самозаверяющих сертификатов сертификат является собственным CA и должен быть предоставлен. Для сертификатов в формате PEM поддерживаются типы «TRUSTED CERTIFICATE», «X509 CERTIFICATE» и «CERTIFICATE». См. также tls.rootCertificates.
  • cert <строка> | <массив строк> | <Буфер> | <массив буферов> Цепочки сертификатов в формате PEM. Один сертификат должен быть предоставлен на один закрытый ключ. Цепочка сертификатов должна состоять из сертификата в формате PEM для предоставленного закрытого key, за которым следуют промежуточные сертификаты в формате PEM (если таковые имеются), в порядке следования, без корневого CA (корневой CA должен быть известен узлу, см. ca). При предоставлении нескольких цепочек сертификатов они не должны быть в том же порядке, что и их закрытые ключи в key. Если промежуточные сертификаты не предоставлены, узел не сможет проверить сертификат, и соединение завершится неудачей.
  • sigalgs <строка> Список поддерживаемых алгоритмов подписи, разделённых двоеточием. Список может содержать алгоритмы хеширования (SHA256, MD5 и т. д.), алгоритмы с открытым ключом (RSA-PSS, ECDSA и т. д.), комбинацию обоих (например, 'RSA+SHA384') или имена схем TLS v1.3 (например, rsa_pss_pss_sha512). См. страницы руководства OpenSSL для получения дополнительной информации.
  • ciphers <строка> Указание набора шифров OpenSSL, заменяющее значение по умолчанию. Для получения дополнительной информации см. изменение набора шифров TLS по умолчанию. Разрешенные шифры можно получить через tls.getCiphers(). Имена шифров должны быть в верхнем регистре для корректного распознавания OpenSSL.
  • clientCertEngine <строка> Имя модуля OpenSSL, который может предоставить сертификат клиента.
  • crl <строка> | <массив строк> | <Буфер> | <массив буферов> PEM-форматированные CRL (списки отзыва сертификатов).
  • dhparam <строка> | <Буфер> Параметры Diffie-Hellman, необходимые для совершенной прямой секретности. Используйте openssl dhparam для создания параметров. Длина ключа должна быть больше или равна 1024 битам, иначе будет выброшено исключение. Хотя 1024 бита допустимы, используйте 2048 бит или больше для большей безопасности. Если параметр опущен или неверен, параметры будут молча проигнорированы, и шифры DHE не будут доступны.
  • ecdhCurve <строка> Строка, описывающая кривую с именем, или список кривых, разделённых двоеточием, или их NID, например P-521:P-384:P-256, для использования в согласовании ключей ECDH. Установите значение auto, чтобы выбрать кривую автоматически. Используйте crypto.getCurves() для получения списка доступных имён кривых. В последних выпусках openssl ecparam -list_curves также отображает имя и описание каждой доступной эллиптической кривой. По умолчанию: tls.DEFAULT_ECDH_CURVE.
  • honorCipherOrder <логическое значение> Попробовать использовать предпочтения набора шифров сервера вместо предпочтений клиента. Когда true, устанавливает SSL_OP_CIPHER_SERVER_PREFERENCE в secureOptions, см. Параметры OpenSSL для получения дополнительной информации.
  • key <строка> | <массив строк> | <Буфер> | <массив буферов> | <массив объектов> Закрытые ключи в формате PEM. PEM позволяет зашифровывать закрытые ключи. Зашифрованные ключи будут расшифрованы с помощью options.passphrase. Можно предоставить несколько ключей с использованием разных алгоритмов, либо в виде массива незашифрованных строк или буферов ключей, либо в виде массива объектов в формате {pem: <string|buffer>[, passphrase: <string>]}. Формат объекта может быть только в массиве. object.passphrase необязательно. Зашифрованные ключи будут расшифрованы с помощью object.passphrase, если предоставлено, или options.passphrase в противном случае.
  • privateKeyEngine <строка> Имя модуля OpenSSL для получения закрытого ключа. Используется вместе с privateKeyIdentifier.
  • privateKeyIdentifier <строка> Идентификатор закрытого ключа, управляемого модулем OpenSSL. Используется вместе с privateKeyEngine. Не должно быть установлено вместе с key, потому что оба параметра определяют закрытый ключ по-разному.
  • maxVersion <строка> Необязательно установите максимальную версию TLS, которую разрешено использовать. Одно из значений: 'TLSv1.3', 'TLSv1.2', 'TLSv1.1' или 'TLSv1'. Не может быть указано вместе с параметром secureProtocol; используйте один или другой. По умолчанию: tls.DEFAULT_MAX_VERSION.
  • minVersion <строка> Необязательно установите минимальную версию TLS, которую разрешено использовать. Одно из значений: 'TLSv1.3', 'TLSv1.2', 'TLSv1.1' или 'TLSv1'. Не может быть указано вместе с параметром secureProtocol; используйте один или другой. Избегайте установки значения меньше TLSv1.2, но это может потребоваться для межсетевой совместимости. По умолчанию: tls.DEFAULT_MIN_VERSION.
  • passphrase <строка> Общий пароль, используемый для одного закрытого ключа и/или PFX.
  • pfx <строка> | <массив строк> | <Буфер> | <массив буферов> | <массив объектов> PFX или PKCS12 закрытый ключ и цепочка сертификатов. pfx - альтернатива предоставлению key и cert по отдельности. PFX обычно зашифрован, если это так, passphrase будет использоваться для его расшифровки. Можно предоставить несколько PFX в виде массива незашифрованных буферов PFX или массива объектов в формате {buf: <string|buffer>[, passphrase: <string>]}. Формат объекта может быть только в массиве. object.passphrase необязательно. Зашифрованный PFX будет расшифрован с помощью object.passphrase, если предоставлено, или options.passphrase в противном случае.
  • secureOptions <число> Необязательно повлиять на поведение протокола OpenSSL, что обычно не требуется. Следует использовать с осторожностью! Значение - это числовая битовая маска параметров SSL_OP_* из Параметров OpenSSL.
  • secureProtocol <строка> Устаревший механизм выбора версии протокола TLS для использования, не поддерживает независимый контроль минимальной и максимальной версии, и не поддерживает ограничение протокола TLSv1.3. Используйте minVersion и maxVersion вместо этого. Возможные значения перечислены как SSL_METHODS, используйте имена функций в качестве строк. Например, используйте 'TLSv1_1_method' для принудительного использования TLS версии 1.1 или 'TLS_method' для разрешения любой версии протокола TLS до TLSv1.3. Не рекомендуется использовать версии TLS менее 1.2, но это может потребоваться для межсетевой совместимости. По умолчанию: ничего, см. minVersion.

• • sessionIdContext <string> Идентификатор, используемый серверами для предотвращения совместного использования состояния сеанса между приложениями. Не используется клиентами.
  • ticketKeys: <Buffer> 48 байт криптографически сильной псевдослучайной данных. Дополнительную информацию см. в разделе Возобновление сеанса.
  • sessionTimeout <number> Количество секунд, после которого сеанс TLS, созданный сервером, больше не будет возобновляемым. Дополнительную информацию см. в разделе Возобновление сеанса. По умолчанию: 300.

tls.createServer() устанавливает значение по умолчанию для параметра honorCipherOrder в значение true. Другие API, создающие защищённые контексты, не устанавливают значение по умолчанию.

tls.createServer() использует 128-битное усечённое значение хеша SHA1, сгенерированное из process.argv, как значение по умолчанию для параметра sessionIdContext. Другие API, создающие защищённые контексты, не имеют значения по умолчанию.

Метод tls.createSecureContext() создаёт объект SecureContext. Он может быть использован в качестве аргумента для нескольких API tls, таких как tls.createServer() и server.addContext(), но не имеет публичных методов.

Ключ требуется для шифров, использующих сертификаты. Для его предоставления можно использовать либо key, либо pfx.

Если параметр ca не задан, Node.js по умолчанию будет использовать общедоступный доверенный список CA от Mozilla.

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

• context <Объект> Объект защищённого контекста, возвращаемый tls.createSecureContext()
• isServer <boolean> true для указания, что это соединение TLS должно быть открыто как сервер.
• requestCert <boolean> true для указания, должен ли сервер запрашивать сертификат от подключаемого клиента. Применимо только в том случае, если isServer равно true.
• rejectUnauthorized <boolean> Если не false, сервер автоматически отклоняет клиентов с недействительными сертификатами. Применимо только в том случае, если isServer равно true.
• options
  • enableTrace: См. tls.createServer()
  • secureContext: Объект контекста TLS из tls.createSecureContext()
  • isServer: Если true, сокет TLS будет инициализирован в режиме сервера. По умолчанию: false.
  • server <net.Server> Экземпляр net.Server
  • requestCert: См. tls.createServer()
  • rejectUnauthorized: См. tls.createServer()
  • ALPNProtocols: См. tls.createServer()
  • SNICallback: См. tls.createServer()
  • session <Buffer> Экземпляр Buffer, содержащий сеанс TLS.
  • requestOCSP <boolean> Если true, указывает, что расширение запроса статуса OCSP будет добавлено в приветствие клиента, и событие 'OCSPResponse' будет выброшено в сокет перед установлением защищённого соединения.

Создаёт новый объект защищённой пары со двумя потоками, один из которых читает и записывает зашифрованные данные, а другой — читает и записывает открытый текст. Обычно зашифрованный поток передаётся в/из входящий зашифрованный поток данных, а поток открытого текста используется в качестве замены начального зашифрованного потока.

tls.createSecurePair() возвращает объект tls.SecurePair с свойствами потоков cleartext и encrypted.

Использование cleartext имеет тот же API, что и tls.TLSSocket.

Метод tls.createSecurePair() теперь устарел в пользу tls.TLSSocket(). Например, код:

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

можно заменить на:

secureSocket = tls.TLSSocket(socket, options);

где secureSocket имеет тот же API, что и pair.cleartext.

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

• options <Объект>

  • ALPNProtocols: <строковый массив> | <Буферный массив> | <Массив TypedArray> | <Массив DataView> | <Буфер> | <TypedArray> | <DataView> Массив строк, Buffer, TypedArray или DataView, или одиночный Buffer, TypedArray или DataView, содержащий поддерживаемые протоколы ALPN. Buffer должны иметь формат [len][name][len][name]..., например, 0x05hello0x05world, где первый байт – длина следующего имени протокола. Передача массива обычно намного проще, например, ['hello', 'world']. (Протоколы должны быть упорядочены по приоритету.)

  • clientCertEngine <строка> Имя OpenSSL-движка, который может предоставить сертификат клиента.

  • enableTrace <логическое значение> Если true, tls.TLSSocket.enableTrace() будет вызываться для новых подключений. Отслеживание можно включить после установления защищённого соединения, но эта опция необходима для отслеживания процесса установки защищённого соединения. По умолчанию: false.

  • handshakeTimeout <число> Прервать соединение, если рукопожатие SSL/TLS не завершится в указанное количество миллисекунд. 'tlsClientError' будет испускаться объектом tls.Server всякий раз, когда рукопожатие истечёт. По умолчанию: 120000 (120 секунд).

  • rejectUnauthorized <логическое значение> Если не false, сервер отклонит любое подключение, которое не авторизовано предоставленным списком CA. Эта опция работает только если requestCert равно true. По умолчанию: true.

  • requestCert <логическое значение> Если true, сервер запросит сертификат у подключённых клиентов и попытается проверить этот сертификат. По умолчанию: false.

  • sessionTimeout <число> Количество секунд, по истечении которых сессия TLS, созданная сервером, больше не будет возобновляемой. Дополнительную информацию см. в Возобновлении сеансов. По умолчанию: 300.

  • SNICallback(servername, callback) <Функция> Функция, которая будет вызвана, если клиент поддерживает расширение SNI TLS. При вызове будут переданы два аргумента: servername и callback. error — это обратный вызов, обрабатывающий ошибки, принимающий два необязательных аргумента: error и ctx. ctx, если предоставлено, является экземпляром SecureContext. tls.createSecureContext() может быть использован для получения необходимого SecureContext. Если callback вызывается с ложным аргументом ctx, используется по умолчанию защищённый контекст сервера. Если SNICallback не предоставлено, используется по умолчанию обратный вызов с высокоуровневым API (см. ниже).

  • ticketKeys: <Буфер> 48 байт криптографически сильных псевдослучайных данных. Дополнительную информацию см. в Возобновлении сеансов.

  • pskCallback <Функция>

    • socket: <tls.TLSSocket> экземпляр серверного tls.TLSSocket для этого соединения.
    • identity: <строка> параметр идентификации, отправленный клиентом.
    • Возвращает: <Буфер> | <TypedArray> | <DataView> предварительно согласованный ключ, который должен быть буфером или null для остановки процесса переговоров. Возвращаемый PSK должен быть совместим с выбранным хэш-алгоритмом.

    При переговорах TLS-PSK (предварительно согласованных ключей) эта функция вызывается с идентификатором, предоставленным клиентом. Если возвращаемое значение равно null, процесс переговоров остановится, и клиенту будет отправлено сообщение об «неизвестном идентификаторе PSK». Если сервер хочет скрыть тот факт, что идентификатор PSK не был известен, обратный вызов должен предоставить некоторые случайные данные в качестве psk, чтобы подключение завершилось ошибкой «decrypt_error», прежде чем переговоры закончатся. PSK-шифры по умолчанию отключены, и для использования TLS-PSK необходимо явно указать набор шифров с помощью опции ciphers. Дополнительную информацию можно найти в RFC 4279.

  • pskIdentityHint <строка> необязательное сообщение, которое отправляется клиенту для помощи в выборе идентификации во время переговоров TLS-PSK. Будет проигнорировано в TLS 1.3. При ошибке установки pskIdentityHint будет испускаться 'tlsClientError' с кодом 'ERR_TLS_PSK_SET_IDENTIY_HINT_FAILED'.

  • ...: Любая опция tls.createSecureContext() может быть предоставлена. Для серверов обычно необходимы параметры идентификации (pfx, key/cert или pskCallback).

  • ...: Любая опция net.createServer() может быть предоставлена.

• secureConnectionListener <Функция>
• Возвращает: <tls.Сервер>

Создаёт новый tls.Server. Опция secureConnectionListener, если указана, автоматически устанавливается как обработчик события 'secureConnection'.

Опции ticketKeys автоматически обмениваются между рабочими процессами модуля cluster.

Пример простого сервера эхо:

const tls = require('tls');
const fs = require('fs');

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

  // This is necessary only if using client certificate authentication.
  requestCert: true,

  // This is necessary only if the client uses a self-signed certificate.
  ca: [ fs.readFileSync('client-cert.pem') ]
};

const server = tls.createServer(options, (socket) => {
  console.log('server connected',
              socket.authorized ? 'authorized' : 'unauthorized');
  socket.write('welcome!\n');
  socket.setEncoding('utf8');
  socket.pipe(socket);
});
server.listen(8000, () => {
  console.log('server bound');
});

Сервер можно проверить, подключившись к нему с помощью примерного клиента из tls.connect().

tls.getCiphers()

• Возвращает: <строковый массив>

Возвращает массив с именами поддерживаемых TLS-шифров. Имена по историческим причинам в нижнем регистре, но должны быть приведены к верхнему регистру для использования в опции ciphers tls.createSecureContext().

Имена шифров, начинающиеся с 'tls_', предназначены для TLSv1.3, все остальные — для TLSv1.2 и ниже.

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

tls.rootCertificates

• <строковый массив>

Неизменяемый массив строк, представляющих корневые сертификаты (в формате PEM) из встроенного хранилища сертификатов Mozilla CA, предоставляемого текущей версией Node.js.

Встроенное хранилище CA, предоставляемое Node.js, представляет собой моментальный снимок хранилища сертификатов Mozilla CA, фиксируемый во время выпуска. Оно одинаково на всех поддерживаемых платформах.

tls.DEFAULT_ECDH_CURVE

Имя кривой по умолчанию для согласования ключей ECDH на сервере tls. Значение по умолчанию — 'auto'. Дополнительную информацию см. в tls.createSecureContext().

tls.DEFAULT_MAX_VERSION

• <string> Значение по умолчанию параметра maxVersion опции tls.createSecureContext(). Можно назначить любое из поддерживаемых версий протокола TLS, такие как 'TLSv1.3', 'TLSv1.2', 'TLSv1.1' или 'TLSv1'. По умолчанию: 'TLSv1.3', если не изменено с помощью опций командной строки. Использование --tls-max-v1.2 устанавливает значение по умолчанию в 'TLSv1.2'. Использование --tls-max-v1.3 устанавливает значение по умолчанию в 'TLSv1.3'. Если указано несколько опций, используется максимальное значение.

tls.DEFAULT_MIN_VERSION

• <string> Значение по умолчанию параметра minVersion опции tls.createSecureContext(). Можно назначить любое из поддерживаемых версий протокола TLS, такие как 'TLSv1.3', 'TLSv1.2', 'TLSv1.1' или 'TLSv1'. По умолчанию: 'TLSv1.2', если не изменено с помощью опций командной строки. Использование --tls-min-v1.0 устанавливает значение по умолчанию в 'TLSv1'. Использование --tls-min-v1.1 устанавливает значение по умолчанию в 'TLSv1.1'. Использование --tls-min-v1.3 устанавливает значение по умолчанию в 'TLSv1.3'. Если указано несколько опций, используется минимальное значение.