mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2026-09-22 22:38:05 +03:00
TLS: Some rename
RU TLS: Some rename EN TLS: Some rename
This commit is contained in:
Fangliding
+12
-14
@@ -107,7 +107,7 @@ Reality 是目前最安全的传输加密方案, 且外部看来流量类型和
|
||||
```json
|
||||
{
|
||||
"serverName": "xray.com",
|
||||
"verifyPeerCertInNames": [],
|
||||
"verifyPeerCertByName": "",
|
||||
"rejectUnknownSni": false,
|
||||
"allowInsecure": false,
|
||||
"alpn": ["h2", "http/1.1"],
|
||||
@@ -136,13 +136,9 @@ Reality 是目前最安全的传输加密方案, 且外部看来流量类型和
|
||||
|
||||
特殊值 `"FromMitM"`, 这会使其使用入来自 dokodemo-door 入站解密的 TLS 中包含的 SNI.
|
||||
|
||||
::: tip
|
||||
如上所述，因为该值用于校验服务端证书是否有效，如果出于特殊目的将其修改为与服务端证书域名不一致的需要需要开启 `allowInsecure` 否则会导致证书认证失败。出于安全考虑我们不推荐长期使用这种方法，如果想要安全地伪造SNI，请考虑使用REALITY。
|
||||
:::
|
||||
> `verifyPeerCertByName`: string
|
||||
|
||||
> `verifyPeerCertInNames`: \[ string \]
|
||||
|
||||
仅客户端，用于校验证书使用的 SNI 列表(只需要证书中有一个 SAN 在该列表中即可), 将会覆盖本用于校验的 `serverName`, 用于域前置等特殊目的。 相较于修改 `serverName` 并开启 `allowInsecure` 更加安全，因为其仍会执行证书签名验证。
|
||||
仅客户端，用于校验证书使用的 SNI，可以用 `,` 分割多个域名(只需要证书中有一个 SAN 在该列表中即可), 将会覆盖本用于校验的 `serverName`, 用于域前置等特殊目的。
|
||||
|
||||
特殊值 `"FromMitM"`, 这会使其额外加入来自 dokodemo-door 入站解密的 TLS 中包含的 SNI.
|
||||
|
||||
@@ -182,7 +178,9 @@ CipherSuites 用于配置受支持的密码套件列表, 每个套件名称之
|
||||
当值为 `true` 时，Xray 不会检查远端主机所提供的 TLS 证书的有效性。
|
||||
|
||||
::: danger
|
||||
出于安全性考虑，这个选项不应该在实际场景中选择 true，否则可能遭受中间人攻击。
|
||||
~~出于安全性考虑，这个选项不应该在实际场景中选择 true，否则可能遭受中间人攻击。~~
|
||||
|
||||
该选项已被弃用，使用 `pinnedPeerCertSha256` 手动指定需要的证书。
|
||||
:::
|
||||
|
||||
> `disableSystemRoot`: true | false
|
||||
@@ -229,19 +227,19 @@ CipherSuites 用于配置受支持的密码套件列表, 每个套件名称之
|
||||
::: tip
|
||||
当使用此功能时，TLS 的部分影响TLS指纹的选项将被 utls 库覆盖不再生效，列如ALPN。
|
||||
会被传递的参数有
|
||||
`"serverName" "allowInsecure" "disableSystemRoot" "pinnedPeerCertSha256" "masterKeyLog"`
|
||||
`"serverName" "disableSystemRoot" "pinnedPeerCertSha256" "masterKeyLog"`
|
||||
:::
|
||||
|
||||
> `pinnedPeerCertSha256`: string
|
||||
|
||||
用于指定远程服务器的证书 SHA256 散列值，使用 hex 且大小写不敏感。如 `e8e2d387fdbffeb38e9c9065cf30a97ee23c0e3d32ee6f78ffae40966befccc9`. 该编码与 Chrome 证书查看器 SHA-256 证书指纹，以及 crt.sh 的 Certificate Fingerprints SHA-256 格式均相同。也可以使用 `xray tls leafCertHash --cert <cert.pem>` 进行计算。可以使用 `~` 连接更多的散列值，匹配到任何一个即通过验证。
|
||||
用于指定远程服务器的证书 SHA256 散列值，使用 hex 且大小写不敏感。如 `e8e2d387fdbffeb38e9c9065cf30a97ee23c0e3d32ee6f78ffae40966befccc9`，可以使用 `,` 连接更多的散列值，匹配到任何一个即通过验证。
|
||||
|
||||
该验证在正常证书验证成功后才会调用，分为两种情况。
|
||||
该编码与 Chrome 证书查看器 SHA-256 证书指纹，以及 crt.sh 的 Certificate Fingerprints SHA-256 格式均相同。可以使用 `xray tls leafCertHash --cert <cert.pem>` 进行计算，也可以使用 `openssl x509 -noout -fingerprint -sha256 -in cert.pem` （兼容它生成的带冒号的格式）， `xray tls ping` 同样会输出远程证书的 SHA256 散列值。
|
||||
|
||||
该验证将覆盖默认的证书校验，分两种情况：
|
||||
|
||||
- 1.当核心找到匹配的散列值为叶子证书，验证直接通过。
|
||||
- 2.当核心找到匹配的值为 CA 证书（可以是根证书也可以是中级证书），将验证叶子证书上的签名是否来自该 CA 授权。
|
||||
|
||||
在该验证前会先执行正常的证书验证，故自签证书可以考虑开启 `allowInsecure` 并在此配置散列，而自签 CA 可以在这里 pin CA 并设置 `verifyPeerCertInNames` （其验证流程使用的 CA 证书将会被这里找到的 CA 证书替换）
|
||||
- 2.当核心找到匹配的值为 CA 证书（可以是根证书也可以是中级证书），将使用 `serverName` 里的值验证叶子证书上的签名是否来自该 CA 授权。
|
||||
|
||||
> `certificates`: \[ [CertificateObject](#certificateobject) \]
|
||||
|
||||
|
||||
+12
-14
@@ -106,7 +106,7 @@ Specific configurations related to transparent proxying.
|
||||
```json
|
||||
{
|
||||
"serverName": "xray.com",
|
||||
"verifyPeerCertInNames": [],
|
||||
"verifyPeerCertByName": "",
|
||||
"rejectUnknownSni": false,
|
||||
"allowInsecure": false,
|
||||
"alpn": ["h2", "http/1.1"],
|
||||
@@ -135,13 +135,9 @@ When left empty, the value in `address` (if it is a domain name) is automaticall
|
||||
|
||||
Special value `"FromMitM"`: This causes it to use the SNI contained in the TLS decrypted from the dokodemo-door inbound.
|
||||
|
||||
::: tip
|
||||
As mentioned above, since this value is used to verify whether the server certificate is valid, if you modify it to be inconsistent with the server certificate domain for special purposes, you need to enable `allowInsecure`; otherwise, certificate authentication will fail. For security reasons, we do not recommend using this method for a long time. If you want to securely spoof SNI, please consider using REALITY.
|
||||
:::
|
||||
> `verifyPeerCertByName`: string
|
||||
|
||||
> `verifyPeerCertInNames`: \[ string \]
|
||||
|
||||
Client-only. List of SNIs used to verify certificates (only one SAN in the certificate needs to be in this list). This will override `serverName` used for verification, used for special purposes like domain fronting. It is safer than modifying `serverName` and enabling `allowInsecure` because it still performs certificate signature verification.
|
||||
Client-only. The SNI used for certificate verification. Multiple domains can be separated by `,` (only one SAN in the certificate needs to be in this list). This will override the `serverName` used for verification, intended for special purposes such as domain fronting.
|
||||
|
||||
Special value `"FromMitM"`: This causes it to additionally include the SNI contained in the TLS decrypted from the dokodemo-door inbound.
|
||||
|
||||
@@ -180,7 +176,9 @@ Whether to allow insecure connections (client-only). Default value is `false`.
|
||||
When set to `true`, Xray will not check the validity of the TLS certificate provided by the remote host.
|
||||
|
||||
::: danger
|
||||
For security reasons, this option should not be set to `true` in actual scenarios, otherwise, you may suffer from Man-in-the-Middle attacks.
|
||||
~~For security reasons, this option should not be set to `true` in actual scenarios, otherwise, you may suffer from Man-in-the-Middle attacks.~~
|
||||
|
||||
This option is deprecated. Use `pinnedPeerCertSha256` to manually specify the required certificate.
|
||||
:::
|
||||
|
||||
> `disableSystemRoot`: true | false
|
||||
@@ -224,19 +222,19 @@ This feature only **simulates** the `TLS Client Hello` fingerprint. Behavior and
|
||||
::: tip
|
||||
When using this feature, some TLS options affecting TLS fingerprints will be overwritten by the uTLS library and will no longer take effect, such as ALPN.
|
||||
Parameters passed include:
|
||||
`"serverName"`, `"allowInsecure"`, `"disableSystemRoot"`, `"pinnedPeerCertSha256"`, `"masterKeyLog"`.
|
||||
`"serverName"`, `"disableSystemRoot"`, `"pinnedPeerCertSha256"`, `"masterKeyLog"`.
|
||||
:::
|
||||
|
||||
> `pinnedPeerCertSha256`: string
|
||||
|
||||
Used to specify the remote server's certificate SHA256 hash. Uses hex and is case-insensitive. Example: `e8e2d387fdbffeb38e9c9065cf30a97ee23c0e3d32ee6f78ffae40966befccc9`. This encoding is the same as the SHA-256 certificate fingerprint in Chrome certificate viewer and the Certificate Fingerprints SHA-256 format on crt.sh. It can also be calculated using `xray tls leafCertHash --cert <cert.pem>`. You can use `~` to connect more hash values; verification passes if any one matches.
|
||||
Used to specify the SHA256 hash of the remote server's certificate. It uses hex encoding and is case-insensitive. For example: `e8e2d387fdbffeb38e9c9065cf30a97ee23c0e3d32ee6f78ffae40966befccc9`. You can specify multiple hash values separated by `,`; verification passes if any of them match.
|
||||
|
||||
This verification is called only after normal certificate verification succeeds. There are two cases:
|
||||
This encoding matches the SHA-256 Certificate Fingerprint found in the Chrome certificate viewer and the format used on crt.sh. You can calculate it using `xray tls leafCertHash --cert <cert.pem>` or `openssl x509 -noout -fingerprint -sha256 -in cert.pem` (the format with colons generated by OpenSSL is supported). Additionally, `xray tls ping` will output the remote certificate's SHA256 hash.
|
||||
|
||||
- 1. When the core finds a matching hash value for the leaf certificate, verification passes directly.
|
||||
- 2. When the core finds a matching value for a CA certificate (root or intermediate), it verifies if the signature on the leaf certificate comes from that CA authorization.
|
||||
This mechanism overrides the default certificate validation and operates in two scenarios:
|
||||
|
||||
Normal certificate verification is performed before this verification. Therefore, for self-signed certificates, consider enabling `allowInsecure` and configuring the hash here. For self-signed CAs, you can pin the CA here and set `verifyPeerCertInNames` (the CA certificate used in its verification flow will be replaced by the CA certificate found here).
|
||||
- 1. If the core finds that the matching hash belongs to a leaf certificate, verification passes immediately.
|
||||
- 2. If the core finds that the matching hash belongs to a CA certificate (either a root or intermediate certificate), it will use the value in `serverName` to verify if the leaf certificate is validly signed by that CA.
|
||||
|
||||
> `certificates`: \[ [CertificateObject](#certificateobject) \]
|
||||
|
||||
|
||||
+12
-16
@@ -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.
|
||||
> `verifyPeerCertByName`: string
|
||||
|
||||
В частности, если клиент устанавливает его в IP-адрес, Xray не будет отправлять SNI, и для использования этой функции также необходимо включить `allowInsecure`.
|
||||
:::
|
||||
|
||||
> `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) \]
|
||||
|
||||
|
||||
Reference in New Issue
Block a user