Те вещи о Java и HTTP (4) HTTPS и сертификаты

HTTPS HTTP

Когда речь идет о HTTP, вы должны упомянуть HTTPS, а когда речь идет о HTTPS, вы должны упомянуть цифровые сертификаты. В этом блоге мы изучим HTTPS и технологию цифровых сертификатов с точки зрения Java, а также расскажем о некоторых проблемах, которые могут возникнуть при сканировании HTTPS-сайтов в процессе разработки поискового робота.
В предыдущих блогах HTTPS фактически упоминался незначительно, например, использованиеHttpsURLConnectionкласс для отправки запросов HTTPS, некоторые различия между HTTP и HTTPS при использовании прокси и т.д. Концепция HTTPS не ерунда, давайте перейдем непосредственно к теме ниже.

1. Посетите HTTPS-сайты

В предыдущем первом блоге«Смоделированный HTTP-запрос»Здесь представлены два метода для имитации отправки HTTP-запросов и доступа к HTTP-сайтам. Один из способов — через java.net, который поставляется сHttpURLConnection, другой способ - через ApacheHttpClient, оба метода имеют свои преимущества. Эти два метода также используются здесь для доступа Сайт HTTPS, как видно из приведенного ниже кода, почти точно такой же, как и предыдущий доступ к сайту HTTP.

1.1 Использование HttpURLConnection

@Test
public void basicHttpsGet() throws Exception {
     
    String url = "https://www.baidu.com";
    URL obj = new URL(url);
 
    HttpsURLConnection con = (HttpsURLConnection) obj.openConnection(); 
    con.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64) ...");
    con.setRequestProperty("Accept-Language", "en-US,en;q=0.5");
    con.setRequestMethod("GET");
 
    String responseBody = readResponseBody(con.getInputStream());
    System.out.println(responseBody);
}

1.2 Использование HttpClient

@Test
public void basicHttpsGet() throws Exception {
     
    String url = "https://www.baidu.com";   
    HttpGet request = new HttpGet(url);
    request.setHeader("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64) ...");
     
    CloseableHttpClient httpclient = HttpClients.createDefault();
    CloseableHttpResponse response = httpclient.execute(request);
    String responseBody = readResponseBody(response);
    System.out.println(responseBody);
}

Для конкретного объяснения кода, пожалуйста, обратитесь к первому блогу, который не будет повторяться здесь. В общем, доступ к сайту HTTPS так же прост, как доступ к сайту HTTP.И HttpURLConnection, и HttpClient инкапсулируют основные детали реализации и предоставляют нам согласованный внешний интерфейс, поэтому нам не нужно заботиться о принципе реализации HTTPS. Инкапсуляция лежащих в основе деталей — это изначально хорошая вещь, а также хороший метод проектирования, который может упростить использование разработчиками и повысить эффективность разработки, но для тех, кто мало о нем знает, он может принести больше пользы. путаница.удобнее приехать.

1.3 Обнаружен сбой построения пути PKIX

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

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

Чтобы устранить это исключение, мы рассмотрим это в этой статье.

Во-вторых, принцип аутентификации сертификата

Реакция большинства людей, когда они впервые сталкиваются с вышеуказанным исключением, вероятно, пуста, потому что ненормальная информационная подсказка относительно расплывчата.Для людей, которые не понимают HTTPS, что такое SSLHandshake и какой путь PKIX, совершенно незнакомы. Поэтому нам нужно понять, как работает HTTPS, прежде чем мы сможем решить эту проблему. Мы знаем, что HTTPS на самом деле является комбинацией HTTP + SSL/TLS. На самом деле это протокол HTTP, но у него есть дополнительный уровень. SSL — это зашифрованный протокол безопасности. Целью введения SSL является решение проблемы использования Протокол HTTP в ненадежных сетях Проблемы безопасности, вызванные передачей данных открытым текстом. Можно сказать, что коммуникационная безопасность всего Интернета основана на Помимо безопасности SSL/TLS.

2.1 Протокол SSL/TLS и его процесс рукопожатия

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

В Интернете есть много схематических диаграмм рукопожатий SSL/TLS.Следующая схема очень подробная и профессиональная.Студенты, которые хотят узнать больше о SSL/TLS, могут изучить ее.

