# @ai-ecoverse/wasm-tls-engine 中文文档

规范地址：https://npmcn.com/package/%40ai-ecoverse/wasm-tls-engine/

版本：4\.2\.0-12
npm 元数据更新时间：2026-10-24T03:43:13.789Z
中文译文更新时间：2026-11-05T20:21:49.602Z
软件包许可：Apache-2\.0 AND MPL-2\.0

本文由上游 README 翻译，可能存在偏差，请结合原文核对 API、命令与配置。版权与许可归原作者所有。

原始 npm 页面：https://www.npmjs.com/package/%40ai-ecoverse/wasm-tls-engine
原文对照：https://npmcn.com/package/%40ai-ecoverse/wasm-tls-engine/?lang=original
项目主页：https://github.com/ai-ecoverse/homescoop/tree/main/packages/tls-engine
源码仓库：https://github.com/ai-ecoverse/homescoop

## 关键信息（来自 npm 元数据）

- 包体积（解压后）：575 kB，8 个文件
- 模块格式：ES Module
- TypeScript 类型：包内自带
- 运行依赖：0 个
- 首次发布：2026-09-28T21:05:28.413Z
- 最新版本发布：2026-10-24T03:43:13.435Z
- 近 30 天下载量：29291（2026-10-05 至 2026-11-03，npm 官方下载统计）
- 已发布版本数：14（近 12 个月 14 个）

## 中文简介

安全(TLS)网络连接 slic.

## 安装

```sh
npm install @ai-ecoverse/wasm-tls-engine
```

也可以使用：`pnpm add @ai-ecoverse/wasm-tls-engine`、`yarn add @ai-ecoverse/wasm-tls-engine`、`bun add @ai-ecoverse/wasm-tls-engine`

## README

# @ai-ecoverse/wasm-tls-engine (英语)

