Coia Prant
Coia Prant
Preliminary judgment of the problem in the gin. ResponseWriter re-packaged the http.ResponseWriter. If we could make a middleware type for grpc alone, or add a new method to get the...
> If you don't know what you are doing, please close this issue. MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了
> > > If you don't know what you are doing, please close this issue. > > > > > > MTProto FakeTLS在TLS ClientHello中使用secret进行hmac，将hash值填充在tls.random字段中，服务器可以在clienthello中进行判断，验证客户端有效性，但是依旧被识别，这种方式已经过时了 > > 感谢反馈！ > > 没太仔细看...
MTProto不仅在Server Side做数据包校验，Client Side也有数据包校验，避免中间盒探测客户端，MTProto FakeTLS的协议设计具有抗探测和抗重放的性质，对整包进行保护，如果中间盒进行重放，探测等操作，他会回落到真服务器，从而中间盒无法判断是否为代理服务器。
整包保护的好处就是，只要修改了一处，就会被发现。这点使中间盒无法破译TLS内流量，重放无法得到TLS内明文数据，探测会被回落。TLS 1.3对Server Hello后面全部加密保护，所以中间盒没有办法判断证书有效性，唯一的方法就是探测。
MTProto FakeTLS已经完全实现了伪装源服务器，且中间盒探测得到的证书为可信证书，从而可以绕过证书检测。
我很好奇开发者有没有研究过TLS的RFC？只有ClientHello去探测并不能得到什么有效数据吧，都没法发TLS 1.3的Encrypted Client Hello Done
而且不说别的，MTG的FakeTLS实现，认证字段做了一次性处理的，只能用一次，然后会被记录，第二次相同的就会被回落
如果您有telegram的话，最好留一下，拿telegram交流更方便
> > > > > > If you don't know what you are doing, please close this issue. > > > > > > > > > > > >...