woohoo.cheat-sheets.org/saved-copy/…

Жуань Ифэн в своем«Обзор механизма работы протокола SSL/TLS»и«Иллюстрированный протокол SSL/TLS»Принципы SSL/TLS подробно представлены в двух блогах, и заинтересованные студенты могут ознакомиться с ними. я использую здесьРуководство пользователя IBM Tivoli Risk ManagerИзображение (потому что его относительно легко понять), чтобы примерно проиллюстрировать процесс рукопожатия, который происходит в середине, когда мы обычно используем браузер для доступа к сайту HTTPS.

ssl_handshake.png

Весь процесс рукопожатия и связи SSL/TLS, говоря простыми словами, можно разделить на следующие три этапа:

  1. приветствовать
  • Когда пользователь посещает HTTPS-сайт через браузер, браузер передает приветствие серверу (ClientHello), а сервер также передает приветствие браузеру (ServerHello). Так называемое приветствие фактически сообщает друг другу их соответствующие номера версий SSL/TLS и поддерживаемые алгоритмы шифрования и т. д., чтобы дать друг другу предварительное понимание.
  1. идентифицировать, подтвердить личность
  • Второй шаг — самый сложный во всем процессе и ключевой в HTTPS-коммуникациях. Для обеспечения безопасности общения, в первую очередь, мы должны убедиться, что человек, с которым я общаюсь, действительно тот человек, с которым я хочу общаться, сервер отправит сертификат, чтобы указать его личность, а браузер проверит его. по информации в аттестате (зачем проходить аттестат? Можно ли подтвердить личность? Как удостоверить личность другой стороны через аттестат? Об этом позже). В случае взаимной аутентификации браузер также отправит сертификат клиента на сервер.
  • После проверки личности обеих сторон браузер согласовывает с сервером "сеансовый ключ". Следует отметить, что этот "сеансовый ключ" нельзя отправить другой стороне напрямую, а следует отправить таким образом, чтобы только другая сторона может понять.Дайте ему, чтобы ключ не был перехвачен другими (или даже если он будет перехвачен, он не будет понят).
  1. коммуникация
  • На этом рукопожатие закончилось. Две стороны начинают общаться в чате и шифруют передаваемые данные с помощью «ключа разговора».

Процесс рукопожатия примерно такой же.Теперь мы узнали, что для связи HTTPS требуется рукопожатие, поэтому выше см.javax.net.ssl.SSLHandshakeExceptionЭто исключение нам нетрудно понять, на самом деле это проблема во время рукопожатия SSL/TLS. Конечно, есть много, много деталей, продолжим ниже.

2.2 Криптография в HTTPS

Причина, по которой протокол HTTPS сложен, заключается в обеспечении безопасности данных в процессе связи, а для обеспечения безопасности связи в протоколе используется множество принципов криптографии, можно сказать, что HTTPS является кульминацией криптографии. . Будь то в процессе рукопожатия SSL/TLS или в процессе зашифрованной связи, HTTPS включает большое количество криптографических концепций.Например, алгоритмы хеширования и асимметричные алгоритмы шифрования используются в цифровой подписи сертификатов.В процессе связи используется симметричный алгоритм шифрования.Для предотвращения подделки и повторного воспроизведения передаваемых данных также используется MAC (код аутентификации сообщения).

Если вы хотите иметь глубокое представление о том, как работает HTTPS, необходимо тщательно изучить следующие концепции.В Интернете уже есть много статей, которые знакомят с этими концепциями, поэтому я кратко изложу их здесь.

  • хэш
    • Алгоритм хеширования, также известный как хеширование, представляет собой алгоритм, который преобразует данные любой длины в данные фиксированной длины.
    • Алгоритм хеширования необратим
    • Распространенные алгоритмы хеширования: MD5 и SHA1.
  • Симметричное шифрование
    • Симметричное шифрование означает, что для шифрования и дешифрования используется один и тот же ключ.
    • Преимущество симметричного шифрования в том, что оно быстрое, а недостаток в том, что управление ключами неудобно и ключ должен быть общим.
    • Общие алгоритмы симметричного шифрования включают DES, AES, Blowfish и т. д.
  • Асимметричное шифрование
    • Асимметричное шифрование означает, что при шифровании и дешифровании используются разные ключи, один из которых является открытым, а другой — закрытым, причем открытый ключ является открытым, а закрытый ключ известен только вам.
    • Данные, зашифрованные с помощью открытого ключа, должны быть расшифрованы с помощью закрытого ключа, а данные, зашифрованные с помощью закрытого ключа, должны быть расшифрованы с помощью открытого ключа.
    • Существует некоторая связь между открытым ключом и закрытым ключом, но закрытый ключ не может (или его трудно) вывести из открытого ключа.
    • Недостаток асимметричного шифрования в том, что оно медленное, а преимущество в том, что управление ключами очень удобно.
    • Общие алгоритмы асимметричного шифрования включают RSA, ECC и т. д.
  • Цифровой сертификат

