net4people
Can a middlebox clobber the TLS 1.3 legacy_session_id to distinguish REALITY?
Hello. Today morning I thought, that I found some serious Reality volnurability. I hope to listen from you that I mistaken. Look. Reality works as TLS 1.3 server and use SessionID for authenticate valid client connections. All requests from other clients transparently redirected to remote server by TCP. In TLS 1.3 SessionID must be random ir zero. Any TLS 1.3 server don't validate it. Ok. If third party (censor) change Reality client SessionID (with encrypted authentication data) in ClientHello with any 32 bit data for all TLS 1.3 Hellos to foreign IPs or IPs from grey lists, I think all legal (non-Reality) TLS 1.3 connections not be violated. We even can connect with our Reality VPS, but Reality server due to Session ID changed by third party will think about us as not valid Reality client and send our connection to remote server. So censor no need to find Reality servers specially. He may mechanically change Session ID of TLS 1.3 ClientHello to any randon 32-bit value for some connections to some IPs and not violate any TLS 1.3 non-Reality connections. So HTTPs will work fine, but Reality don't. Or I mistaken?
Originally posted by @seeker252 in #455
He may mechanically change Session ID of TLS 1.3 ClientHello to any randon 32-bit value for some connections to some IPs and not violate any TLS 1.3 non-Reality connections. So HTTPs will work fine, but Reality don't.
@seeker252, good question. No, this won't work. By changing the legacy_session_id, the censor will break standard TLS connections as well. The reason is that the Finished message includes a Transcript-Hash of the messages exchanged so far. Even if the legacy_session_id is not used, it still participates in the Transcript-Hash. The server will be able to tell that what it received is not the same as what the client sent, and will terminate the connection:
Recipients of Finished messages MUST verify that the contents are correct and if incorrect MUST terminate the connection with a "decrypt_error" alert.
It's still possible that such an active attack might distinguish REALITY from other TLS—if the server reacts differently to the error condition, for example. But it would not be a stealthy attack, because it would break normal TLS.
It's still possible that such an active attack might distinguish REALITY from other TLS—if the server reacts differently to the error condition, for example. But it would not be a stealthy attack, because it would break normal TLS.
如果 session id 未通过 REALITY 服务端的验证，则只会继续到 target 的双向对拷，任何 errors 均由 target 响应，所以不会有区别
If the session id fails to pass the verification of the REALITY server, it will only continue the two-way copy to the target. Any errors will be responded by the target, so there will be no difference.
