SSL-соединение с использованием автономного приложения Java - PullRequest
Новая
       21

SSL-соединение с использованием автономного приложения Java

1 голос
/ 20 мая 2010

Я создал автономную исполняемую JAR-программу, которая должна отправлять личную информацию через SSL-соединение.
Мне не удалось установить SSL-соединение с использованием сертификатов. Получал это: 

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path `building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target`

Итак, я нашел где-то код, который создает менеджер доверия, который не проверяет цепочки сертификатов: 

// Create a trust manager that does not validate certificate chains
TrustManager[] trustAllCerts = new TrustManager[]{
            new X509TrustManager() {
                public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                    return null;
                }
                public void checkClientTrusted(
                    java.security.cert.X509Certificate[] certs, String authType) {
                }
                public void checkServerTrusted(
                    java.security.cert.X509Certificate[] certs, String authType) {
                }
            }
        };

Это помогло, и я смог установить соединение SSL без каких-либо сертификатов.

Меня беспокоит, будут ли данные по-прежнему шифроваться при обмене личной информацией. Это исполняемый JAR-файл, который клиенты будут загружать на свои компьютеры.

Так действительно ли сертификат необходим для этого случая?

Ответы [ 2 ]

4 голосов
/ 20 мая 2010

Это все еще зашифровано, НО не заслуживает доверия. Лучше вместо этого исправить проблемы с проверкой сертификата.

По сути, SSL обеспечивает как шифрование, так и механизм доверия. Вы обходите часть доверия, поэтому сообщение все равно будет зашифровано, но подвержено перехвату или отслеживанию с использованием, например, атаки «человек посередине». MITM может перехватить запрос и завершить рукопожатие SSL, используя совершенно другой сертификат. При желании они могут переслать ваше сообщение на заданный сервер и обратно, чтобы вы никогда не узнали, что сообщение было перехвачено.

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

См. keytool . Исполняемый файл keytool поставляется в комплекте с JDK, и вы можете использовать этот инструмент командной строки для создания «хранилища ключей» (в данном случае известного как «хранилище доверенных сертификатов») и импортировать в него сертификат.

Существует множество способов указать Java использовать хранилище ключей, и ваш выбор зависит от того, какие библиотеки и т. Д. Вы используете для установления соединения SSL. Одним из способов является использование параметров запуска, например ::

-Djavax.net.ssl.trustStore = mySrvKeystore -Djavax.net.ssl.trustStorePassword = 123456

Лучше всего в Google найти "keystore java" плюс имя вашей библиотеки (если вы ее используете)

НТН

2 голосов
/ 14 марта 2013

С таким диспетчером доверия (или с анонимными наборами шифров) соединение все равно будет зашифровано (при условии, что вы не включаете комплект шифров, использующий нулевой шифр, который никогда не должен включаться по умолчанию).

Однако клиент не будет знать, с какой сущностью он обменивается секретной информацией: это может быть злоумышленник типа «человек посередине».

Шифрования недостаточно: вам нужно знать, с кем вы разговариваете. Клиент должен убедиться, что:

  • доверяет сертификату сервера как подлинному (это цель диспетчера доверия, но не этой конкретной реализации, поскольку он никогда ничего не отклоняет),
  • этот сертификат действителен для имени хоста, с которым клиент собирался связаться.
...