2.3 О сертификате

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

Узнав, что такое сертификат, мы часто больше беспокоимся о его принципе.Когда мы представили рукопожатие SSL/TLS выше, у нас осталось два вопроса: почему мы можем подтвердить свою личность с помощью сертификата? Как проверить личность другой стороны с помощью сертификата?

Для этого требуется асимметричное шифрование, упомянутое выше.Важной особенностью асимметричного шифрования является то, что данные, зашифрованные с помощью открытого ключа, должны быть расшифрованы с помощью закрытого ключа.Точно так же данные, зашифрованные с помощью закрытого ключа, должны быть расшифрованы с помощью открытого ключа. Именно благодаря этой функции веб-сайт может раскрывать свой открытый ключ в своем собственном сертификате и использовать свой собственный закрытый ключ для шифрования своей идентификационной информации и раскрывать ее вместе.Эта часть информации, зашифрованная закрытым ключом, является цифровой подписью сертификат. , после получения сертификата браузер расшифровывает подпись с помощью открытого ключа в сертификате. Если он может быть успешно расшифрован, это означает, что сертификат действительно выдан этим сайтом, потому что только этот сайт знает свой собственный закрытый ключ (если его, если закрытый ключ не утек).

Среди алгоритмов асимметричного шифрования наиболее выдающимся является алгоритм RSA, Математические детали алгоритма RSA см. в книге Руана Ифэна.«Принцип алгоритма RSA (1)»и«Принцип алгоритма RSA (2)»Эти два блога настоятельно рекомендуются.

Конечно, если цифровая подпись просто проверена, нельзя полностью гарантировать, что сертификат действительно принадлежит веб-сайту.Хакеры могут перехватить его посередине, зашифровать идентификационную информацию веб-сайта с помощью своего закрытого ключа и зашифровать идентификационная информация в сертификате.Открытый ключ заменяется собственным открытым ключом, так что браузер также может расшифровать цифровую подпись, и идентификационная информация в подписи также полностью легальна. Это как те разносчики, у которых на улице фальшивые печати, они могут подделать точно такую ​​же печать, как и настоящую. Для решения этой проблемы специалисты по информационной безопасности ввели УЦ, так называемые УЦ, полное название Центра сертификации в переводе на китайский языкЦентр сертификации, которое является сторонним агентством, которое специализируется на управлении и выпуске сертификатов. Поскольку центр сертификации связан с идентификацией всех интернет-коммуникаций, он должен быть очень авторитетным, например GeoTrust, GlobalSign и другие, вот копияСписок распространенных ЦС. Если веб-сайт должен поддерживать HTTPS, ему нужен сертификат для подтверждения своей личности, и этот сертификат должен быть запрошен в агентстве CA.В большинстве случаев цена подачи заявки на цифровой сертификат высока, но есть и бесплатные сертификаты для личного пользования. , вроде недавнего пожараLet's Encrypt. С точки зрения безопасности нет никакой разницы между бесплатными и платными сертификатами, оба из которых могут обеспечить достаточно высокий уровень безопасности для вашего веб-сайта.Единственная разница заключается в том, что если вы покупаете платный сертификат в уполномоченном органе, после того, как сертификат будет защищен, проблема приводит к экономическим потерям, и можно получить огромную сумму компенсации.

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

На следующем рисунке показан процесс подачи заявки на сертификат (изображение изТехнический блог Лю Куня):

