5hadow5ocks 的 TCP 流处理是不是有缺陷啊

下午在看 5hadow5ocks AEAD 算法的重定向攻击，简单看了一下源码，版本号是 2.8.2

发现它支持的加密算法都是流密码，猜测它内部是不是没做 TCP 的上层分包，发现果然是。大体 sslocal 和 ssserver 的通信逻辑：

1. 客户端通过 sslocal 本地的 Socks5 客户端向 target 发请求，Socks5 握手结束后，sslocal 调用 Encryptor.encrypt(data)加密数据，在向 ssserver 建立 TCP 连接时会在数据头部附上固定长度的 IV。数据长度被扩展为 len(DATA) + len(IV)

2. ssserver 端的 eventloop 在on_read事件触发时调用_on_local_read，注意到这里只是简单的data = self._remote_sock.recv(BUF_SIZE)，接着就调用 ENcryptor.decrypt 解密。decrypt 的逻辑是：

   if self.decipher is None:
       decipher_iv_len = self._method_info[1]
       decipher_iv = buf[:decipher_iv_len]
       print('IV: ', decipher_iv.encode('hex'))
       self.decipher = self.get_cipher(self.key, self.method, 0,
                                       iv=decipher_iv)
       buf = buf[decipher_iv_len:]
       if len(buf) == 0:
           return buf
   return self.decipher.update(buf)
   

   看出该条 TCP 连接后续的解密都会用这第一个包发来的 IV。解密完成后直接往对端的 socket 写了

那么问题来了，在没有做分包的情况下，按现在代码的逻辑，self._remote_sock.recv()如果分两次 read 才拿到完整的 IV，就直接把第一次小于 16bytes 的数据设置成当前 TCPRelay 的 IV （虽然概率不大，但考虑极端情况）这里应该考虑一下边界处理吧

我担心是自己哪里思考错了，所以实验了一下，在上面代码中加了一行 print，结果确实存在问题，分两次发数据连接直接 closed 了

IV:  6f
2020-03-18 17:39:42 WARNING  unsupported addrtype 194, maybe wrong password or encryption method
2020-03-18 17:39:42 ERROR    can not parse header when handling connection from 127.0.0.1:59824