有 Java 编程相关的问题?

你可以在下面搜索框中键入要查询的问题!

java FTP Explicit在celluar数据上失败

这个问题是this original question的后续问题。在与FTP解决了一段时间后,我再次决定调查这个问题。这次,我用纯java(非安卓)编写了一个简单的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以及所有的结果都是相同的,其中socket超时,服务器关闭连接。FTP服务器(FileZilla服务器0.9.48 beta版)没有提供该问题的详细日志

对此问题的任何见解都将不胜感激


共 (1) 个答案

  1. # 1 楼答案

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

    这与您的问题有何关系: 在蜂窝网络中,通常需要NAT,也就是说,您没有公共IP地址。但是,至少FTP中的活动模式需要一个公共IP,因此,在FTP控制连接中使用帮助程序为端口/EPRT命令翻译IP和端口并不少见。这些帮助程序无法处理加密的连接,这意味着它们可能会故意阻止这些连接,也可能会意外地阻止它们,因为它们不再了解通信量