shuzizhengshu_5.png

Сертификат ЦС может иметь иерархическую структуру, которая устанавливает нисходящую цепочку доверия, нижний ЦС доверяет верхнему ЦС, а нижний ЦС выдается и сертифицируется вышестоящим ЦС. Например, цепочка сертификатов Google показана на следующем рисунке:

shuzizhengshu_6.png

Видно, что SSL-сертификат google.com.hk проверен Google Internet Authority G2, который проверен GeoTrust Global CA, который проверен Equifax Secure Certificate Authority. Этот самый верхний сертификат, мы называем его корневым сертификатом (root certificate), так кто же будет проверять корневой сертификат? Ответ сам по себе.Корневой сертификат доказывает сам себя.Иными словами, корневой сертификат не нужно доказывать. Когда браузер проверяет сертификат, он начинает с корневого сертификата и проверяет путь цепочки сертификатов.Корневой сертификат обеспечивает безопасность всей цепочки сертификатов.Если корневой сертификат подделан, безопасность всей системы сертификатов будет угрожать. Так что не доверяйте корневому сертификату легко. Когда вам будет предложено в следующий раз, когда вы посетите веб-сайт, установите наш корневой сертификат, это может сделать ваш визит на наш веб-сайт более плавным и безопасным. Вам лучше быть осторожным. Перед установкой ознакомьтесь с этими блогами:"12306 проблем с сертификатами",«Почему мне нужно устанавливать корневой сертификат при покупке билетов на поезд в Интернете? 》.

Наконец, чтобы подвести итог тому, что я сказал выше, то, что асимметричное шифрование, цифровые подписи, агентства CA, корневые сертификаты и т. д. на самом деле являются основными концепциями PKI. PKI (инфраструктура открытых ключей) на китайском языке называется инфраструктурой открытых ключей.Она предоставляет систему или платформу для шифрования с открытым ключом и услуги цифровой подписи для облегчения управления ключами и сертификатами, тем самым создавая безопасную сетевую среду. Наиболее распространенным форматом цифровых сертификатов является X.509, поэтому эта инфраструктура открытых ключей также называется PKIX.

До сих пор мы примерно понимали приведенную выше информацию об исключении,sun.security.validator.ValidatorException: PKIX path building failed, то есть при проверке сертификата по пути цепочки сертификатов возникло исключение, и проверка не удалась.

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

2.4 О сертификатах в Java

Выше описан процесс проверки сертификата браузером. Браузер сохраняет список часто используемых сертификатов ЦС. При проверке действительности цепочки сертификатов он напрямую использует открытый ключ в сохраненном сертификате для проверки. Если список не найдено или найдено, но проверка не удалась, браузер предупредит пользователя, и пользователь сам решит, продолжать ли. Точно так же операционная система также поддерживает список доверенных сертификатов.Например, под Windows вы можете запуститьcertmgr.mscОткройте диспетчер сертификатов, чтобы увидеть, что эти сертификаты на самом деле хранятся в реестре Windows, обычно по адресу:\SOFTWARE\Microsoft\SystemCertificates\под дорожкой. Так как же проверяется сертификат в программе Java?

Подобно браузерам и операционным системам, Java также сохраняет список доверенных сертификатов по умолчанию в каталоге установки JRE.$JRE/lib/security/cacertsв файле. Чтобы просмотреть этот файл, вы можете использовать что-то вродеKeyStore ExplorerДля такого программного обеспечения, конечно, вы также можете использовать инструмент keytool, который поставляется с JRE (описан ниже).Пароль по умолчанию для файла cacerts:changeit(Но я обещаю, что большинство людей не изменит его).

Мы знаем, что существует множество различных форматов хранения сертификатов. Например, когда центры сертификации выдают сертификаты, они часто используют формат PEM. Преимущество этого формата заключается в простом тексте, кодировке содержимого BASE64 и "----- BEGIN CERTIFICATE В сертификате используется ". -----" и "-----КОНЕЦ СЕРТИФИКАТА-----". Кроме того, есть более распространенный двоичный формат DER, более распространенный формат PKCS#12 на платформе Windows и так далее. Конечно, сертификаты в разных форматах можно конвертировать друг в друга, мы можем использоватьopensslЭтот инструмент командной строки для преобразования, см.SSL ConverterКроме того, если вы хотите узнать больше о формате сертификата, вы можете обратиться сюда:Various SSL/TLS Certificate File Types/Extensions.

