在没使用 tls 的时候,假设规定一个数据包由(包头( 4 字节)+包体)组成,这样就很好获取一个完整的包,那我的疑问就是使用 tls 后,数据经过加密了,因此数据包大小也会发生改变,之前的那套规则就行不通了,那在接收数据的时候,怎么才能知道接收到的是一个完整的加密数据包?
1 neoblackcap 2022-02-26 15:17:16 +08:00 流加密,加密前后信息长度是一样的。 |
2 GGPlayer 2022-02-26 15:18:58 +08:00 只需要加密包体即可 |
3 0o0O0o0O0o 2022-02-26 15:22:48 +08:00 ![]() |
![]() | 4 sunny1688 OP @neoblackcap 这个还没注意,我试下 |
![]() | 5 Biwood 2022-02-26 15:25:18 +08:00 数据完整性校验恐怕不是 TLS 来干的事情,而是 TCP 协议做的事情,一个应用层,一个传输层,TLS 协议建立在 TCP 协议之上,TCP 连接成功了,TLS 数据就没问题。有问题的话那也是证书验证不通过,密钥被篡改之类的问题,而不是丢包问题。 |
![]() | 6 rrfeng 2022-02-26 15:42:40 +08:00 via Android 首先 TCP 是流没有包 其次 TLS 是对数据流加密,头部不变。 |
![]() | 7 sunny1688 OP @neoblackcap 加密前 18 字节,加密后 40 字节,不理解您说的长度不变是什么意思 |
![]() | 8 feather12315 2022-02-26 15:54:18 +08:00 via Android 多一比特跟少一比特解密后的数据不一样,这个是雪崩效应。 换个角度想:block 类型的加密不需要关注包大小,解密后的数据包大小是固定的,协议自己验证相关的数据对不对。 |
9 jinliming2 2022-02-26 16:12:16 +08:00 ![]() 你原始的 TCP 直接传裸数据时,自己可以定义包头+包体的结构。 但是中间加了一层 TLS 之后,你自己定义的结构对于 TLS 来说都没有意义了,都看作一堆无意义的二进制流。 然后 TLS 会自己对这一堆二进制数据流进行包装,包装成一个一个的 Application Data 帧,每个 Application Data 帧里可能包含了一个你的自定义包头+包体结构,也可能包含了两个,也可能包含了半个,具体包含多少是 TLS 层面决定的(单个帧最大 16K ,通常根据实际情况动态调整。单帧大了,可能会受 MTU 、MSS 限制而在 TCP 层面再拆分;单帧小了,则会浪费帧头的传输)。 Application Data 帧的结构与你的包头+包体结构类似:1 字节的帧类型( 0x17 Application Data ),2 字节的 TLS 协议版本号,2 字节的数据长度,然后后面跟加密初始化向量和加密后的帧数据。(注:这里的数据长度是指后面初始化向量和**加密后**的数据的总长度,与加密前的数据多长无关) |
![]() | 10 Rieouu 2022-02-26 16:12:54 +08:00 包是应用层协议考虑的 |
![]() | 11 sunny1688 OP @jinliming2 非常感谢,让我一下就明白了 |
![]() | 12 keepMyselfClam 2022-02-26 22:17:20 +08:00 之前是直接将数据放在 tcp 上传输的. 那么加上了 TLS 层之后不应该去关心或者直接处理 tls 加密后的数据. 而应该使用 tls 解密以后的数据. 这样 TLS 层对上面是透明的,数据内容也不会变,就不会影响之前的逻辑. |
![]() | 13 sunny1688 OP @keepMyselfClam 是的,我有点搞混了 |
![]() | 14 ysc3839 2022-02-27 11:40:40 +08:00 via Android @Biwood TLS 是要保证数据完整性的,TCP 反而不需要保证。虽然 TCP 头有校验码,但是大多数网络设备都会忽略不管的。早年间 http 下载文件可能会损坏就是一个例子。 |