No peer certificate android

Содержание

Авторизация с помощью клиентских SSL сертификатов в IOS и Android
Авторизация с помощью клиентских SSL сертификатов в IOS и Android
Анализ трафика Android-приложений: обход certificate pinning без реверс-инжиниринга
Что такое certificate pinning?
Обход certificate pinning
Русские Блоги
Управление корневыми сертификатами Android и проверка сертификатов
Управление корневым сертификатом Android
Проверка легальности цепочки сертификатов
Поиск TrustManager
Применение сертификата, подписанного частным ЦС

Авторизация с помощью клиентских SSL сертификатов в IOS и Android

Протокол безопасной передачи данных SSL (Secure Sockets Layer) помимо обеспечения безопасной передачи данных так же позволяет реализовать авторизацию клиентов при помощи клиентских SSL сертификатов. Данная статья является практическим руководством по реализации данного вида авторизации в мобильных приложениях на IOS и Android.

Процесс организации работы сервера обеспечивающего такой вид авторизации в статье не рассматривается, однако в конце приведены ссылки по данной тематике.

Процесс авторизации выглядит следующим образом. При переходе клиента в закрытую область сервер запрашивает у клиента сертификат, если проверка прошла успешно то клиент получает доступ к закрытому контенту в ином случае клиент может получить ошибку “No required SSL certificate was sent”.

Для организации подключения мы сгенирировали клиентский сертификат, а так же создали запрос на подписание сертификата в результате чего получили файл client.csr. Далее мы отправили данный файл поставщику услуг и получили наш подписанный клиентский сертификат необходимый для аутентификации на удаленном сервере.

Тестирование подключения может быть осуществлено при помощи утилиты curl.

curl cert client.crt key client.key k someserive.com