На платформе Java сертификаты часто хранятся в файлах KeyStore. Упомянутый выше файл cacerts является файлом KeyStore. KeyStore может хранить не только цифровые сертификаты, но и ключи. В файлах KeyStore хранятся три типа объектов: Сертификат, PrivateKey и Секретный ключ. Certificate — это сертификат, PrivateKey — это закрытый ключ в асимметричном шифровании, а SecretKey используется в симметричном шифровании, которое является ключом в симметричном шифровании. Файлы KeyStore также доступны во многих различных форматах в зависимости от их назначения: JKS, JCEKS, PKCS12, DKS. Подождите, на PixelsTech есть серия статей с подробным введением в KeyStore, вы можете узнать:Different types of keystore in Java.

До сих пор KeyStore, о котором мы говорили, на самом деле является просто форматом файла.На самом деле, в мире Java файлы KeyStore делятся на два типа: KeyStore и TrustStore.Это два понятия, которые легко спутать, но эти две вещи от Формат файла на самом деле тот же. KeyStore сохраняет закрытый ключ, который используется для шифрования и расшифровки или подписи для других; TrustStore сохраняет некоторые доверенные сертификаты для аутентификации посетителя при доступе к HTTPS, чтобы гарантировать его надежность. То есть, если быть точным, приведенный выше файл cacerts должен называться TrustStore вместо KeyStore, но его формат файла Формат файла хранилища ключей.

Помимо KeyStore и TrustStore, в Java есть два других класса, KeyManager и TrustManager, которые тесно связаны с этим.Справочное руководство по JSSEСуществует диаграмма, иллюстрирующая отношения между различными классами:

jsse-class.jpg

Видно, что если вы хотите иметь сеанс SSL, вы должны создать новый.SSLSocketобъект, в то время как объект SSLSocketSSLSocketFactoryДля управления объект SSLSocketFactory зависит отSSLContext, объект SSLContext, в свою очередь, зависит отkeyManager,TrustManagerиSecureRandom. Наша главная забота здесь TrustManager, два других пока игнорируются, потому что именно TrustManager отвечает за проверку сертификата и аутентификацию веб-сайта.Если вы хотите пройти аутентификацию при доступе по HTTPS, не сообщайтеsun.security.validator.ValidatorExceptionНенормально, нужно управлять отсюда.

3. Пользовательский TrustManager для обхода проверки сертификата

Мы знаем, что TrustManager специально отвечает за проверку сертификатов, поэтому самый простой способ придумать — это переписать класс TrustManager так, чтобы он не проверял сертификат. также Его действительно можно переписать, вот пример кода:

@Test
public void basicHttpsGetIgnoreCertificateValidation() throws Exception {
     
    String url = "https://kyfw.12306.cn/otn/";
     
    // Create a trust manager that does not validate certificate chains
    TrustManager[] trustAllCerts = new TrustManager[] {
        new X509TrustManager() {
            public X509Certificate[] getAcceptedIssuers() {
                return null;
            }
            public void checkClientTrusted(X509Certificate[] certs, String authType) {
                // don't check
            }
            public void checkServerTrusted(X509Certificate[] certs, String authType) {
                // don't check
            }
        }
    };
     
    SSLContext ctx = SSLContext.getInstance("TLS");
    ctx.init(null, trustAllCerts, null);
     
    LayeredConnectionSocketFactory sslSocketFactory = new SSLConnectionSocketFactory(ctx);
     
    CloseableHttpClient httpclient = HttpClients.custom()
            .setSSLSocketFactory(sslSocketFactory)
            .build();
     
    HttpGet request = new HttpGet(url);
    request.setHeader("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64) ...");
     
    CloseableHttpResponse response = httpclient.execute(request);
    String responseBody = readResponseBody(response);
    System.out.println(responseBody);
}

