RU TLS: Some rename

Author: iambabyninja

docs/ru/config/transport.md

@@ -106,7 +106,7 @@ Reality — это самое безопасное на данный момен
 ```json
 {
   "serverName": "xray.com",
-  "verifyPeerCertInNames": "",
+  "verifyPeerCertByName": "",
   "rejectUnknownSni": false,
   "allowInsecure": false,
   "alpn": ["h2", "http/1.1"],
@@ -134,15 +134,9 @@ Reality — это самое безопасное на данный момен
 
 Специальное значение `"FromMitM"`. Это заставит использовать SNI, содержащийся в TLS, который был расшифрован входящим соединением dokodemo-door.
 
-::: tip
-Как упоминалось выше, поскольку это значение также используется для проверки действительности сертификата сервера, если вы измените его на доменное имя, отличное от доменного имени сертификата сервера, необходимо включить `allowInsecure`, иначе произойдет сбой проверки сертификата. Из соображений безопасности мы не рекомендуем использовать этот метод в течение длительного времени. Если вам нужно безопасно подделать SNI, рассмотрите возможность использования REALITY.
-
-В частности, если клиент устанавливает его в IP-адрес, Xray не будет отправлять SNI, и для использования этой функции также необходимо включить `allowInsecure`.
-:::
+> `verifyPeerCertByName`: string
 
-> `verifyPeerCertInNames`: \[ string \]
-
-Только для клиента. Список SNI, используемый для проверки сертификата (достаточно, чтобы хотя бы один SAN из сертификата находился в этом списке). Этот список переопределит `serverName`, который используется для проверки, и предназначен для особых целей, таких как domain fronting. По сравнению с предыдущим методом изменения `serverName` и включения `allowInsecure`, этот способ более безопасен, так как он по-прежнему выполняет проверку подписи сертификата.
+Только для клиента. Используется для SNI при проверке сертификата. Можно указать несколько доменов, разделяя их `,` (достаточно, чтобы хотя бы один SAN сертификата присутствовал в этом списке). Это переопределит `serverName`, используемый для проверки; применяется для маскировки домена (Domain Fronting) и других специальных целей.
 
 Специальное значение `"FromMitM"`: при его использовании в список будет дополнительно добавлен SNI из TLS-трафика, расшифрованного входящим соединением `dokodomo-door`.
 
@@ -181,7 +175,9 @@ Reality — это самое безопасное на данный момен
 Если значение равно `true`, то Xray не будет проверять действительность сертификата TLS, предоставленного удаленным хостом.
 
 ::: danger
-Из соображений безопасности этот параметр не следует устанавливать в значение `true` в реальных сценариях, иначе вы можете подвергнуться атаке типа «человек посередине».
+~~Из соображений безопасности этот параметр не следует устанавливать в значение `true` в реальных сценариях, иначе вы можете подвергнуться атаке типа «человек посередине».~~
+
+Эта опция устарела. Используйте `pinnedPeerCertSha256` для ручного указания необходимого сертификата.
 :::
 
 > `disableSystemRoot`: true | false
@@ -240,19 +236,19 @@ Reality — это самое безопасное на данный момен
 ::: tip
 При использовании этой функции некоторые параметры TLS, влияющие на отпечаток TLS, будут переопределены библиотекой utls и не будут действовать, например, ALPN.
 Передаваемые параметры:
-`"serverName" "allowInsecure" "disableSystemRoot" "pinnedPeerCertSha256" "masterKeyLog"`
+`"serverName" "disableSystemRoot" "pinnedPeerCertSha256" "masterKeyLog"`
 :::
 
 > `pinnedPeerCertSha256`: string
 
-Используется для указания хеш-суммы SHA256 сертификата удаленного сервера; формат hex, регистр не учитывается. Например: `e8e2d387fdbffeb38e9c9065cf30a97ee23c0e3d32ee6f78ffae40966befccc9`. Эта кодировка совпадает с отпечатком сертификата SHA-256 в просмотрщике сертификатов Chrome, а также с форматом Certificate Fingerprints SHA-256 на crt.sh. Также для вычисления можно использовать команду `xray tls leafCertHash --cert <cert.pem>`. Можно использовать символ `-` для объединения нескольких хеш-значений; проверка считается пройденной при совпадении с любым из них.
+Используется для указания SHA256-хеша сертификата удаленного сервера. Используется шестнадцатеричный формат (hex), регистр не важен. Например: `e8e2d387fdbffeb38e9c9065cf30a97ee23c0e3d32ee6f78ffae40966befccc9`. Можно перечислить несколько хешей через запятую `,`; проверка считается пройденной при совпадении любого из них.
 
-Эта проверка выполняется только после успешного завершения стандартной проверки сертификата и делится на два случая:
+Эта кодировка совпадает с отпечатком SHA-256 в просмотрщике сертификатов Chrome, а также с форматом Certificate Fingerprints SHA-256 на сайте crt.sh. Значение можно вычислить с помощью команды `xray tls leafCertHash --cert <cert.pem>` или `openssl x509 -noout -fingerprint -sha256 -in cert.pem` (формат с двоеточиями, который она генерирует, также поддерживается). Команда `xray tls ping` также выводит SHA256-хеш удаленного сертификата.
 
-- 1. Когда ядро обнаруживает, что совпадающий хеш принадлежит конечному (leaf) сертификату, проверка проходит сразу.
-- 2. Когда ядро обнаруживает, что совпадающее значение принадлежит сертификату CA (это может быть корневой или промежуточный сертификат), проверяется, действительно ли подпись на конечном сертификате авторизована этим CA.
+Эта проверка переопределяет стандартную валидацию сертификатов. Возможны два сценария:
 
-Перед этой проверкой сначала выполняется стандартная проверка сертификата, поэтому для самоподписанных сертификатов можно рассмотреть возможность включения `allowInsecure` с настройкой хеша здесь, а для самоподписанных CA можно закрепить (pin) CA здесь и настроить `verifyPeerCertInNames` (сертификат CA, используемый в процессе его проверки, будет заменен сертификатом CA, найденным здесь).
+- 1. Если ядро находит совпадающий хеш для конечного (leaf) сертификата, проверка сразу же проходит успешно.
+- 2. Если ядро находит совпадающий хеш для сертификата CA (это может быть корневой или промежуточный сертификат), оно проверит, подписан ли конечный сертификат этим CA, используя для валидации значение из `serverName`.
 
 > `certificates`: \[ [CertificateObject](#certificateobject) \]