update documentation

_docs/readme_ja.md

@@ -98,12 +98,11 @@ google-chrome --proxy-server="http://127.0.0.1:8080"
 世界中のほとんどのウェブサイトがHTTPSをサポートしているため、SpoofDPIはHTTPリクエストのDeep Packet Inspectionをバイパスしませんが、すべてのHTTPリクエストに対してプロキシ接続を提供します。
 
 ### HTTPS
-TLS 1.3はすべてのハンドシェイクプロセスを暗号化しますが、Client helloパケットには依然としてドメイン名がプレーンテキストで表示されます。 
+TLS はすべてのハンドシェイクプロセスを暗号化しますが、Client helloパケットには依然としてドメイン名がプレーンテキストで表示されます。 
 つまり、他の誰かがパケットを見た場合、パケットがどこに向かっているのかを簡単に推測することができます。 
 ドメイン名はDPIが処理されている間に重要な情報を提供することができ、実際にClient helloパケットを送信した直後に接続がブロックされることがわかります。
 これをバイパスするためにいくつかの方法を試してみましたが、Client helloパケットをチャンクに分割して送信すると、最初のチャンクだけが検査されるように見えることがわかりました。 
 SpoofDPIがこれをバイパスするために行うことは、リクエストの最初の1バイトをサーバーに送信し、その後に残りを送信することです。
