能力值：
( LV2，RANK：10 )
|
-
-
2 楼
照着GitHub的tls1.3实现就行了，几个细微差别而已。
|
能力值：
( LV4，RANK：55 )
|
-
-
3 楼
可以
|
能力值：
( LV4，RANK：55 )
|
-
-
4 楼
好文
|
能力值：
( LV8，RANK：130 )
|
-
-
5 楼
mark
|
能力值：
( LV2，RANK：10 )
|
-
-
6 楼
好文 期待后续 
|
能力值：
( LV1，RANK：0 )
|
-
-
7 楼
秘钥按照(16 12 16 12)进行分解，作为AES GCM的 key 跟IV
这个看分解 是 （16 16 12 12）
091DDD18 0D7C99F0
091DDD1C 00000010
091DDD20 0D7C9A00
091DDD24 00000010
091DDD28 0D7C9A10
091DDD2C 0000000C
091DDD30 0D7C9A1C
091DDD34 0000000C
|
能力值：
( LV2，RANK：10 )
|
-
-
8 楼
jingang728627，v，等联系
|
能力值：
( LV3，RANK：30 )
|
-
-
9 楼
请教下怎样：屏蔽掉长连接，而强制使用短连接？
找了资料，说是__RunConnect，尝试了修改socekt为-1，还是会再次调用长连接。
往上层找MakesureLonglinkConneted，没找到开始调用的地方。
|
能力值：
( LV6，RANK：80 )
|
-
-
10 楼
KongKong20
请教下怎样：屏蔽掉长连接，而强制使用短连接？
找了资料，说是__RunConnect，尝试了修改socekt为-1，还是会再次调用长连接。
往上层找MakesureLonglinkConneted ...
新版本是不让屏蔽了的
|
能力值：
( LV3，RANK：30 )
|
-
-
11 楼
大魔头
新版本是不让屏蔽了的
我这边用的是一样的老版本：2.6.2.31。  clientHello包长也不是 0x0d，反而大很多0x161，其他字段对得上，就中间的未知多了很多东西
|
能力值：
( LV2，RANK：10 )
|
-
-
12 楼
5
最后于 2020-7-7 21:40
被Altai001编辑
，原因： 重新组织下语言
|
能力值：
( LV2，RANK：10 )
|
-
-
13 楼
--
最后于 2020-6-15 11:05
被Altai001编辑
，原因： 不恰当言论
|
能力值：
( LV3，RANK：30 )
|
-
-
14 楼
Altai001
我知道为什么了，我的也是0x161，仔细再读一篇MMTLS的介绍就知道了 哈哈哈
携带了PSK数据？
|
能力值：
( LV2，RANK：10 )
|
-
-
15 楼
。
最后于 2020-7-6 13:07
被Altai001编辑
，原因： 不符合规范
|
能力值：
( LV2，RANK：10 )
|
-
-
16 楼
|
能力值：
( LV6，RANK：80 )
|
-
-
17 楼
KongKong20
我这边用的是一样的老版本：2.6.2.31。[em_78]
clientHello包长也不是 0x0d，反而大很多0x161，其他字段对得上，就中间的未知多了很多东西
那是第一次协商完成以后，本地缓存了加密的PSK，所以下次就直接发送psk就可以协商了
|
能力值：
( LV3，RANK：30 )
|
-
-
18 楼
|
能力值：
( LV3，RANK：30 )
|
-
-
19 楼
大魔头
那是第一次协商完成以后，本地缓存了加密的PSK，所以下次就直接发送psk就可以协商了
感谢感谢~
|
能力值：
( LV2，RANK：10 )
|
-
-
20 楼
.
最后于 2020-7-6 13:06
被Altai001编辑
，原因： 不符合规范
|
能力值：
( LV2，RANK：10 )
|
-
-
21 楼
我不是搞逆向的，不过个人觉得mmtls没必要研究，不是未来方向，而且它假设了应用层能够谨慎的使用它（就好像微信发文件时，在其明文数据结构中包含了该文件的本地文件名一样。应用层的粗心大意造成了很多安全问题）。
未来协议的典型需求是： 低延迟，高带宽利用率，高并发，物理网络切换不切换会话等等。防范的主要是 攻击，破解。需要平衡的是各种厂商的正常需求，比如流量监控等。
因此，dtls，gquic，iquic这些才值得研究。当然，作为现有tcp的代表tls也值得继续关注。不过基于现有tcp永远解决不了真正的并发问题，物理网络切换问题，天然缺陷太多。至于 是 rtt-0(1)的gquic能胜出，还是rtt-1（2）的dtls能胜出，这个就不太好说了。个人感觉反射攻击防范和rtt-0都是主流需求。不过，如果能够使用会话保持，无视物理网络切换，也许rtt-x就不再是问题了。个人猜测，未来不会是单一协议的填写，也不会太多。更多的可能是几种不同偏向的协议并存。（dtls，quic ？）
|
能力值：
( LV2，RANK：10 )
|
-
-
22 楼
重新编辑
最后于 2020-7-24 18:03
被Altai001编辑
，原因：
|
能力值：
( LV2，RANK：10 )
|
-
-
23 楼
.
最后于 2020-7-29 18:28
被Altai001编辑
，原因：
|
能力值：
( LV2，RANK：10 )
|
-
-
24 楼
这篇文章不错, 可以给后来者很多参考, 大体结构都有了, 除了握手消息hash那段没截图, 这个你自己hook后数据就有了, 另外说句那段乱七八糟数据是psk握手用的, 安卓也是这个流程, 重现下楼主流程, 还原 mmtls 不难 .
最后于 2020-9-21 10:01
被骇客技术编辑
，原因：
|
能力值：
( LV1，RANK：0 )
|
-
-
25 楼
mmtls最终使用的密钥是有HKDF-Expand扩展出来的。mmtls把info参数分为：length，label，handshake_hash。其中length等于out_key_length，label是标记密钥用途的固定字符串，handshake_hash表示握手消息的hash值，这样扩展出来的密钥保证连接内唯一。
最后于 2020-9-28 11:44
被安小白MCY编辑
，原因：
|
|
|
|
大魔头
