我尝试通过已建立的 SSL 连接发送一个 byte[] ()(握手等已完成)。
结果:byte[] 被吐入两个数据包(参见下面的调试):
- 第一个数据包:只是应用程序数据的第一个字节 (**01**) 。
- 第二个数据包:其余 (fe db 01 00 ...) 650 字节
有没有办法在一个数据包中提交所有应用程序数据字节？
要发送 651 字节的流:
**01** fe db 01 00 00 02 83 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 73 2d 61 73 63 69 69 22 20 73 74 61 6e 64 61 6c 6f 6e 65 3d 22 6e 6f 22 3f 3e …
javax.net.debug 输出
Padded plaintext before ENCRYPTION: len = 32
0000: **01** 06 03 06 46 7F 7F AE D4 E8 30 5D B7 DB 3C 44 ....F.....0]..<D
0010: 02 08 C9 2A A1 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A ...*............
1, WRITE: TLSv1 Application Data, length = 32
[Raw write]: length = 37
0000: 17 03 01 00 20 B3 4E EE CE 5B 69 EC A5 4A 80 7F .... .N..[i..J..
0010: D6 03 35 AF 6A 7B 85 17 B7 46 A2 31 B2 EF 7E D0 ..5.j....F.1....
0020: EA 1B 67 7E ED ..g..
Padded plaintext before ENCRYPTION: len = 672
0000: FE DB 01 00 00 02 83 3C 3F 78 6D 6C 20 76 65 72 .......<?xml ver
0010: 73 69 6F 6E 3D 22 31 2E 30 22 20 65 6E 63 6F 64 sion="1.0" encod
0020: 69 6E 67 3D 22 75 73 2D 61 73 63 69 69 22 20 73 ing="us-ascii" s
0030: 74 61 6E 64 61 6C 6F 6E 65 3D 22 6E 6F 22 3F 3E tandalone="no"?>
[…]
最佳答案
Sun 的 impl 评论:
By default, we counter chosen plaintext issues on CBC mode ciphersuites in SSLv3/TLS1.0 by sending one byte of application data in the first record of every payload, and the rest in subsequent record(s). Note that the issues have been solved in TLS 1.1 or later.
对 SSLEngine.wrap( largePlainText ) 的实验表明它产生了 2 个 SSL 记录，第一个记录包含 1 个字节的纯文本，第二个记录包含 15846 个字节的纯文本。
接收器 API 可能会逐个记录地处理，因此它会在第一次读取时返回 1 个字节。
我们也可以在其他 SSL impls 中观察到这种行为，例如来自 Web 浏览器的 HTTPS 请求。
OpenSSL 插入空记录来对抗攻击。如果接收器是 Java SSL 套接字，则输入流不能为 read() 返回 0 字节，因此跳过该记录。其他接收器可能没有准备好接收长度为 0 的记录，可能会中断。
关于Java SSL Streaming - 拆分应用程序数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13528021/