Мы создали новый анонимный класс, который наследуется отX509TrustManagerИнтерфейс, этот интерфейс предоставляет три метода проверки действительности сертификата:getAcceptedIssuers,checkClientTrusted,checkServerTrusted, возвращаем прямо в функцию проверки без всякой проверки, чтобы при обращении При использовании сайта HTTPS, даже если сертификат не является доверенным, исключение не будет выдано, и выполнение может быть продолжено.

Хотя этот метод прост, у него есть одна из самых серьезных проблем — ненадежность. Поскольку для сертификата нет проверки действительности, и эта обработка является глобальной, все сертификаты не будут проверяться независимо от всех без исключения, поэтому, даже если он встретит ненадежный сертификат, код будет продолжать с ним связываться. данные не могут быть гарантированы. Так что, если вы просто хотите провести эксперимент в тестовой среде, это нормально, но будьте осторожны, если вы выпускаете свой код в производство.

В-четвертых, используйте сертификат

Для некоторых сертификатов мы в основном уверены, что им можно доверять, но этих сертификатов нет в файле cacerts Java, например, на веб-сайте 12306 или на некоторых веб-сайтах, использующих сертификат Let's Encrypt, для этих веб-сайтов мы можем добавить его в список доверия Вместо того, чтобы использовать описанный выше метод, я считаю, что безопасность программы все же может быть гарантирована.

4.1 Импорт сертификата с помощью keytool

Самый простой способ — импортировать сертификаты этих веб-сайтов в файл cacerts, чтобы программа Java могла найти и успешно проверить сертификат из файла cacerts при проверке сертификата. Выше мы представили ключевой инструмент, который поставляется с JRE, Это небольшой, но мощный инструмент с множеством функций. Сначала мы можем использовать его для просмотра файла KeyStore, используя следующую команду, чтобы вывести список всего в файле KeyStore (включая сертификаты, закрытые ключи и т. д.):

$ keytool -list -keystore cacerts

Затем импортируйте сертификат в файл cacerts с помощью следующей команды:

$ keytool -import -alias 12306 -keystore cacerts -file 12306.cer

Чтобы импортировать сертификат веб-сайта в файл cacerts, вы должны сначала получить сертификат веб-сайта, например файл 12306.cer в приведенной выше команде, который сохраняется с помощью мастера экспорта сертификатов браузера. Как показано ниже:

export-cert.png

Для получения дополнительной информации об использовании keytool см.Официальный сайт руководства keytool, есть также статья о SSLShopper, в которой перечисленыОбщие команды keytool.

4.2 Динамическая загрузка сертификатов с помощью KeyStore

Используя keytool для импорта сертификата, этот метод не только прост, но и обеспечивает безопасность кода, самое главное, что код не нужно модифицировать. Поэтому я предпочитаю этот метод. Но у этого метода есть фатальный недостаток, то есть вам нужно изменить файлы в каталоге JRE.Если ваша программа работает только на вашем собственном компьютере, это нормально, но если ваша программа будет развернута на чужих компьютерах Или на сервер компании, и у вас нет прав на изменение файлов в каталоге JRE, что мне делать? Если ваша программа представляет собой распределенную программу для развертывания на сотнях или тысячах машин, нужно ли вам изменять файл JRE на каждой машине? К счастью, у нас есть другой способ добиться этого через программирование, динамическую загрузку кода. Файл KeyStore для завершения проверки сертификата, зная, что это такое, мы также практикуем этот метод в конце концов. Получите более глубокое понимание, написав кодKeyStore,TrustManagerFactory,SSLContextа такжеSSLSocketFactoryотношения между этими классами.

@Test
public void basicHttpsGetUsingSslSocketFactory() throws Exception {
 
    String keyStoreFile = "D:\\code\\ttt.ks";
    String password = "poiuyt";
    KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
    FileInputStream in = new FileInputStream(keyStoreFile);
    ks.load(in, password.toCharArray());
     
    System.out.println(KeyStore.getDefaultType().toString());
    System.out.println(TrustManagerFactory.getDefaultAlgorithm().toString());
     
    TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
    tmf.init(ks);
    SSLContext ctx = SSLContext.getInstance("TLS");
    ctx.init(null, tmf.getTrustManagers(), null);
     
    LayeredConnectionSocketFactory sslSocketFactory = new SSLConnectionSocketFactory(ctx);
     
    String url = "https://ttt.aneasystone.com";
     
    /**
     * Return the page with content:
     *  401 Authorization Required
     */
     
    CloseableHttpClient httpclient = HttpClients.custom()
            .setSSLSocketFactory(sslSocketFactory)
            .build();
     
    HttpGet request = new HttpGet(url);
    request.setHeader("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64) ...");
     
    CloseableHttpResponse response = httpclient.execute(request);
    String responseBody = readResponseBody(response);
    System.out.println(responseBody);
}