Однако стоит заметить, что в последняя версия curl 7.30.0 в OS X сломана и не может быть использована для организации тестирования (http://curl.haxx.se/mail/archive-2013-10/0036.html).

Для передачи клиентского сертификата мы будем использовать файл в формате PKCS#12. В файлах PKCS#12 хранятся одновременно и закрытый ключ, и сертификат (разумеется в зашифрованном виде). Примерная организация PKCS#12 файла показана на рисунке.

Сконвертировать Ваш client.crt в файл формата PKCS#12 можно при помощи следующей команды:

openssl pkcs12 export in client.crt inkey client.key out client.p12

После того как мы получили файл в формате PKCS#12 можно переходить к разработке и тестированию нашего мобильного приложения. Начнем с IOS.

1. Реализуем IOS версию приложения

Необходимо подключить к Вашему проекту Security.Framework
Для осуществления запроса нам необходимо извлечеть из PKCS#12 цифровой сертификат и ассоциированный с ним приватный ключ (SecIdentityRef). Наличие данного объекта позволит нам получить соответствующий NSURLCredential.
Итак реализуем функецию extractIdentityAndTrust.

Производим извлечение при помощи функции SecPKCS12Import, незабываем указать пароль к серитификату.
Далее реализуем делегат canAuthenticateAgainstProtectionSpace, вызов данного делегата позволяет нам определить свойства сервера, а именно протокол, механизм авторизации. У нас реализация этого делегата будет простой, укажем, что обрабатываем любой способ аутентификации представленный сервером.

Обработаем возможные ошибки:

Теперь перейдем к реализации непосредственно механизма аутентификации. Реализуем делегат didRecieveAuthentificationChallenge:

Загружаем наш сертификат, извлекаем из него нужные нам данные, создаем NSURLCredential, передаем нужную информацию, сохраняем данные аутентификации только в контексте текущей сессии.

Ну и для полноты картины приведу код подготавливающий NSURLConnection:

Реализацию делегата didReceiveData приводить не буду.

2. Реализуем Android версию приложения

Начну сразу с кода:

Получаем экземпляр соответствующего KeyStore в нашем случае это (PKCS12), загружаем из ресурсов наш сертификат, вторым аргументом указываем пароль. Далее создаем экземпляр SSLSocketFactory, использую собственную реализацию SSLSocketFactory, позволяющую инициализировать SSL контекст с использованием нашего сертификата. Код фабрики приведен чуть ниже. Далее конфигурируем параметры подключения, регистрируем нашу фабрику, указываем порт на который будем посылать запрос, формируем соответсвующий POST и выполняем запрос.

Заключение.

Мы рассмотрели как производить авторизацию по SSL с использованием клиентского сертификата.

Источник

Авторизация с помощью клиентских SSL сертификатов в IOS и Android

Тестирование подключения может быть осуществлено при помощи утилиты curl.

curl cert client.crt key client.key k someserive.com

Сконвертировать Ваш client.crt в файл формата PKCS#12 можно при помощи следующей команды:

openssl pkcs12 export in client.crt inkey client.key out client.p12

1. Реализуем IOS версию приложения

Обработаем возможные ошибки:

Ну и для полноты картины приведу код подготавливающий NSURLConnection:

Реализацию делегата didReceiveData приводить не буду.

2. Реализуем Android версию приложения

Начну сразу с кода:

Заключение.

Мы рассмотрели как производить авторизацию по SSL с использованием клиентского сертификата.

Источник

Анализ трафика Android-приложений: обход certificate pinning без реверс-инжиниринга

Иногда нужно исследовать работу бэкенда мобильного приложения. Хорошо, если создатели приложения не заморачивались и все запросы уходят по «голому» HTTP. А что, если приложение для запросов использует HTTPS, и отказывается принимать сертификат вашего корневого удостоверяющего центра, который вы заботливо внедрили в хранилище операционной системы? Конечно, можно поискать запросы в декомпилированом приложении или с помощью реверс-инжиниринга вообще отключить применение шифрования, но хотелось бы способ попроще.

Что такое certificate pinning?

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

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

Обход certificate pinning

В качестве подопытного выберем приложение Uber. Для анализа HTTP-трафика будем использовать Burp Suite. Также нам понадобится JDK и Android SDK (я использую все последней версии). Из Android SDK нам понадобится только утилита zipalign, так что при желании можно не скачивать весь SDK, а найти ее на просторах интернета.
Заранее облегчим себе жизнь, добавив следующие пути к нужным утилитам в переменную окружения PATH:

Открываем Burp, заходим в Proxy – Options – Add и добавляем Proxy Listener на интерфейсе, который будет доступен подопытному Android-устройству (или эмулятору). На устройстве в свою очередь настраиваем используемую Wi-Fi сеть на использование только что включенного прокси.

Скачаем apk-файл через apkpure.com, установим приложение на устройство и попытаемся войти в свой аккаунт – приложение зависнет на этапе аутентификации.

В логах Burp Suite (вкладка Alerts) при этом мы увидим множественные отчеты о неудачных SSL-рукопожатиях. Обратите внимание на первую строчку – именно через сервер cn-geo1.uber.com в моем случае осуществляется аутентификация, поэтому и не удается войти в приложение.

Дело в том, что Burp Suite при перехвате HTTPS-соединений (а мы помним, что все соединения устройства проксируются через него) подменяет сертификат веб-сервера на свой, который, естественно, не входит в список доверенных. Чтобы устройство доверяло сертификату, выполняем следующие действия. В Burp заходим в Proxy – Options и нажимаем Import/export CA certificate. Далее в диалоге выбираем Export Certificate. Копируем сертификат на устройство, переходим в Настройки – Безопасность – Установить сертификаты и устанавливаем наш сертификат в качестве сертификата для VPN и приложений.

Опять пытаемся войти в свой аккаунт. Сейчас приложение Uber сообщит нам только о неудачной попытке аутентификации – значит прогресс есть, осталось только обойти certificate pinning.

Откроем приложение в вашем любимом архиваторе как zip-архив. В папке res/raw можно заметить файл с говорящим названием ssl_pinning_certs_bk146.bks.

По его расширению можно понять, что Uber использует хранилище ключей в формате BouncyCastle (BKS). Из-за этого нельзя просто заменить сертификат в приложении. Сначала нужно сгенерировать BKS-хранилище. Для этого качаем jar для работы с BKS.

Теперь генерируем BKS-хранилище, которое будет содержать наш сертификат:

На вопрос о доверии сертификату отвечаем «yes». Опять открываем apk в архиваторе и заменяем оригинальное хранилище на наше (сохраняем при этом оригинальное название).

Но на этом все не заканчивается. Каждый apk должен быть подписан сертификатом разработчика. К счастью, это делается не для обеспечения безопасности, а для идентификации приложений, поэтому для наших исследовательских целей мы вполне можем использовать и недоверенный сертификат.

Удаляем из apk папку META-INF со старой подписью приложения и приступаем к генерации новой.
Создаем хранилище ключей и генерируем в нем ключ для подписи apk:

Подписываем только что сгенерированным ключом наш APK:

Теперь осталось выровнять данные в архиве по четырехбайтной границе:

Источник

Русские Блоги

Управление корневыми сертификатами Android и проверка сертификатов

Система PKI полагается на сертификаты для выполнения критической проверки личности, чтобы подтвердить надежность сервера. Проверка сертификата завершается в процессе подтверждения SSL / TLS. Процесс проверки обычно состоит из трех этапов:

Проверьте легитимность сертификата: этот шаг в основном предназначен для проверки того, что сертификат выпущен законным и действующим центром сертификации. Предварительно сохраните на клиенте надежную библиотеку корневых сертификатов ЦС, такую как FiexFox, Chrome, Android, Microsoft и т. Д., Поддержите свои собственные библиотеки корневых сертификатов и на основе этого проверьте легитимность цепочки сертификатов сервера. Система PKI использует надежную централизованную систему проверки подлинности, а именно CA, для подтверждения легитимности идентификатора сервера. Безопасность хранилища корневых сертификатов является очень важной частью нормальной работы системы PKI.

Проверьте соответствие доменного имени сертификата: сертификат сервера выдается для определенного доменного имени, и сертификат похож на идентификационную карту веб-сайта. Проверяя соответствие доменного имени, он может эффективно предотвратить подделку личности, например оператора, который запускает веб-сайт A, перехватывает запросы пользователей, олицетворяет личность веб-сайта B и крадет информацию. Если клиент не проверяет соответствие доменного имени, это вызовет большую поверхность атаки.Любой, кто получит законный сертификат любого доменного имени, может подделать целевой сервер.

Проверка закрепления сертификата: это относительно новый механизм повышения безопасности в системе PKI. В настоящее время существует множество центров сертификации организаций, выпускающих сертификаты, всего около сотен тысяч. Каждый центр сертификации может выдать действительный сертификат для любого доменного имени. Поэтому многие центры сертификации создали очень большую поверхность для атак. Например, если определенный ЦС был скомпрометирован или были допущены другие ошибки, злоумышленнику выдается сертификат для доменного имени, такого как www.google.com, и злоумышленник может подделать эти веб-сайты. Механизм закрепления сертификата был создан для решения этой проблемы — в механизме закрепления сертификата клиент связывает сертификат определенного доменного имени с конкретным издателем, то есть клиент распознает только определенное доменное имя, выданное конкретным эмитентом. Сертификат, выданный другими центрами сертификации для доменного имени, не распознается. Таким образом устраняется большое количество атак CA.

Читайте также: Unity android sdk путь

В приложениях Java системы Android проверка сертификата обычно выполняется несколькими компонентами на разных уровнях. Первым шагом является проверка действительности сертификата, в основном с помощью стандартной библиотеки Java. javax.net.ssl.SSLSocket В startHandshake() Метод завершен, а следующие два шага выполняются компонентами более высокого уровня, такими как библиотека HTTPS OkHttp.

В этой статье в основном обсуждается управление библиотекой корневых сертификатов и проверка законности сертификатов в Android. (Анализ в этой статье в основном основан на поведении системы android-7.1.1 / android-7.1.2, доступ к которой можно получить через GoogleСервер OpenGrok Прочтите исходный код системы Android. )

Управление корневым сертификатом Android

В репозитории исходного кода AOSP корневой сертификат CA в основном хранится в system/ca-certificates Каталог, а в системе Android он хранится в /system/etc/security/ В каталоге возьмем в качестве примера устройство Pixel системы Android 7.1.1:

среди них cacerts_google Корневой сертификат в каталоге в основном используется для system/update_engine 、 external/libbrillo с участием system/core/crash_reporter И другие модули, cacerts Корневой сертификат в каталоге используется для всех приложений. cacerts Корневой сертификат в каталоге, то есть библиотека корневых сертификатов системы Android, выглядит следующим образом:

Все это сертификаты X.509 в формате PEM. Система Android прошла SystemCertificateSource 、 DirectoryCertificateSource с участием CertificateSource Библиотека корневых сертификатов системы управления. CertificateSource Определение (находится в frameworks/base/core/java/android/security/net/config/CertificateSource.java ) Операции, которые могут быть выполнены с библиотекой корневых сертификатов, в основном предназначены для получения и поиска корневого сертификата:

DirectoryCertificateSource Класс основан на библиотеке корневых сертификатов, хранящейся в виде файла корневого сертификата, отдельно хранящегося в файловой системе, и обеспечивает операции создания, получения и поиска сертификатов. Определение этого класса (находится в frameworks/base/core/java/android/security/net/config/DirectoryCertificateSource.java )следующим образом:

Получите корневую библиотеку сертификатов getCertificates() Когда операция вызывается в первый раз, она просматривает файловую систему, загружает все файлы корневых сертификатов системы и кэширует их для последующего доступа. Операция поиска корневого сертификата в основном основана на имени файла сертификата. Файл сертификата требуется для [Хеш-значение SubjectName]. [Индекс] Назван в форме.

SystemCertificateSource Основное определение класса (находится в frameworks/base/core/java/android/security/net/config/SystemCertificateSource.java ) Путь к системной библиотеке корневых сертификатов и механизм аннулирования корневого сертификата:

Корневой сертификат системы Android находится по адресу /system/etc/security/cacerts/ Под содержимым. Пользователь может скопировать определенный корневой сертификат в каталог конфигурации пользователя. cacerts-removed Корневой сертификат в каталоге недействителен.

Платформа Android также предоставляет другой компонент для загрузки и доступа к библиотеке корневых сертификатов пользователя. UserCertificateSource , Определение этого класса (находится в frameworks/base/core/java/android/security/net/config/UserCertificateSource.java )следующим образом:

Этот компонент и SystemCertificateSource Аналогично, за исключением того, что он определяет путь к библиотеке корневых сертификатов пользователя.

Структура нескольких связанных компонентов выглядит следующим образом:

Проверка легальности цепочки сертификатов

Каким образом корневое хранилище сертификатов используется для процесса проверки сертификата при подтверждении связи SSL / TLS с корневым хранилищем сертификатов?

Срок действия сертификата определяется стандартной библиотекой Java. javax.net.ssl.SSLSocket В startHandshake() Метод завершен. Для системы Android SSLSocket Эта реализация, основанная на реализации библиотеки OpenSSL, реализована external/conscrypt Модуль предоставлен, SSLSocket Реализуется как OpenSSLSocketImpl Класс (находится в external/conscrypt/src/main/java/org/conscrypt/OpenSSLSocketImpl.java ）。

OpenSSLSocketImpl.startHandshake() Подтверждение SSL / TLS — чрезвычайно деликатный процесс. Мы пропускаем подробный процесс установления связи и сосредотачиваемся на части проверки сертификата.

OpenSSLSocketImpl.startHandshake() Проходят NativeCrypto Класс (находится в external/conscrypt/src/main/java/org/conscrypt/NativeCrypto.java ) Статический метод локального слоя SSL_do_handshake() Метод выполняет операцию рукопожатия:

NativeCrypto Класс определяет набор обратных вызовов, которые будут вызываться кодом OpenSSL C / C ++, связанным с рукопожатием SSL на локальном уровне. SSLHandshakeCallbacks ,над SSL_do_handshake() В методе этот набор обратных вызовов передается на локальный уровень в качестве параметров.

SSLHandshakeCallbacks Это определяется следующим образом:

среди них verifyCertificateChain() Обратный вызов используется для проверки сертификата сервера. Система Android использует этот обратный вызов для подключения модуля управления библиотекой корневых сертификатов с подтверждением связи SSL / TLS и проверкой подлинности базового OpenSSL.

SSLHandshakeCallbacks Обратный звонок от OpenSSLSocketImpl достичь, verifyCertificateChain() Реализация следующая:

OpenSSLSocketImpl из verifyCertificateChain() Из sslParameters Получить X509TrustManager А потом в Platform.checkServerTrusted() （ com.android.org.conscrypt.Platform ,роды external/conscrypt/src/compat/java/org/conscrypt/Platform.java ) При выполнении проверки действительности сертификата на стороне сервера:

Platform.checkServerTrusted() Выполняя X509TrustManager из checkServerTrusted() Метод выполняет проверку действительности сертификата.

X509TrustManager Из OpenSSLSocketImpl из sslParameters , Что sslParameters Откуда это? OpenSSLSocketImpl из sslParameters Передано создателем объекта:

Другими словами, OpenSSLSocketImpl из sslParameters Из javax.net.ssl.SSLSocketFactory ,который OpenSSLSocketFactoryImpl 。 OpenSSLSocketFactoryImpl Определение (находится в external/conscrypt/src/main/java/org/conscrypt/OpenSSLSocketFactoryImpl.java )следующим образом:

OpenSSLSocketImpl Основная ответственность — установить параметры SSL / TLS. SSLParametersImpl Придерживайтесь SSLSocket. В основном смотрите по умолчанию SSLParametersImpl из X509TrustManager Что находится (находится в external/conscrypt/src/main/java/org/conscrypt/SSLParametersImpl.java ）：

Будет createDefaultX509TrustManager() Скопируйте код в наше приложение, как показано ниже:

Прервите точку во время выполнения приложения и подтвердите системное значение по умолчанию с помощью Android Studio X509TrustManager Что это такое, подтвердить несложно, это android.security.net.config.RootTrustManager 。 android.security.net.config.RootTrustManager из checkServerTrusted() Определение (находится в frameworks/base/core/java/android/security/net/config/RootTrustManager.java )следующим образом:

NetworkSecurityConfig из getTrustManager() Определение (находится в frameworks/base/core/java/android/security/net/config/NetworkSecurityConfig.java )следующим образом:

NetworkSecurityConfig Компоненты библиотеки корневых сертификатов SystemCertificateSource 、 UserCertificateSource И провести проверку легальности сертификата NetworkSecurityTrustManager Поднимите это:

Одновременно NetworkSecurityConfig Он также предоставляет некоторые операции для поиска корневых сертификатов на основе определенных условий:

Разве не правда, что проводится проверка легальности сертификата? NetworkSecurityTrustManager , Но TrustManagerImpl (роды external/conscrypt/src/platform/java/org/conscrypt/TrustManagerImpl.java ) От NetworkSecurityTrustManager Определение (находится в frameworks/base/core/java/android/security/net/config/NetworkSecurityTrustManager.java ) В этом нетрудно убедиться:

TrustedCertificateStoreAdapter Предоставляется для корневого хранилища сертификатов TrustedCertificateStore Найдите интерфейс для облегчения TrustManagerImpl Использование (находится в frameworks/base/core/java/android/security/net/config/TrustedCertificateStoreAdapter.java ）：

Нетрудно увидеть процесс проверки сертификата уровня Java в Android, как показано на рисунке ниже:

OpenSSLSocketImpl.startHandshake() с участием NativeCrypto.SSL_do_handshake() Выполните полный процесс подтверждения SSL / TLS. В качестве важного шага подтверждения SSL / TLS проверка законности сертификата осуществляется с помощью метода обратного вызова уровня Java, вызываемого локальным уровнем. SSLHandshakeCallbacks.verifyCertificateChain() осуществлять, OpenSSLSocketImpl Реализуйте этот обратный вызов. OpenSSLSocketImpl.verifyCertificateChain() 、 Platform.checkServerTrusted() 、 RootTrustManager.checkServerTrusted() с участием NetworkSecurityTrustManager.checkServerTrusted() Используется для проверки законности сертификата в соответствии с системной корневой библиотекой сертификатов TrustManagerImpl Придерживайтесь процесса подтверждения SSL / TLS. OpenSSLSocketFactoryImpl Будет OpenSSLSocketImpl с участием SSLParametersImpl Держи это. SSLParametersImpl Будет OpenSSLSocketImpl с участием RootTrustManager Держи это.

NetworkSecurityConfig Будет RootTrustManager с участием NetworkSecurityTrustManager Держи это. NetworkSecurityConfig 、 NetworkSecurityTrustManager с участием TrustedCertificateStoreAdapter Будет TrustManagerImpl Библиотека корневых сертификатов системы управления SystemCertificateSource Держи это.

TrustManagerImpl Это ядро проверки легитимности сертификата. Оно выполняет поиск в библиотеке корневых сертификатов системы и проверяет легитимность сертификата сервера.

Стек вызовов этого процесса выглядит следующим образом:

Есть еще два вопроса, один SSLParametersImpl Как ты это нашел RootTrustManager ; Второй — как настроить или повлиять на процесс проверки законности сертификата.

Поиск TrustManager

Архитектура шифрования Java (JCA) — очень гибкая архитектура, и ее общая структура выглядит следующим образом:

Приложения Java получают доступ к службам шифрования через уровень интерфейса. В состав уровня интерфейса входят JAAS (Java Authentication Authorization Service, Java Authentication and Authorization API), JSSE (Java Secure Socket Extension, Java Secure Socket Extension), JGSS (Java Generic Security Service) ) И CertPath и т. Д. Конкретные компоненты, как мы видели ранее CertificateFactory 、 TrustManagerFactory с участием SSLSocketFactory Подождите.

JCA также определяет набор интерфейсов поставщика услуг шифрования, например javax.net.ssl.SSLContextSpi с участием javax.net.ssl.TrustManagerFactorySpi Подождите. Разработчики служб шифрования реализуют эти интерфейсы и передают java.security.Security Предоставленный интерфейс зарегистрирован в структуре JCA.

Для системы Android TrustManagerFactory Регистрация службы шифрования находится на ActivityThread из handleBindApplication() Соответствующий код (находится в frameworks/base/core/java/android/app/ActivityThread.java )следующим образом:

NetworkSecurityConfigProvider Определение класса (находится в frameworks/base/core/java/android/security/net/config/NetworkSecurityConfigProvider.java )следующим образом:

В NetworkSecurityConfigProvider.install() В методе передайте Security.insertProviderAt() Будет NetworkSecurityConfigProvider Зарегистрирован в рамках JCA. Из NetworkSecurityConfigProvider Конструктор видит, что он android.security.net.config.RootTrustManagerFactorySpi Внесите в структуру JCA.

android.security.net.config.RootTrustManagerFactorySpi Определение (находится в frameworks/base/core/java/android/security/net/config/RootTrustManagerFactorySpi.java )следующим образом:

RootTrustManagerFactorySpi из TrustManager Из ApplicationConfig ， ApplicationConfig Средний TrustManager Связанный код (находится в frameworks/base/core/java/android/security/net/config/ApplicationConfig.java )следующим образом:

ApplicationConfig из TrustManager Да RootTrustManager 。

Давайте посмотрим на уровень интерфейса JCA javax.net.ssl.TrustManagerFactory Определение:

TrustManagerFactory Предоставляется через структуру JCA sun.security.jca.GetInstance Найти зарегистрированные javax.net.ssl.TrustManagerFactorySpi . Приложение прошло javax.net.ssl.TrustManagerFactory -> android.security.net.config.RootTrustManagerFactorySpi -> android.security.net.config.ApplicationConfig Получить android.security.net.config.RootTrustManager ,который X509TrustManager 。

Применение сертификата, подписанного частным ЦС

Самозаверяющие сертификаты — это сертификаты, которые не нужно подписывать другими сертификатами для подтверждения их легитимности. Все корневые сертификаты являются самозаверяющими. Сертификат подписи частного ЦС относится к ЦС, который подписывает сертификат доменного имени, юридическая сила которого не получила широкого признания, а корневой сертификат ЦС не встроен в систему.

В фактическом процессе разработки, иногда для того, чтобы сэкономить дорогостоящие расходы на покупку сертификата, вы хотите выпустить сертификат доменного имени для доменного имени вашего сервера, который является сертификатом, подписанным частным ЦС. Чтобы иметь возможность использовать этот тип сертификата, необходимо встроить корневой сертификат на стороне клиента и вмешаться в процесс проверки законности клиентского сертификата. С помощью нашего встроенного корневого сертификата мы можем проверить законность сертификата сервера, не полагаясь на систему. Хранилище корневых сертификатов.

настроить javax.net.ssl.SSLSocket Цена слишком высока, обычно не на заказ javax.net.ssl.SSLSocket Чтобы изменить процесс проверки легальности сертификата сервера. Исходя из этого, из приведенного выше анализа нетрудно увидеть, что если вы хотите настроить OpenSSLSocketImpl Процесс проверки сертификата должен измениться SSLParametersImpl Изменить OpenSSLSocketImpl из SSLParametersImpl , Вы должны изменить SSLSocketFactory . Изменить SSLSocketFactory Часто это хороший метод.

В Java SSLContext Он предназначен для этой цели. Создать индивидуальный SSLParametersImpl , Который настроен TrustManager из SSLSocketFactory Метод выглядит следующим образом:

SSLContext Реализация связанного метода (находится в libcore/ojluni/src/main/java/javax/net/ssl/SSLContext.java )следующим образом:

среди них SSLContextSpi За OpenSSLContextImpl , Реализация этого класса (находится в external/conscrypt/src/main/java/org/conscrypt/OpenSSLContextImpl.java )следующим образом:

Как мы обсуждали ранее, проверка легитимности сертификатов на стороне сервера является чрезвычайно важным звеном в системе PKI для обеспечения безопасности системы. Если действительность сертификата сервера не проверена, даже если HTTPS развернут, HTTPS будет бесполезным и бесполезным. Итак, в нашей собственной реализации X509TrustManager Важно загрузить встроенный корневой сертификат и на его основе проверить действительность сертификата сервера. checkServerTrusted() Завершено в. Однако для того, чтобы мы достигли X509TrustManager Функция более полная. Если проверка не соответствует нашему встроенному корневому сертификату, мы будем использовать систему по умолчанию. X509TrustManager Сделайте проверку, как показано ниже:

Кроме того, вы также можете сделать это самостоятельно X509TrustManager , И только изменить X509TrustManager Используется следующее хранилище корневых сертификатов:

Сделай это сам X509TrustManager Интерфейс и пройти TrustManagerFactory , Только по индивидуальному заказу KeyStore Эти два творения X509TrustManager Объектный метод, конечно, лучше, чем последний метод. Как мы видели ранее, систематический X509TrustManager Достичь RootTrustManager Интегрирован из X509ExtendedTrustManager , Не реализовано напрямую X509TrustManager Интерфейс. Уровень интерфейса JCA также постоянно расширяется с разработкой новых протоколов безопасности и библиотек SSL. При реализации конкретных служб шифрования Java эти расширенные функции могут быть реализованы и зависеть от них, как показано выше. X509TrustManager , И реализация служб шифрования часто использует отражение, чтобы динамически полагаться на некоторые расширенные интерфейсы. Поэтому осознайте X509TrustManager Интерфейс и другие интерфейсы, связанные с шифрованием, такие как SSLSocket И так далее, некоторые функции могут быть нарушены.

Много раз вы могли видеть, что для использования сертификата, подписанного частным ЦС, логика настройки проверки соответствия доменного имени реализуется вами самостоятельно. HostnameVerifier . Однако при нормальных обстоятельствах сетевая библиотека будет строго проверять соответствие доменного имени и сертификата в соответствии со спецификациями, поэтому в этом нет необходимости, если в сертификате доменного имени нет чего-то менее стандартизованного.

Что касается закрепления сертификата, это обычно кажется ненужным при использовании сертификата, подписанного частным ЦС.

Источник