- > SpoofDPIはHTTPSリクエストを復号化しないため、SSL証明書は必要ありません。
 
 # インスピレーション
 [Green Tunnel](https://github.com/SadeghHayeri/GreenTunnel) by @SadeghHayeri  

_docs/readme_ko.md

@@ -95,11 +95,10 @@ SpoofDPI는 HTTP 요청에 대한 DPI 우회는 지원하지 않습니다.
 다만 모든 HTTP 요청에 대한 Proxy 연결은 지원합니다.
 
 ### HTTPS
-TLS 1.3은 모든 Handshake 과정을 암호화 합니다. 하지만, Client hello 패킷의 일부에는 여전히 서버의 도메인 네임이 평문으로 노출되어있습니다. 
+TLS는 모든 Handshake 과정을 암호화 합니다. 하지만, Client hello 패킷의 일부에는 여전히 서버의 도메인 네임이 평문으로 노출되어있습니다. 
 다시 말하자면, 누군가가 암호화된 패킷을 본다면 해당 패킷의 목적지가 어딘지 손쉽게 알아차릴 수 있다는 뜻입니다. 
 노출된 도메인은 DPI 검열에 매우 유용하게 사용될 수도 있고, 실제로 HTTPS 요청을 보냈을 때 차단이 이루어지는 시점도 Client hello 패킷을 보낸 시점입니다. 
 여러가지 방법을 시도해본 결과, Client hello 패킷을 여러 조각으로 나누어 요청을 보냈을 때, 첫번째 조각에 대해서만 도메인 검열이 이루어지는 듯한 동작을 발견했습니다. 따라서 SpoofDPI는 해당 패킷을 두번에 나누어 보냅니다. 자세히 말하자면, 첫번째 1 바이트를 우선적으로 보내고, 나머지를 그 이후에 보내는 동작을 수행합니다.
-> SpoofDPI는 HTTPS 패킷을 복호화 하지 않기때문에 SSL 인증서를 필요로하지 않습니다.
 
 # 참고
 [Green Tunnel](https://github.com/SadeghHayeri/GreenTunnel) by @SadeghHayeri  

_docs/readme_ru.md

@@ -100,9 +100,8 @@ google-chrome --proxy-server="http://127.0.0.1:8080"
 Поскольку большинство веб-сайтов в мире теперь поддерживают HTTPS, SpoofDPI не обходит Deep Packet Inspection для HTTP запросов, однако он по-прежнему обеспечивает прокси-соединение для всех HTTP запросов.
 
 ### HTTPS
-Хотя TLS 1.3 шифрует каждый процесс рукопожатия, имена доменов по-прежнему отображаются в виде открытого текста в пакете Client Hello. Другими словами, когда кто-то другой смотрит на пакет, он может легко догадаться, куда направляется пакет. Домен может предоставлять значительную информацию во время обработки DPI, и мы можем видеть, что соединение блокируется сразу после отправки пакета Client Hello.
+Хотя TLS шифрует каждый процесс рукопожатия, имена доменов по-прежнему отображаются в виде открытого текста в пакете Client Hello. Другими словами, когда кто-то другой смотрит на пакет, он может легко догадаться, куда направляется пакет. Домен может предоставлять значительную информацию во время обработки DPI, и мы можем видеть, что соединение блокируется сразу после отправки пакета Client Hello.
 Я попробовал несколько способов обойти это, и обнаружил, что, похоже, проверяется только первый фрагмент, когда мы отправляем пакет Client Hello, разделенный на фрагменты. Чтобы обойти DPI, SpoofDPI отправляет на сервер первый 1 байт запроса, а затем отправляет все остальное.
- > SpoofDPI не расшифровывает Ваши HTTPS запросы, так что нам не нужны SSL сертификаты.
 
 # Вдохновение
 [Green Tunnel](https://github.com/SadeghHayeri/GreenTunnel) от @SadeghHayeri

_docs/readme_zh-cn.md

@@ -107,9 +107,7 @@ google-chrome --proxy-server="http://127.0.0.1:8080"
 因为世界上许多网站都已支持 HTTPS ，SpoofDPI 不会规避对 HTTP 请求的 DPI，但是它仍会为 HTTP 请求提供代理。
 
 ### HTTPS
-尽管 TLS 1.3加密了握手的每一步，但是在 Client Hello 中的域名仍然是明文的。因此如果有人看到 Client Hello 包就可以知道你在连接什么网站。这给 DPI 提供了很大方便，我们也看到连接在 Client Hello 之后就会被屏蔽掉。我之前尝试了规避这种审查，并发现，如果把 Client Hello 分包，只有第一个 chunk 会被检测。SpoofDPI 只要在第一个分包发送 1 byte，然后再发送其他部分就能规避。
+尽管 TLS 加密了握手的每一步，但是在 Client Hello 中的域名仍然是明文的。因此如果有人看到 Client Hello 包就可以知道你在连接什么网站。这给 DPI 提供了很大方便，我们也看到连接在 Client Hello 之后就会被屏蔽掉。我之前尝试了规避这种审查，并发现，如果把 Client Hello 分包，只有第一个 chunk 会被检测。SpoofDPI 只要在第一个分包发送 1 byte，然后再发送其他部分就能规避。
-
- > SpoofDPI 不会解密 HTTPS 请求，所以您无需安装任何 TLS 证书。
 
 # 启发
 

readme.md

@@ -98,16 +98,15 @@ google-chrome --proxy-server="http://127.0.0.1:8080"
 
 # How it works
 ### HTTP
-Since most of websites in the world now support HTTPS, SpoofDPI doesn't bypass Deep Packet Inspections for HTTP requets, However It still serves proxy connection for all HTTP requests.
+ Since most of websites in the world now support HTTPS, SpoofDPI doesn't bypass Deep Packet Inspections for HTTP requets, However It still serves proxy connection for all HTTP requests.
 
 ### HTTPS
- Although TLS 1.3 encrypts every handshake process, the domain names are still shown as plaintext in the Client hello packet.
+ Although TLS encrypts every handshake process, the domain names are still shown as plaintext in the Client hello packet.
  In other words, when someone else looks on the packet, they can easily guess where the packet is headed to.
  The domain name can offer a significant information while DPI is being processed, and we can actually see that the connection is blocked right after sending Client hello packet.
  I had tried some ways to bypass this, and found out that it seemed like only the first chunk gets inspected when we send the Client hello packet splited in chunks.
  What SpoofDPI does to bypass this is to send the first 1 byte of a request to the server,
  and then send the rest.
- > SpoofDPI doesn't decrypt your HTTPS requests, and that's why we don't need the SSL certificates.
 
 # Inspirations
 [Green Tunnel](https://github.com/SadeghHayeri/GreenTunnel) by @SadeghHayeri