TLS 用于 [系统](https://github.com/ai-ecoverse/slicc): Mbed TLS 4.2.0会话在内存缓冲器之上,与 Emscripten 一起编译到一个ES 模块工厂 + `slicc-tls-engine.wasm`。 。 。 .

-   **服务器会话** 服务 SLICC 的原真 HTTP 代理 (ai- ecoverse/ slic# 3571).
-   **客户会话** 验证服务器,用于 slic-内核的生 TLS(ai-ecoverse/slic-内核#922).
-   两者都在一个原地中,被它的召唤者懒惰地装载.

## 服务器会话

-   引擎稳住 **无 CA 密钥**。 。 。 . `tls_leaf_new` 生成一对P-256键,以及 `tls_leaf_spki` 只把公用钥匙拿出来 呼叫者建立并签名 叶证书,并给回链 `tls_leaf_add_cert`。 。 。 .
-   每条CONNECT隧道有一个会话(`tls_session_new(leaf, host)`),客户端的SNI必须命名 `host`ALPN提议 `http/1.1` 只有这个 TLS 1.2和 1.3.

### 一个程序自己的TLS服务器( 4. 2. 0-8, homecoop# 1638)

-   **`tls_leaf_import(chain, chain_len, key, key_len, pass, pass_len)`** 制作来自呼叫者链的叶子(简洁的DER,其叶子为先)和私钥;失败时为0 `tls_last_error`。 。 。 .
    -   密钥被解析为 `tls_client_cert` 解析: PEM( NUL 计数于 `key_len`)或 DER、PKCS#8、SEC1或PKCS#1,可选加密 `pass` (单位:千美元)`0, 0` );RSA最多可达8192位和NIST EC曲线.
    -   拒绝的也是同样的错误: `TLS_BADARG` 对于一个与叶子不相匹配的键(对于一个空链或键), `TLS_RSA_TOO_LARGE` 用于一个 RSA 密钥超过 8192 位的链式证书,以及 Mbed TLS 自己的 PK 错误或缺失的密码句。 没有错误文本 .
    -   一样 `tls_client_cert`,引擎会擦去密钥并给出密码字节,无论导入成功与否;它会保留自己的副本,在叶子去后零化.
    -   叶子为任何会议服务。 它的重新计算像 `tls_leaf_new`': `tls_leaf_free` 放弃调用者的引用,每个会话都会自己举行.
-   **`tls_server_new(leaf, alpn, alpn_len, client_ca, flags)`** 是服务器会话,对客户端的SNI没有要求. 其作用于任何叶子的叶子,其叶子的链被设定:入叶;或 `tls_leaf_new` 加号 `tls_leaf_add_cert`。 。 。 .
    -   **艾尔平:** `alpn` a. 服务器优先级中的有线格式列表(长前缀名称); `0, 0` 没有。 当客户端提供多个时,服务器的第一个客户端也会提供胜利. 提供 ALPN 的客户端, 但服务器的协议中没有任何一个失败 `no_application_protocol` 警报(RFC 7301,Mbed TLS的行为). 客户端不提供,或服务器没有列表,则不同意(`tls_alpn` 给 0 。 一个错误的列表是 `TLS_BADARG`。 。 。 .
    -   **客户端证书 :** 与 `client_ca` 联合国 `tls_ca_new` 存储, `TLS_SERVER_REQUEST_CERT` ( 一 ) 索取 一 个 、 让 手 握 完 无 一 个 、 有 一 个 不 核实 的 ; `tls_verify_result` 然后说查证结果 由打电话者决定. `TLS_SERVER_REQUIRE_CERT` ( 二 ) 没有 证明 、 无法 握手 `client_ca` (当证书列出扩展密钥用途时的链条、有效性和客户端Auth). 标记为 0 的证书是否 `client_ca` 是否设定。 没有旗帜 `client_ca`两面相通的旗子 或除此之外的任何一点, `TLS_SERVER_SELECT` (4,以下)和 `TLS_KEYLOG` (8个,两边) `TLS_BADARG`,因此服务器不能认为不需要证书。 本届会议参考文件如下: `client_ca`。 。 。 .
    -   TLS 1.2和1.3,作为 `tls_session_new`I/O电话, `tls_handshake`, (中文(简体) ), `tls_alpn`, (中文(简体) ), `tls_version`, (中文(简体) ), `tls_ciphersuite`, (中文(简体) ), `tls_peer_count`编号 :`tls_peer_der` (客户链)和 `tls_verify_result` (客户端证书的旗子)进行. `tls_client_cert` 服务器会话为 `TLS_BADARG`。 。 。 .
-   **`tls_sni(session, out, max)`** 在开始时给出客户端发送的服务器名称 `out`:它的长度,当客户端发送无(或客户端Hello之前)时为0,或 `TLS_BADARG` 何时 `max` 这太小了 服务器会话拒绝一个256字节或以上的SNI(握手失败). 在一个 `tls_session_new` 这是SNI必须命名的东道主.

### 拒绝通知(4.2.0-9,housecoop#1765)

拒绝客户端的服务器会话会发出客户端能够读取的提醒,在两个版本上:

-   **TLS 1.3 : (英语)** 完成后,一个服务器会在其应用流量密钥下发送(RFC 8446§7.1)。 Mbed TLS 4.2.0 一直用握手键发送,直到客户端完成,所以拒绝客户端证书的提醒是客户端无法解密的记录: OpenSSL说"解密失败或不良记录mac",引擎自己的客户端"MAC消息验证失败". `server-refusal-alerts.patch` 在服务器完成后立即切换服务器的出行密钥(而不是在握手端再次切换,这样可以重置记录序列号). 缺少的证书现在是提醒116(certificate required),Mbed TLS发送了41(没有证书,一个SSL 3的提醒TLS 1.3没有定义). 未验证的证书是 Mbed TLS 的提醒,原因如下: 48 (unknown ca) 或 43 (unsupported certificate) 用于服务器 Auth- only one.
-   **TLS 1.2 : (英语)** 隐藏 TLS 时未发送 `TLS_SERVER_REQUIRE_CERT` 找不到客户端证书 。 补丁发送40 (手摇 故障),如OpenSSL(RFC 5246 §7.4.6). 无法验证的证书已经发出警报了.
-   ALPN的错配是120 (没有应用 protocol) 两者,如前.

### 在客户端Hello(4.2.0-9, homescoop#1766)之后选择叶和ALPN

为了节点 `SNICallback` 财务报告和审定财务报表 `ALPNCallback`(单位:千美元) `tls_server_new` 语句 `TLS_SERVER_SELECT` (4)一旦客户端的客户端Hello进入,在使用任何叶片或ALPN之前暂停.

-   **创建 :** `leaf` 可能为0(稍后选定一个),以及 `alpn` 必须是 `0, 0` (单位:千美元)`TLS_BADARG` 否则:选择设置). 它结合 `TLS_SERVER_REQUEST_CERT` 或者说 `TLS_SERVER_REQUIRE_CERT` 和以前一样.
-   **暂停:** `tls_handshake` 在客户端 Hello 不完整时返回 0,然后是 2 (“选择”). `tls_read` 财务报告和审定财务报表 `tls_write` 返回时 `TLS_SELECT_PENDING` (4) 在等待的时候。 选择之前没有发送任何信息.
-   **客户要求的:** `tls_sni` 给SNI(零) `tls_client_alpn(session, out, max)` 客户端的ALPN作为线条格式列表(长度前缀名称,按客户端顺序排列):其长度,0为无出价, `TLS_BADARG` 何时 `max` 这太小了 两人握手后仍可读取. 其他会议 `tls_client_alpn` 给0.
-   **`tls_server_select(session, leaf, alpn, alpn_len)`** 设置叶子( 0 保留) `tls_server_new`';会话参考: `tls_server_new` 以及一个ALPN协议`alpn` 名称是字节,而不是列表,或者无(`0, 0`),即使客户提供了一些. 那就开车吧 `tls_handshake` 继续 客户端未提供的名称(或带有NUL字节的名称),完全没有叶子,没有链子的叶子,或者当会话未暂停时的呼叫是 `TLS_BADARG`,则会话暂停.
-   **`tls_server_refuse(session, alert)`** 以致命的警示结束暂停会话:112(未识别出 名称)、120(无 application protocol)、40(手摇 失败)、49(access 拒绝)或80(内部-error)。 下水道 `tls_out`;然后会话的呼叫失败。 任何其它的警报,或者一个没有暂停的会话,是 `TLS_BADARG`。 。 。 .
-   **如何阅读客户端 Hello:** Mbed TLS没有 ALPN 调用,所以引擎从输入的字节读取客户端 Hello 本身,而不消耗它们,然后让Mbed TLS在选择完成后解析相同的字节. 它重新组装一个客户端 Hello 分拆记录(最多32 KiB)并检查其框架. 无法读取的客户端 Hello在提醒下被拒绝 Mbed TLS 发送: 10 (unexpected message) 为不是握手或握手消息,不是客户端 Hello, 22 (record overflow) 为记录超过 16 KiB, 70 (protocol version) 为非 TLS 记录版本, 47 (非法 parameter) 为两个 SNI或两个 ALPN 扩展, 112 为 SNI 为256字节或更多, 以及 50 (decode error) 为任何其它错误的字段. 它无法关闭 : 没有选择, 没有客户端 Hello 到达 Mbed TLS .
-   **交叉检查 :** Mbed TLS的证书回调,在自己解析客户端Hello后,将它的SNI和同意的ALPN与引擎读取的内容和选择的呼叫者进行比较,并在任何区别上都未能握手(40). 这涵盖了一个TLS 1.3 Hello Retry Request:第二个客户端Hello必须携带相同的SNI,没有第二次暂停.

## 客户会话

-   **信托店是打来的.** `tls_ca_new` 做一个空商店. `tls_ca_add_der` 添加一个 DER 根,以及 `tls_ca_add_bundle` 添加缩写 DER, 如包的 `roots.der`,还原它添加了多少根。 在出错( < 0) 时, 它可能在坏的 之前添加了根, 所以丢弃那个商店 。 引擎从不自己装入根.
-   **开始会话 :** `tls_client_new(ca, servername, alpn, alpn_len, flags)` 开始一个。 它将服务器名称取为C字符串,一个有线格式的ALPN列表(长度前缀名; `0, 0` 和旗帜. `tls_client_new_name(ca, servername, servername_len, alpn, alpn_len, flags)` (自 4.2.0-6起) 名称的长度与给定的长度相同: 名称内的一个 NUL 字节被拒绝(`TLS_BADARG`),其中C字符串形式将结束名称. 使用它的名字来自JS.
    -   **需要核查.** 该链必须达到根在 `ca`,叶子必须给服务器取名,每个证书必须在时钟的有效期之内,叶子必须允许服务器使用(扩展KeyUsage serverAuth和KeyUsage).
    -   没有商店,或服务器名称为空,没有会话(`TLS_BADARG`) (中文(简体) ).
    -   **旗帜 :**
        -   `TLS_CLIENT_INSECURE_SKIP_VERIFY` (1)让握手完成链子上所说的一切. `tls_verify_result` 仍报告核查结果.
        -   `TLS_CLIENT_NO_SNI` (2) 不发送SNI。 名称仍与SNI完全相同:通过Mbed TLS自己的检查,在后缀-点条后,一个IP文字只针对一个iPAddress SAN.
        -   **`TLS_CLIENT_VERIFY_CHAIN_ONLY` (4)跳过主机名检查. 呼叫者 MUST 检查服务器本身的身份**,例如与节点 `checkServerIdentity` 打开 `tls_peer_der(s, 0)`. 仍然需要链条、有效性和密钥使用,SNI仍然发送. `tls_name_mismatch` 给出跳过检查的结果,所以报告不匹配,而不是沉默.
        -   只允许0, 1, 2, 4, 1|2和 2|4, 每人可选择使用 `TLS_KEYLOG` (8,两边下. 任何其他组合, CHAIN ONLYINSECURE 和未知的位数, 都被拒绝 .
-   **客户端证书( mTLS) :** `tls_client_cert` 在第一次握手之前取取呼叫者自己的链子(简洁的DER,其叶子先取)和私钥.
    -   密钥为PEM,有NUL计数,或DER:PKCS#8,SEC1或PKCS#1,可选用密码句加密(密码:已加密的私人密钥,两侧下).
    -   **密钥大小** (4.2.0-7, homecoop#1376):RSA密钥可达8192位,而NIST曲线上的EC密钥. 该建筑提高了TF-PSA-Crypto的 `PSA_VENDOR_RSA_MAX_KEY_BITS` 从4096起至8192起`rsa-max-key-bits-8192.patch`),其大号所持有的最多`MBEDTLS_MPI_MAX_SIZE`, 1024字节). 拒绝使用含有较大RSA 密钥的链式证书 `tls_client_cert` 与 `TLS_RSA_TOO_LARGE` (-0x1000,"tls-engine-RSA密钥大于8192位"). 8192位限制是整个引擎的:一个服务器证书或一个有较大RSA密钥的信任存储根无法解析,有Mbed TLS自己的出错.
    -   密钥必须匹配叶子: 另一个证书的密钥被拒绝 `tls_client_cert` (单位:千美元)`TLS_BADARG`在任何握手之前。 。 。 它只来自呼叫者;没有默认.
    -   引擎会擦去密钥并发号施令的字节,一旦解析出来,它就会随会话释放出(零化)它的副本.
-   **密码:** `tls_ciphersuite` 给密码组的IANA号码.
-   **警报:** 与 Mbed TLS 的 FATAL ALERT MESSAGE 握手或读取失败后, `tls_last_alert` 给出服务器发送的提醒的描述编号:116(证书 需要)来自一个想要客户端证书的TLS 1.3服务器,40(手摇 失败)来自一个TLS 1.2 1. 否则,对于一个服务器会话,是 -1.
-   **不握手的链式核查** (4.2.0-5, slic-内核#1090) (中文(简体) ) `tls_chain_verify(store, chain, len, hostname, flagsOut)` 用客户端会话的检查来验证服务器的链条(简洁的DER,其叶子为先)与信任商店的对接. 这些是默认配置文件、 商店的根、 真实时钟的有效性、 叶子的密钥用法和服务器 Auth 扩展密钥用法, 以及会话本身的名称检查: 仅针对一个 iPAddress SAN 的 IP 字节, 一个后继点被剥去 。 它只有在链被验证时返回 0 (旗帜 0), 当它被验证和失败时返回 1 (旗帜说明原因), 或者在设置旗帜时返回 < 0 `0xffffffff`,从0起,对于NULL商店,空的或畸形的链条,分配失败或任何其他错误. **一个 NULL `hostname` 跳过名称检查;然后调用者必须另定服务器身份** (一个SPKI针). 没有什么是保存的. `tls_test_chain_verify_alloc_error()` 使下一个调用失败为分配失败.
-   **未曝光( 已知 ) :** 已谈判达成的密钥交换组和签名算法。 Mbed TLS 4.2.0 也没有公开获取器,只有配置的组列表.
-   **服务器名称 :**
    -   一个 DNS 名称作为 SNI 发送,并与叶子的 DNS 名称核对,因为 Mbed TLS 检查它们(subjectAltName,又称CN).
    -   IPv4或IPv6升不作为SNI(RFC 6066)发送. 它必须与叶子的iPAddress主题AltName相匹配,从不使用DNS名或CN来拼出.
    -   一个后缀( 绝对名称, 如 `example.com.`)被放弃,为SNI和支票都一样.
-   **议定书:** TLS 1.2 最小值和 TLS 1.3 最大值. 没有重新谈判,也没有开会或复会的机会:每一个联系都是全面握手和全面核查.
-   **握个手:** `tls_handshake` 驱动它。 它在握手完成后返回 1,当它需要更多的密码文本时返回 0,否则就是出错. 一个被拒绝的链条是 `MBEDTLS_ERR_X509_CERT_VERIFY_FAILED`。 。 。 .
    -   `tls_verify_result` 给 Mbed TLS 的 `MBEDTLS_X509_BADCERT_*` 旗帜(0=已核实,-1=尚未证书),以及 `tls_verify_info` 把它们放在文字上.
    -   `tls_alpn` 提供商定的议定书,以及 `tls_version` 该版本.
    -   `tls_peer_count` 财务报告和审定财务报表 `tls_peer_der` 给服务器的链条 发送,它的叶子优先.
    -   握手后,I/O为服务器会话'.
    -   `tls_read` 返回 0 时,任何缓冲都无法处理。 TLS 1.3 数据之前的新会议夹在同一电话(homescoop#1032).

### 限制

-   **没有取消检查 :** 无论是OCSP还是CRL,如同节点的默认.
-   **没有复会.**
-   **钟是打电话的 `Date.now()`, (中文(简体) ),** 通过标记 `time()`。错误的时钟页面拒绝有效的证书,或者接受已过期的证书.

## `roots.der`

默认信任商店 呼叫者可能加载 `dist/roots.der`,并导出为 `@ai-ecoverse/wasm-tls-engine/roots.der`。 。 。 .

-   是莫兹拉的根店 **cacert-2026-09-25. pem (英语)**沙256被固定在食谱上 以捆绑的顺序装饰DER.
-   `package.json` 记录日期、来源和散列 `slicc.tls.roots`,所以消费者可以分辨它的年代.
-   这是MPL-2.0数据. `THIRD-PARTY-NOTICES.md` 用那张执照的文本命名它.

## 双方

-   **I/O为拉式:**
    -   `tls_feed` 输入密码;
    -   `tls_read` 给出简单文本( 0 = 需要更多);
    -   `tls_write` 输入正文;
    -   将密码排出 `tls_out_take`。 。 。 .
-   **内存 :** `crypto.getRandomValues` 是PSA随机生成器(TF-PSA-Crypto)的来源,它使每个键和握手. 没有它,一个呼叫失败(`PSA - Insufficient entropy`),从不掷出.
-   `tls_strerror` 命名引擎本身的代码( n)`TLS_EOF`, (中文(简体) ), `TLS_NOMEM`, (中文(简体) ), `TLS_BADARG`, (中文(简体) ), `TLS_SELECT_PENDING`, (中文(简体) ), `TLS_RSA_TOO_LARGE`,作为"tls-engine -.")和TLS,X.509,PK,ASN.1和PSA错误.
-   **网页和工人** (单位:千美元)`-sENVIRONMENT=web,worker`:有"无节点"分支,其" `import('module')` {\\fn黑体\\fs22\\bord1\\shad0\\3aHBE\\4aH00\\fscx67\\fscy66\\2cHFFFFFF\\3cH808080}会用捆绑者的急切图案降落 在节点中,通过模块的字节: `createTlsEngine({ wasmBinary })`。 。 。 .

### 加密的私人密钥(卡梅利亚和ARIA自4.2.0-12起,housecoop#1811起)

`tls_client_cert` 财务报告和审定财务报表 `tls_leaf_import` 以同样的方式分析一个键, 所以这对两者都有利.

-   **PKCS# 8 (中文(简体) ) `ENCRYPTED PRIVATE KEY`** 与 PBES2 和 PBKDF2 (PEM, 或带密码句的 DER) 方案 `openssl pkcs8 -topk8 -v2 <cipher>` 和节点 `KeyObject.export({ type: 'pkcs8', cipher })` 写作。 加密方案可以是AES-128/192/256-CBC、Camellia-128/192/256-CBC(`-v2 camellia128|camellia192|camellia256`,RFC 3657 OIDs 1.2.392.200011.61.1.1.1.2/.3/4)或ARIA-128/192/256-CBC (`-v2 aria-128-cbc|aria-192-cbc|aria-256-cbc`,RFC 5794 OIDs 1.2.410.200046.1.1.2/7/12.
-   **为什么是补丁 :** TF-PSA-Crypto 4.2.0 建造了卡美利亚和阿里亚(`PSA_WANT_KEY_TYPE_CAMELLIA`编号 :`ARIA` 并且有他们的CBC密码, 但PBES2的加密方案表(`oid_cipher_alg` 内 `tf-psa-crypto/utilities/oid.c`)只列出三个AES-CBC OID,所以 `pkcs5.c` 拒绝任何其他方案 `MBEDTLS_ERR_PKCS5_FEATURE_UNAVAILABLE`。 。 。 . `pbes2-camellia-aria.patch` 增加六个OID(在 `utilities/crypto_oid.h`,并分别绘制其地图 `MBEDTLS_CIPHER_*_CBC` 类型。 解密是PBES2自己的路径,没有改变:密钥长度和16字节的IV出自密码,CBC有PKCS#7的活塞活塞. 加密配置和TLS密码套接字,组和签名算法提供和接受的引擎没有改变(证书将其钉入4.2.0-11's).
-   **错误的密码句** 实值 `MBEDTLS_ERR_PK_PASSWORD_MISMATCH` (-0x3B80,"PK-由于私人密钥密码不允许正确解密") AES, Camellia 和 ARIA 都使用; slic-内核将其映射到Node's `ERR_OSSL_BAD_DECRYPT`。加密密钥没有密码句 `MBEDTLS_ERR_PK_PASSWORD_REQUIRED` (-0x3C00) (中文(简体) ).
-   **大约在 256 中 1 个错误的密码句** 解密为垃圾, 其最后一个字节恰好是有效的 PKCS # 7 编码 。 然后将垃圾解析为密钥,错误是: 解析为: ASN 1 或 PK 格式出错 ()`MBEDTLS_ERR_ASN1_UNEXPECTED_TAG`, -0x62, 对于证书的固定病例, 而不是 PASWORD MISMATCH。 OpenSSL 做同样的事情: 节点然后丢出解码器或 ASN 1 出错, 不 `ERR_OSSL_BAD_DECRYPT`。哪一个取决于 OpenSSL 版本 : `ERR_OSSL_UNSUPPORTED` ("DECODER常规:不支持") 有节点26's bunded OpenSSL 3.5, `ERR_OSSL_ASN1_WRONG_TAG` 或者说 `ERR_OSSL_ASN1_HEADER_TOO_LONG` 带有 OpenSSL 4. 证书使用固定的密钥和密码句,因此,哪一行点击从未改变.
-   **与节点的区别 :**
    -   **3DES被拒绝.** Mbed TLS在它的加密器移动到没有DES密码的TF-PSA-Crypto时将DES投放,而引擎没有再添加回. PKCS# 8 密钥, 写有 `-v2 des3` (删除) `MBEDTLS_ERR_PKCS5_FEATURE_UNAVAILABLE` (-0x2E80,"PKCS5-请求加密或文摘 alg不可用") 口令句是对是错:在解密任何内容之前先查看方案. 节取之. 用 `openssl pkcs8 -topk8 -v2 aes-256-cbc`。 。 。 .
    -   **传统的加密 PEM** (单位:千美元)`Proc-Type: 4,ENCRYPTED` 与 `DEK-Info`,作为 `openssl ec -aes256` 写入)只与 AES- CBC 合作, Mbed TLS 的 PEM 解密; a `DEK-Info: CAMELLIA-256-CBC` 密钥被拒绝使用 `MBEDTLS_ERR_PEM_UNKNOWN_ENC_ALG` (- 0x1280, 哪个 `tls_strerror` 没有名字). 节取之.
    -   PBES1和PKCS#12计划`openssl pkcs8 -v1 …`没有像以前那样支持.

### 关键日志行(4.2.0-10,housecoop#1774;Exporter SECRET自4.2.0-11起,housecoop#1799)

为了节点 `keylog` 事件和 `SSLKEYLOGFILE` (石英-内核#1504). **默认关闭;行是会话的秘密:任何持有它们的人都可以解密会话.**

-   **每届预选** 与 `TLS_KEYLOG` (8) 旗帜 `tls_client_new`, (中文(简体) ), `tls_client_new_name` 或者说 `tls_server_new`它与每个旗子的组合结合起来,这些呼叫被接受;一个被拒绝. `tls_session_new` 没有旗帜,也没有日志.
-   **`tls_keylog(session, out, max)`** 将迄今为止收集的线路排入 `out`: 其长度以字节表示, 0 当无时, 或 `TLS_BADARG` (没有排出) 当 `max` 无法支撑第一整行。 它只发出全线, 尽可能多的合适, 其余的为下一个呼叫; `max` 4096年或更长的时间 总是会夺走一切 线条的出现是握手 得到的秘密,所以排出之后 `tls_handshake`编号 :`tls_read` 并释放一个 `keylog` 每行活动.
-   **线条** 是 NSS 密钥日志格式, 小写十六进制, 每个结尾在 `\n`,客户端随机作为第二个字段:
    -   TLS 1.2 : (英语) `CLIENT_RANDOM <client random> <master secret>`· ;
    -   TLS 1.3, 有5行线: `CLIENT_HANDSHAKE_TRAFFIC_SECRET`, (中文(简体) ), `SERVER_HANDSHAKE_TRAFFIC_SECRET`, (中文(简体) ), `CLIENT_TRAFFIC_SECRET_0` 财务报告和审定财务报表 `SERVER_TRAFFIC_SECRET_0`,来自 Mbed TLS 的 `mbedtls_ssl_set_export_keys_cb`,以及 `EXPORTER_SECRET <client random> <exporter master secret>` (RFC 8446 第7.5段),关于客户端和服务器会话.
    -   它们是OpenSSL为同一会话所写的行(`openssl s_client -keylogfile`,节点的 `keylog`),所有5个在TLS 1.3. 没有早期的数据行:没有恢复会话.
    -   **何处 `EXPORTER_SECRET` 来源:** Mbed TLS 4.2.0的出口回调没有出口主密钥的类型. 它的关键时刻表 获得它与应用程序 交通秘密,一步(`mbedtls_ssl_tls13_derive_application_secrets`,从 `ssl_tls13_generate_application_keys` 内 `library/ssl_tls13_keys.c`输入 `session_negotiate->app_secrets.exporter_master_secret`,然后输出客户端和服务器的应用程序交通秘密。 客户端和服务器通过同一步骤到达 `mbedtls_ssl_tls13_compute_application_transform` (在服务器完成后读取或写入). 所以,当召回报告 `SERVER_APPLICATION_TRAFFIC_SECRET`中,引擎在谈判中读取了会话中的出口商主密钥,该调用的秘密长度(套房的散列长度),并在之后记录 `SERVER_TRAFFIC_SECRET_0`Mbed TLS的源头没有被补上. TLS 1.2 没有出口商主密及其主密 `CLIENT_RANDOM` 线条不变.
-   **没有这面旗帜,什么也没有收集或保存:** 没有注册导出回调, 而会话的密钥日志缓冲度保持为零 .
-   **拨号:** 缓冲器位于会话内. `tls_keylog` 将它伸出的字节零取出(左起而后被零取出) `tls_session_free` 整个缓冲器为零。 给打电话的 `out` 是打电话者的工作.
-   **边界和外溢:** 缓冲器有4096字节。 一个会话有一个握手(没有重新谈判,没有恢复),其行数最多为938字节(包含SHA-384秘密的五道TLS 1.3行:每道是它的标签,一个空格,64个客户端随机位数,一个空格,96个秘密位数和 `\n`,因此163字节外加31,31,23,23和15等标签;TLS 1.2的一行是176),所以即使从未被排出也无法填充. 如果一条线永远不合适,它就被全部抛出:从不截断,也从不覆盖更早的线条,因此缓冲器只保留了完整的线条.
-   **测试钩:** `tls_test_keylog_armed(session)` 当出口回调登记时为 1; `tls_test_keylog_residue(session)` 计出缓冲器的非零字节外加其待取长度(0表示空并被擦去); `tls_test_keylog_cap(session, cap)` 降低一个约束 `TLS_KEYLOG` (b) 会期在握手之前(不超过4096; `TLS_BADARG` 因此,证书可以显示溢出规则。 没有一个读取或改变一个秘密.

类型 : `index.d.ts`。构建: `packages/tls-engine/build.sh` 在家庭库.

## 常见问题

### @ai-ecoverse/wasm-tls-engine 是什么？

安全\(TLS\)网络连接 slic\.

### 如何安装 @ai-ecoverse/wasm-tls-engine？

在项目目录运行 npm install @ai-ecoverse/wasm-tls-engine，或使用 pnpm add / yarn add / bun add。

### @ai-ecoverse/wasm-tls-engine 支持 TypeScript 吗？

支持。包内自带 TypeScript 类型声明（package\.json 声明了 types 入口），安装后即可获得类型提示，无需再安装 @types 包。

### @ai-ecoverse/wasm-tls-engine 支持 ESM 还是 CommonJS？

以 ES Module 形式发布，推荐使用 import 引入。在 CommonJS 项目中，Node\.js 20\.19\+ / 22\.12\+ 可以直接 require\(\) 不含顶层 await 的 ES Module，更早的版本需要改用动态 import\(\)。

### @ai-ecoverse/wasm-tls-engine 可以商用吗？

@ai-ecoverse/wasm-tls-engine 使用 Apache-2\.0 AND MPL-2\.0 许可。声明的许可为 Apache-2\.0 AND MPL-2\.0，请阅读许可原文确认使用条件。以上为概括，不构成法律意见，请以许可原文为准。

### @ai-ecoverse/wasm-tls-engine 的下载量有多少？

根据 npm 官方下载统计，@ai-ecoverse/wasm-tls-engine 在 2026/10/05 – 2026/11/03 这 30 天内被下载 29,291 次，日均约 976 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入，适合横向比较热度，不能直接等同于使用人数。

### @ai-ecoverse/wasm-tls-engine 还在维护吗？

最新版本 4\.2\.0-12 发布于 2026/10/24（12 天前）；至今共发布 14 个版本，其中过去 12 个月发布了 14 个；首次发布于 2026/09/29。发布频率只是参考信号：功能稳定的工具可能很少需要更新，建议结合源码仓库的 issue 和提交记录判断。