java - 蜂窝数据上的 FTP 显式失败

Question

此问题是 this original question 的后续问题.在使用 FTP implicit 解决了一段时间后，我再次决定调查这个问题。这一次，我用纯 java(非 android)编写了一个简单的 FTP 客户端，并在我通过手机热点连接到互联网时分析了 SSL/TLS 调试消息。

问题发生在 ClientHello 发送后的 TLS 握手期间。在 FTP 方面，这对应于服务器成功接受 AUTH TLS 之后。失败的交换表示如下:

*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1416712655 bytes = { <binary data> }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
Extension server_name, server_name: [type=host_name (0), value=<server>]
Extension renegotiation_info, renegotiated_connection: <empty>
***
main, WRITE: TLSv1.2 Handshake, length = 188
main, handling exception: java.net.SocketTimeoutException: Read timed out
Exception in thread "main" java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:150)
    at java.net.SocketInputStream.read(SocketInputStream.java:121)
    at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
main, called close()

作为引用，成功的交换如下:

*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1416713014 bytes = { <binary data> }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
Extension server_name, server_name: [type=host_name (0), value=<server>]
Extension renegotiation_info, renegotiated_connection: <empty>
***
main, WRITE: TLSv1.2 Handshake, length = 188
main, READ: TLSv1.2 Handshake, length = 81
*** ServerHello, TLSv1.2
RandomCookie:  GMT: 142326665 bytes = { <binary data> }
Session ID:  { <session id data> }
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***

我试过使用 TLSv1.2、TLSv1.1 和 TLSv1，结果都一样，套接字超时，服务器关闭连接。 FTP 服务器(FileZilla Server 0.9.48 测试版)没有提供该问题的详细日志。

如有任何关于此问题的见解，我们将不胜感激。

Answer 1

我建议您的提供商的流量“优化”会导致问题。用于“优化”流量的深度数据包检测在蜂窝网络中非常常见，通常用于改善流量，有时也用于阻止不需要的流量。

这与您的问题有什么关系:在蜂窝网络中，通常需要 NAT，也就是说您无法获得公共(public) IP 地址。但是，至少 FTP 中的 Activity 模式需要一个公共(public) IP，因此在 FTP 控制连接内使用帮助程序为 PORT/EPRT 命令转换 IP 和端口的情况并不少见。这些帮助程序无法使用加密连接，这意味着它们要么有意阻止此类连接，要么可能因为不再了解流量而意外阻止它们。