В приведенном выше коде используется HttpClient. Если вы используете HttpsURLConnection, вам нужно изменить только следующие две строки:

HttpsURLConnection con = (HttpsURLConnection) obj.openConnection();
con.setSSLSocketFactory(ctx.getSocketFactory());

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

System.setProperty("javax.net.ssl.trustStore", "D:\\code\\ttt.ks");
System.setProperty("javax.net.ssl.trustStorePassword", "poiuyt");

резюме

На этом наше путешествие по HTTPS подходит к концу. В процессе изучения HTTPS меня ненароком коснутся некоторые технологии или приемы в HTTPS, особенно процесс сертификации сертификатов и принцип алгоритма асимметричного шифрования, который действительно аккумулирует бесконечную мудрость человеческих существ. математика. В процессе обучения, чем больше вы добираетесь до сути, тем больше вы выходите из-под контроля.В середине слишком много деталей, а слишком большая глубина заставляет людей бессознательно сбиваться с пути. Этот блог то и дело пишется уже больше месяца.Потихоньку я также немного разбираюсь в HTTPS, и теперь у меня есть первый взгляд на дверь. Чем больше пишу, тем больше понимаю, что многое не понимаю. В этом блоге много справочных материалов, да и качество тоже неравномерное, не могу сказать, как это повлияет на читателей, но мне очень помогло прояснить многие идеи в процессе обучения. Благодаря оригинальным авторам этих блогов здесь. В то же время, если вы обнаружите какие-либо проблемы или ошибки в этом блоге, пожалуйста, исправьте их.

взаимное поощрение.

Ссылаться на

  1. Как работает SSL
  2. Введение и анализ случая использования протокола SSL/TLS
  3. Подробное объяснение принципа SSL/TLS
  4. Подробное объяснение оптимизации рукопожатия TLS
  5. Введение в три метода расшифровки HTTPS-трафика
  6. Графический протокол SSL/TLS
  7. Обзор механизма работы протокола SSL/TLS
  8. HTTPS от принципа к практике
  9. Принцип работы HTTPS и механизм рукопожатия TCP
  10. Грамотность протоколов HTTPS и SSL/TLS
  11. HTTPS эти вещи (1) принцип HTTPS
  12. Понимание протокола HTTPS
  13. Серия SSL/TLS Protocol Security: обзор SSL/TLS
  14. Different types of keystore in Java -- Overview
  15. Different types of keystore in Java -- JKS
  16. Проблема доступа к ссылкам Https с помощью HttpsURLConnection в Java
  17. Where is the certificate folder in Windows 7?
  18. Знакомство с цифровыми сертификатами и ЦС
  19. Принципы цифровых сертификатов
  20. Цифровой сертификат
  21. Java использует самозаверяющий сертификат для доступа к сайту https
  22. 12306 Проблемы с сертификатом
  23. Что такое цифровая подпись?
  24. Зачем мне нужно устанавливать корневой сертификат при покупке билетов на поезд онлайн?
  25. Технология шифрования Java (8) - цифровой сертификат
  26. Технология шифрования Java (9) — предварительное изучение SSL
  27. Распространенные форматы цифровых сертификатов
  28. keyStore vs trustStore
  29. Difference between trustStore and keyStore in Java - SSL
  30. Java Secure Socket Extension (JSSE) Reference Guide
  31. Disable Certificate Validation in Java SSL Connections
  32. javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed
  33. How to solve javax.net.ssl.SSLHandshakeException?
  34. SSL Converter
  35. The Most Common Java Keytool Keystore Commands
  36. keytool - Key and Certificate Management Tool
Отсканируйте QR-код и прочитайте его на своем телефоне!
Категории