建议增加Aead的加密方法

[fivetime]

建议增加Aead的加密方法，Https+现有的加密并不靠谱

[ssrlive]

倒沒聽說過GFW能破解TLS加密套件。

希望你能加上 AEAD

[ssrlive]

sample code

#include "mbedtls/gcm.h"

void test_aead(void)
{
    size_t i;
    mbedtls_gcm_context aes;
    char* key = "abcdefghijklmnopabcdefghijklmnop";
    char* input = "Mark C's ESP32 GCM Example code!";
    char* iv = "abababababababab";
    unsigned char output[64] = { 0 };
    unsigned char fin[64] = { 0 };
    printf("[i] Encrypted into buffer:\n");
    // init the context...
    mbedtls_gcm_init(&aes);
    // Set the key. This next line could have CAMELLIA or ARIA as our GCM mode cipher...
    mbedtls_gcm_setkey(&aes, MBEDTLS_CIPHER_ID_AES, (const unsigned char*)key, (unsigned int)strlen(key) * 8);
    // Initialise the GCM cipher...
    mbedtls_gcm_starts(&aes, MBEDTLS_GCM_ENCRYPT, (const unsigned char*)iv, strlen(iv), NULL, 0);
    // Send the intialised cipher some data and store it...
    mbedtls_gcm_update(&aes, strlen(input), (const unsigned char*)input, output);
    // Free up the context.
    mbedtls_gcm_free(&aes);
    for (i = 0; i < strlen(input); i++) {
        char str[3];
        sprintf(str, "%02x", (int)output[i]);
        printf(str);
    }
    printf("\n");
    printf("[i] Decrypted from buffer:\n");
    mbedtls_gcm_init(&aes);
    mbedtls_gcm_setkey(&aes, MBEDTLS_CIPHER_ID_AES, (const unsigned char*)key, (unsigned int)strlen(key) * 8);
    mbedtls_gcm_starts(&aes, MBEDTLS_GCM_DECRYPT, (const unsigned char*)iv, strlen(iv), NULL, 0);
    mbedtls_gcm_update(&aes, 64, (const unsigned char*)output, fin);
    mbedtls_gcm_free(&aes);
    for (i = 0; i < strlen(input); i++) {
        char str[3];
        sprintf(str, "%c", (int)fin[i]);
        printf(str);
    }
}

The encryption key size generated in the above code is 256 bits (32 bytes) and it configures the AES-GCM cipher as AES-256-GCM. If we change the key size to 128 bits or 192 bits, we shall use AES-128-GCM or AES-192-GCM respectively.

[fivetime]

GFW并不需要破解TLS加密，它只需要发送shadowsocks+https的内容到服务器，根据你服务器响应的数据判断出你的行为即可。shadowsocks识别已经是成熟的技术，目前只有shadowsocks+aead识别不出来，这就是shadowsocks还能生存的原因。

[ssrlive]

错误的 http 请求只能返回 404 页面，GFW的主动探测绝不会成功，因为每次 https 请求的临时密码是随机的，gfw的重放攻击也会失败。所以 SSRoT 的方式是目前为止最安全的翻墙方式，反而ss加解密是不是采用 AEAD 的重要性不是那么大。SSRoT的早期版本并不使用加密算法，走的就是明文，gfw都无可奈何。这个提交 之前就是明文走 https。 我的意思你明白了吗？这并不是为自己懒得加AEAD找借口，而是确实不那么重要，当然你有决心、有能力，加上也很好。

[ssrlive]

GFW破解 SSRoT 的方法只能通过附属假网站本身的内容 和 通讯数据包长度的熵值来判断用户是不是在翻墙，而这与是否采用AEAD的关系并不大。根据 gfw 的员工混吃等死的混混作风，他们并不具备上述两方面的技能。只要你的假网站足够精彩，那帮孙子就无法判断你是否翻墙。当然他们的大招就是物理切断国际互联网。我在Wiki里已经说了。我并没有吹牛逼也没有虚声恫吓。

而目前SS翻墙并不足以规避GFW的封锁，GFW只要以不变应万变，只要走443端口不是HTTPS流量，只要走其它端口流量是不可识别流量，一概封锁。你SS+AEAD同样是奇怪流量，这对GFW来说还需要判断吗？不需要，封了就得。

[Alvin9999]

@ssrlive 请教一个问题。美国大选期间，即11月初，各个工具都失效了几天，包括v2ray、ss、ssr等工具，请问ssrot那段时间表现如何？

[ssrlive]

SSRoT 只有一个目的，绕过 GFW，不再关注花里胡哨的其它功能。SSRoT 从来没有拉稀摆带。

[ssrlive]

你天天发免费节点，也不替 SSRoT 推一下。

[Alvin9999]

你天天发免费节点，也不替 SSRoT 推一下。

下个版本就重新增加SSROT了。主要是之前有段时间不是那么好用，可能跟没有套假网站有关，现在准备套假网站试试看。

[ssrlive]

现在可以走 cloudflare 中继一下，就不怕 GFW 封了。

[Alvin9999]

现在可以走 cloudflare 中继一下，就不怕 GFW 封了。

感觉套CF也不是万能的，11月初v2ray套CF也没用。关于SSROT套假网站有没有什么讲究呢？比如这个网站如何https://www.kernel.org/

[ssrlive]

这就没有定规了，得研究 GFW人员怎么看假网站了。

[Alvin9999]

这就没有定规了，得研究 GFW人员怎么看假网站了。

好的，谢谢指教。

[ssrlive]

自有 Windows 客户端已经开发完毕，小巧快速，功能丰富，自包含，完全不用安装任何依赖。你可以试用看看。 https://github.com/ShadowsocksR-Live/ssrWin/releases/latest

[Alvin9999]

@ssrlive 请问开启CDN后，客户端配置文件需要做什么修改吗？

[Alvin9999]

@ssrlive ssrot厉害，2个月没问题，直到今天被墙。

[ssrlive]

不需要做什么修改。 我更感兴趣的是，线路为什么被墙。

[ssrlive]

已經增加 AEAD 加密，也就是說，已經全兼容了 SS，現在 SSR-N 是 SS 的超集。 @fivetime