为什么 volley 不告诉它就加密我的 post-request

Question

我正在尝试登录到使用 https 的远程地址。 为此，我使用 volley 发送带有我的用户数据的 post-request。

这是我的相关代码（includes setting up a StringRequest -> fire StringRequest）：

StringRequest myStringRequest = new StringRequest(Request.Method.POST, remoteurl, this, this) {
            @Override
            public Map<String, String> getHeaders() throws AuthFailureError {
                Map<String, String> headers = new HashMap<>();
                headers.put("Accept-Charset","utf-8");
                headers.put("Connection","keep-alive");
                headers.put("User-Agent","Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0");
                headers.put("Content-Type","application/x-www-form-urlencoded");
                return headers;
            }

            @Override
            protected Map<String, String> getParams() throws AuthFailureError {
                Map<String, String> params = new HashMap<>();
                params.put("name","myname");
                params.put("pw","mypw");
                params.put("totp","");
                params.put("app","76");
                return params;
            }
        };
SingleTonVolley.getInstance().getRequestQueue(getActivity().getApplicationContext()).add(myStringRequest);

用于实例化 newRequestQueue 的 SingleTon 如下所示：

public class SingleTonVolley {
private static SingleTonVolley mInstance = new SingleTonVolley();
private RequestQueue mRequestQueue;

private SingleTonVolley() {
}

public static SingleTonVolley getInstance() {
    return mInstance;
}

public synchronized RequestQueue getRequestQueue(Context context) {
    if(mRequestQueue == null)
    {
        mRequestQueue = Volley.newRequestQueue(context);
    }
    return mRequestQueue;
}

}

但是，在运行我的代码时，我可以通过 WireShark 看到我的数据是使用 TLSv1.2 加密发送的：

No.     Time           Source                Destination           Protocol Length Info
 11 2.898033000    192.168.0.19          80.190.158.9          TCP      74     57186 > https [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=11207479 TSecr=0 WS=128
 12 2.929011000    80.190.158.9          192.168.0.19          TCP      74     https > 57186 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=210621220 TSecr=11207479 WS=128
 13 2.929044000    192.168.0.19          80.190.158.9          TCP      66     57186 > https [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=11207487 TSecr=210621220
 14 2.930506000    192.168.0.19          80.190.158.9          TLSv1.2  284    Client Hello
 15 2.959979000    80.190.158.9          192.168.0.19          TCP      66     https > 57186 [ACK] Seq=1 Ack=219 Win=15616 Len=0 TSval=210621228 TSecr=11207487
 16 2.964700000    80.190.158.9          192.168.0.19          TLSv1.2  1514   Server Hello
 17 2.964742000    192.168.0.19          80.190.158.9          TCP      66     57186 > https [ACK] Seq=219 Ack=1449 Win=32128 Len=0 TSval=11207496 TSecr=210621229
 18 2.967946000    80.190.158.9          192.168.0.19          TLSv1.2  1725   Certificate
 19 2.967997000    192.168.0.19          80.190.158.9          TCP      66     57186 > https [ACK] Seq=219 Ack=3108 Win=35456 Len=0 TSval=11207496 TSecr=210621229
 20 2.993710000    192.168.0.19          80.190.158.9          TLSv1.2  192    Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
 21 3.027476000    80.190.158.9          192.168.0.19          TLSv1.2  324    New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
 22 3.030701000    192.168.0.19          80.190.158.9          TLSv1.2  471    Application Data
 23 3.107383000    80.190.158.9          192.168.0.19          TCP      66     https > 57186 [ACK] Seq=3366 Ack=750 Win=16640 Len=0 TSval=210621265 TSecr=11207512
 35 3.194115000    80.190.158.9          192.168.0.19          TCP      1514   [TCP segment of a reassembled PDU]
 36 3.195622000    80.190.158.9          192.168.0.19          TLSv1.2  6488   Application Data
 37 3.195653000    192.168.0.19          80.190.158.9          TCP      66     57186 > https [ACK] Seq=750 Ack=11236 Win=54144 Len=0 TSval=11207553 TSecr=210621286
535 63.283062000   80.190.158.9          192.168.0.19          TLSv1.2  97     Encrypted Alert
536 63.283534000   80.190.158.9          192.168.0.19          TCP      66     https > 57186 [FIN, ACK] Seq=11267 Ack=750 Win=16640 Len=0 TSval=210636286 TSecr=11207553
537 63.320615000   192.168.0.19          80.190.158.9          TCP      66     57186 > https [ACK] Seq=750 Ack=11268 Win=54144 Len=0 TSval=11222585 TSecr=210636286

关于SO的许多其他问题我可以看到每个人在创建newRequestQueue时都必须通过SSLSocketFactory。然而，虽然这对我来说听起来绝对合乎逻辑，但我想知道为什么我的程序默认会这样做，因为我没有添加任何 SSLSocketFactory。我想知道我是否拥有比过去在 SO 上提问时使用的其他用户更新版本的 volley。但是，在查看source-code of volley 时，我在使用https-url 时找不到任何检测，该SSLSocketFactory 会自动将SSLSocketFactory 分配给RequestQueue。 希望有人可以为我的问题带来一些启示。

加法

我能找到的只有SSLSocketFactory相关的东西在HurlStack.class中：

构造函数：

public HurlStack(UrlRewriter urlRewriter, SSLSocketFactory sslSocketFactory) {
    mUrlRewriter = urlRewriter;
    mSslSocketFactory = sslSocketFactory;
}

判断 SSLSocketFactory 是否通过：

    // use caller-provided custom SslSocketFactory, if any, for HTTPS
    if ("https".equals(url.getProtocol()) && mSslSocketFactory != null) {
        ((HttpsURLConnection)connection).setSSLSocketFactory(mSslSocketFactory);
    }

所以"https".equals(url.getProtocol()) 在我的情况下将评估为真，但mSslSocketFactory != null 不会！

Answer 1

它与套接字工厂没有任何关系。你指定了HTTPS，你得到了HTTPS。