V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
swiftg
V2EX  ›  宽带症候群

分享如何使用 curl 和 openssl 命令简单测试 SNI 阻断

  •  8
     
  •   swiftg · 2022-05-13 10:03:47 +08:00 · 7333 次点击
    这是一个创建于 960 天前的主题,其中的信息可能已经有所发展或是发生改变。

    惊闻泉州已部署域名白名单,看到有人买域名买服务器来测试,其实用不着,还有人拿墙内的 IP 来测试,方法就错了

    分享下使用 curl 和 openssl 进行简单测试的命令

    随便找一个没有被墙境外 IP ,需要开着 https 服务,比如任意 cloudflare 的 IP ,此处使用 104.18.2.8 。任意编造一个白名单外的域名,比如 abc123.com

    使用 openssl 测试:

    openssl s_client -connect 104.18.2.8:443 -servername abc123.com
    

    如果没有 SNI 阻断的话,返回结果如下:

    CONNECTED(00000003)
    140693079176320:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40
    ---
    no peer certificate available
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 7 bytes and written 302 bytes
    Verification: OK
    

    如果被 SNI 阻断的话,返回结果如下(本人所处地方没有白名单,所以使用黑名单里的域名测试,twitter.com ):

    CONNECTED(00000003)
    write:errno=104
    ---
    no peer certificate available
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 0 bytes and written 303 bytes
    Verification: OK
    

    对比分析可以看到区别,被 SNI 阻断的域名不会收到任何服务器的回应,SSL handshake has read 0 bytes

    使用 curl 测试

    curl --resolve abc123.com:443:104.18.2.8 https://abc123.com -iv
    

    如果没有 SNI 阻断的话,返回信息如下:

    curl --resolve abc123.com:443:104.18.2.8 https://abc123.com -iv
    * Expire in 0 ms for 6 (transfer 0x55d868a5dfb0)
    * Added abc123.com:443:104.18.2.8 to DNS cache
    * Hostname abc123.com was found in DNS cache
    *   Trying 104.18.2.8...
    * TCP_NODELAY set
    * Expire in 200 ms for 4 (transfer 0x55d868a5dfb0)
    * Connected to abc123.com (104.18.2.8) port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: none
      CApath: /etc/ssl/certs
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.3 (IN), TLS alert, handshake failure (552):
    * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
    * Closing connection 0
    curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
    

    如果被 SNI 阻断的话,返回信息如下:

    curl --resolve twitter.com:443:104.18.2.88 https://twitter.com -iv
    * Expire in 0 ms for 6 (transfer 0x55dea6262fb0)
    * Added twitter.com:443:104.18.2.88 to DNS cache
    * Hostname twitter.com was found in DNS cache
    *   Trying 104.18.2.88...
    * TCP_NODELAY set
    * Expire in 200 ms for 4 (transfer 0x55dea6262fb0)
    * Connected to twitter.com (104.18.2.88) port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: none
      CApath: /etc/ssl/certs
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to twitter.com:443
    * Closing connection 0
    curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to twitter.com:443
    

    对比分析可以看到区别,被 SNI 阻断的域名,同样收不到任何服务器的回应,正常的域名会有"TLSv1.3 (IN), TLS alert, handshake failure (552)"

    测试时需要注意的是,被 SNI 阻断后,测试的 IP 也会被 IP 阻断一段时间,可以换一个 IP 继续测试

    15 条回复    2023-03-29 17:05:32 +08:00
    Liqianyu
        1
    Liqianyu  
       2022-05-13 11:50:18 +08:00
    除了白名单,还可以检测到特定 SNI (或非白名单内域名)后劣化丢包。
    swiftg
        2
    swiftg  
    OP
       2022-05-13 12:43:51 +08:00
    @Liqianyu 有具体的域名吗?我来测试下丢包率
    Liqianyu
        3
    Liqianyu  
       2022-05-13 13:20:17 +08:00
    @swiftg
    https://github.com/
    https://store.steampowered.com/

    之前测试都是检测到 SNI 包就会随即对该 IP 对应端口丢包劣化。
    swiftg
        4
    swiftg  
    OP
       2022-05-13 14:42:54 +08:00
    @Liqianyu 又仔细测试了下,我原文最后写到的 SNI 阻断后会对被测试的 IP 进行 IP 阻断的说法不正确。

    对于某些 IP ,如上面测试用的 cloudflare 的 IP ,SNI 阻断后会导致整个 IP 阻断,所有协议所有端口全都阻断。我测试到甚至整个 A 段的 IP TCP 端口全都阻断。访问 104.18.2.28 的 443 端口会导致 104.24.2.2 的所有端口被封,可谓株连九族

    但对于另外一些 IP ,比如我测试的 akamai 的 IP ,如你所说,只会对该端口的 TCP 包进行丢包劣化,丢包率接近 100%,偶有几个包漏网,换 80 端口连接正常,tcmp 协议正常。差不多两分钟后 443 端口恢复正常。有趣的是,使用 v2ex.com 这种明显在黑名单里的域名作为 SNI 测试不会导致丢包劣化,看来黑名单里还有更黑的名单。但对于 cloudflare 的 IP ,使用 v2ex.com 和 twiiter 作为 SNI 域名,阻断的效果没有区别

    测试丢包使用的命令 nping 23.56.30.124 --tcp-connect -p 443
    sobev
        5
    sobev  
       2022-05-13 15:17:42 +08:00
    ENSI 可以测试吗😶
    Sephirothictree
        6
    Sephirothictree  
       2022-05-13 15:48:12 +08:00
    不懂就问,理论上可以用这个方式人为制造攻击某个 ip ,降低国内用户体验?
    Liqianyu
        7
    Liqianyu  
       2022-05-13 16:24:38 +08:00
    @sobev
    不用测啊,因为 ESNI 加密。GFW 早就封掉了 ESNI ,未来 ECH 普及也会是这个待遇。所以要解决必须建立境外域名白名单备案制度。因为流量加密导致无法被动审查。只能一刀切。

    @Sephirothictree
    不能,因为只对触发用户( IPv4 /32 IPv6/128 )生效。当然 CGNAT 或许可能会有影响。但是这就是另一种撞墙而已。只不过这堵墙不是砖墙而是软墙。更加无感和具有欺骗性,仿佛问题责任在对方。经典味道了。
    Liqianyu
        8
    Liqianyu  
       2022-05-13 16:26:26 +08:00
    @swiftg
    应该还有在白名单内的 IP ,记得之前用联合国官网 IP 测试是不会被丢包劣化的。
    qingmuhy0
        9
    qingmuhy0  
       2022-05-15 00:32:23 +08:00 via iPhone
    不错的教程,受用了。
    Ag2S
        10
    Ag2S  
       2022-05-15 22:27:01 +08:00
    貌似用 http3/quic 能避开 sni 检测
    zanzhz1101
        11
    zanzhz1101  
       2022-05-16 17:25:19 +08:00
    @swiftg 名单存在,并且分级,之前统计过 blacklist ,通过反查会发现存在明显的层级,可以参考我之前发的帖子,不过后续工作没发上来(不敢)
    carsonmoon
        12
    carsonmoon  
       2023-03-29 02:15:52 +08:00
    为什么用的是境外而不是境内 ip ?来测试 不懂就问
    swiftg
        13
    swiftg  
    OP
       2023-03-29 07:39:36 +08:00 via iPhone
    @carsonmoon 防火墙在大门口,你在大门里面测试有什么用
    carsonmoon
        14
    carsonmoon  
       2023-03-29 14:06:03 +08:00
    @swiftg 我就是在泉州的,如果不是在大门里面测试难道不是没有意义吗?( PS:这只是我的小白提问,没有不好意思,单纯想要知道原理),境外的本来也就不阻断,不知道我的意思表达清楚没,大佬。比如泉州这个白名单 不是类似省墙或者市墙
    swiftg
        15
    swiftg  
    OP
       2023-03-29 17:05:32 +08:00
    @carsonmoon 墙只针对境外的 IP ,国内的 IP 你再怎么测试也是没问题的啊。门卫让不让你过,你要走出大门才知道,大门里面玩门卫又不管你
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2688 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 14:57 · PVG 22:57 · LAX 06:57 · JFK 09:57
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.