SSLSocket через другой SSLSocket

Ответ 1

Я не думаю, что вы делаете что-то неправильно. Похоже, есть ошибка в согласовании протокола во время вашего второго рукопожатия. Хороший кандидат будет терпеть неудачу в расширении квитирования TLS NPN.

Взгляните на свои протоколы в этом вызове: sslSocket.setEnabledProtocols(sslSocket.getSupportedProtocols());

Вы можете пройти через перечисленные протоколы и попробовать их индивидуально. Посмотрите, можете ли вы заблокировать то, что не удается, и нужен ли вам определенный протокол или расширение.

Ответ 2

Итак, я попытался выяснить, что пойдет не так в случае с Android, но до сих пор я не нашел ничего плохого в вашем коде. Кроме того, поскольку код работает для JRE, он утверждает гипотезу.

Из предоставленного вами tcpdump имеется существенная информация, чтобы заключить, как Android ведет себя с тем же набором API, что и JRE.

Посмотрим на JRE tcpdump:

• См. начальные сообщения подтверждения (Client Hello, Server Hello, change cipher spec). Это показывает рукопожатие между клиентом JRE и прокси-сервером. Это успешно.
• Теперь мы не видим второго рукопожатия между клиентом JRE и www.google.com(конечным сервером), как это зашифровано, поскольку мы делаем SSL через SSL. Прокси-сервер копирует их по битам на конечный сервер. Так что это правильное поведение.

Теперь посмотрим на android tcpdump:

• См. начальные сообщения подтверждения (Client Hello, Server Hello, change cipher spec). Это показывает рукопожатие между клиентом android и прокси-сервером. Это успешно.
• Теперь в идеале мы не должны видеть второе рукопожатие, поскольку оно должно быть зашифровано. Но здесь мы видим, что клиент Android отправляет "приветствие клиента" и отправляет его на "www.google.com", даже если пакет отправляется на прокси-сервер.
• Вышеуказанное значение связано с отказом, поскольку пакет должен был быть написан через SSL-сокет, а не через начальный простой сокет. Я просмотрел ваш код, и я вижу, что вы делаете второе рукопожатие над SSLSocket, а не над обычным сокетом.

Анализ прокси /stunnel wireshark:

Случай JRE:

В случае JRE клиент выполняет начальное SSL-соединение с сервером stunnel/proxy. То же самое можно увидеть ниже:

Рукопожатие выполнено успешно и соединение выполнено

Затем клиент пытается подключиться к удаленному серверу (www.google.com) и начинает рукопожатие. Таким образом, приветствие клиента, отправленное клиентом, рассматривается как зашифрованное сообщение в пакете № 34, и когда stunnel расшифровывает его, он отображается на "Client hello", который перенаправляется на прокси-сервер с помощью stunnel

Теперь посмотрим на дело клиента Android.

Исходное SSL-обращение от клиента к stunnel/proxy успешно, как видно выше.

Затем, когда клиент android начинает рукопожатие с удаленным (www.google.com), в идеале он должен использовать SSL-сокет для этого же. Если это так, мы должны увидеть зашифрованный трафик от android до stunnel (аналогично пакету № 34 из случая JRE), stunnel должен расшифровать и отправить "client hello" в прокси. однако, как вы можете видеть ниже, клиент Android отправляет "приветствие клиента" через обычный сокет.

Если вы сравните пакет # 24 с пакетом № 34 от JRE, мы можем определить эту разницу.

Вывод:

Это ошибка с реализацией SSL-протокола android SSL (factory.createsocket() с SSL-сокетом), и я чувствую, что не может быть волшебного обходного пути для того же, используя тот же набор API. На самом деле я нашел эту проблему в списке ошибок Android. См. Ниже ссылку: https://code.google.com/p/android/issues/detail?id=204159

Эта проблема по-прежнему не решена, и вы, возможно, можете продолжить работу с командой разработчиков Android, чтобы исправить ее.

Возможные решения:

Если мы пришли к выводу, что один и тот же набор API-интерфейсов не может работать, вы остаетесь только с одним вариантом:

• Создайте собственную SSL-оболочку через SSL-сокет. Вы можете вручную сделать рукопожатие или использование сторонней реализации. Это может привести к но выглядит как единственный способ.

Ответ 3

Так как HTTPS гарантирует, что средний человек не прерывает связь между ними. вот почему вы не можете этого сделать. так что второе рукопожатие терпит неудачу.

Вот ссылка может помочь.

HTTPS-соединения через прокси-серверы

Ответ 4

Я не знаю, поможет ли это: Я построил тестовую среду репо, и моя ошибка несколько отличается:

I/SurfaceTextureClient(20733): [0x52851b98] frames:2, duration:1.005000, fps:1.989805
I/System.out(20733): [socket][2] connection /192.168.1.100:10443;LocalPort=35380(0)
I/System.out(20733): [CDS]connect[/192.168.1.100:10443] tm:90
I/System.out(20733): [socket][/192.168.1.123:35380] connected
I/System.out(20733): Doing SSL handshake with 192.168.1.100:10443
I/System.out(20733): Supported protocols are: [SSLv3, TLSv1, TLSv1.1, TLSv1.2]
E/NativeCrypto(20733): ssl=0x53c96268 cert_verify_callback x509_store_ctx=0x542e0a80 arg=0x0
E/NativeCrypto(20733): ssl=0x53c96268 cert_verify_callback calling verifyCertificateChain authMethod=RSA
I/System.out(20733): Doing SSL handshake with 192.168.1.100:443
I/System.out(20733): Supported protocols are: [SSLv3, TLSv1, TLSv1.1, TLSv1.2]
E/NativeCrypto(20733): Unknown error during handshake
I/System.out(20733): Shutdown rx/tx
I/System.out(20733): [CDS]close[35380]
I/System.out(20733): close [socket][/0.0.0.0:35380]
W/System.err(20733): javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException:
                        SSL handshake aborted: ssl=0x53c9c1d8:
                        Failure in SSL library, usually a protocol error
W/System.err(20733): error:140770FC:SSL routines:
                        SSL23_GET_SERVER_HELLO:
                        unknown protocol (external/openssl/ssl/s23_clnt.c:766 0x4e7cb3ad:0x00000000)
W/System.err(20733):    at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:413)
W/System.err(20733):    at com.bugreport.sslviassl.SecureWebProxyThread.doSSLHandshake(SecureWebProxyThread.java:147)
W/System.err(20733):    at com.bugreport.sslviassl.SecureWebProxyThread.run(SecureWebProxyThread.java:216)
W/System.err(20733): Caused by: javax.net.ssl.SSLProtocolException:
                        SSL handshake aborted: ssl=0x53c9c1d8:
                        Failure in SSL library, usually a protocol error
W/System.err(20733): error:140770FC:SSL routines:
    SSL23_GET_SERVER_HELLO:unknown protocol (external/openssl/ssl/s23_clnt.c:766 0x4e7cb3ad:0x00000000)
W/System.err(20733):    at org.apache.harmony.xnet.provider.jsse.NativeCrypto.SSL_do_handshake(Native Method)
W/System.err(20733):    at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:372)
W/System.err(20733):    ... 2 more
I/SurfaceTextureClient(20733): [0x52851b98] frames:5, duration:1.010000, fps:4.946089

Одна мысль о потоках: какой поток вы используете для своего метода doSSLHandshake()?

public void policy()
{
    int SDK_INT = android.os.Build.VERSION.SDK_INT;
    if (SDK_INT > 8)
    {
        StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder().permitAll().build();
        StrictMode.setThreadPolicy(policy);
    }
}