Tls proxy что это
«Как это работает»: знакомство с SSL/TLS
Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.
Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.
SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.
Цель протокола — обеспечить защищенную передачу данных. При этом для аутентификации используются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Первый тип шифрования более ресурсоемкий, поэтому его комбинация с симметричным алгоритмом помогает сохранить высокую скорость обработки данных.
Рукопожатие
Когда пользователь заходит на веб-сайт, браузер запрашивает информацию о сертификате у сервера, который высылает копию SSL-сертификата с открытым ключом. Далее, браузер проверяет сертификат, название которого должно совпадать с именем веб-сайта.
Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.
Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.
Алгоритмы шифрования
Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.
Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.
Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.
Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.
Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.
DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.
ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.
Более короткий ключ также влияет на время обработки данных, которое заметно сокращается. Этот факт и то, что алгоритм эффективно обрабатывает большое количество подключений, сделали его удобным инструментом для работы с мобильной связью. В SSL-сертификатах можно использовать сразу несколько методов шифрования для большей защиты.
Хеш и MAC
Цель хеш-алгоритма — преобразовывать все содержимое SSL-сертификата в битовую строку фиксированной длины. Для шифрования значения хеша применяется закрытый ключ центра сертификации, который включается в сертификат как подпись.
Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.
В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.
Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.
Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.
Сертификаты бывают разные
Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.
Domain Validation, или сертификаты с проверкой домена, подходят для некоммерческих сайтов, так как они подтверждают только веб-сервер, обслуживающий определенный сайт, на который был осуществлен переход. Этот вид сертификата самый дешевый и популярный, но не может считаться полностью безопасным, так как содержит только информацию о зарегистрированном доменном имени.
Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.
Extended Validation, или сертификат с расширенной проверкой, считается самым надежным. Собственно, зеленый замочек или ярлык в браузере означает как раз то, что у сайта есть именно такой сертификат. О том, как разные браузеры информируют пользователей о наличии сертификата или возникающих ошибках можно почитать тут.
Он нужен веб-сайтам, которые проводят финансовые транзакции и требуют высокий уровень конфиденциальности. Однако многие сайты предпочитают перенаправлять пользователей для совершения платежей на внешние ресурсы, подтвержденные сертификатами с расширенной проверкой, при этом используя сертификаты OV, которых вполне хватает для защиты остальных данных пользователей.
Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.
Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.
Получить SSL-сертификат можно и самостоятельно: пара ключей для этого генерируется через любой генератор, например, бесплатный OpenSSL. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.
Предистория: Попытки заблокировать Telegram происходят в разных странах, первый вариант блокировки был простым — блокировка IP адресов серверов Telegram.
Telegram достаточно успешно отбивается от этой атаки, переодически меняя IP с которых он доступен, однако это вызывает долгий первичный Connecting…
Чуть позднее стали доступны Socks прокси, однако протокол не подразумевает шифрования и это позволяло достаточно просто смотреть «внутрь» socks туннеля определяя, что внутри него — Telegram, блокируя прокси.
Следующим раундом стал — выпуск MTProto Proxy — прокси сервера от Telegram, который использует свой протокол MTProto, однако и он обладал некоторыми проблемами — размер пакетов достаточно характерный и специфичный, и многие DPI начали определять Telegram уже после первого пакета — блокируя доступ.
Ответом на такое поведение стало введение новой версии протокола MTProto — с случайной длиной, теперь определить что перед нами Telegram туннель — сложнее, часть DPI начали классифицировать трафик как «другое» часть все же научились выявлять характерный паттерн и с некоторой вероятностью (не 100%) определять, что трафик относится к Telegram
Стеганогра́фия (от греч. στεγανός «скрытый» + γράφω «пишу»; букв. «тайнопись») — способ передачи или хранения информации с учётом сохранения в тайне самого факта такой передачи (хранения).
Зачем притворяться?
Ответ лежит на поверхности — в нынешнее время, большая часть трафика — TLS (https), при использовании данного протокола вот что увидит ваш провайдер или DPI:
В такой ситуации все нестандартные протоколы начинают привлекать к себе дополнительное внимание и решение этой проблемы — одно — если ты выглядишь как TLS (https) то вопросов становится меньше.
Техническая реализация
При использовании нового протокола, поток MTProto оборачивается в стандартный HTTPS (первые сообщения о согласовании туннеля) в котором идет передача домена (ненастоящего). После согласования протокола MTProto — Fake-TLS не используется, далее трафик начинает ходить привычным нам MTProto протоколом со случайной длинной (dd — ключи).
Справочно: Telegram использует 3 вида ключей для MTProto Proxy:
Где попробовать?
Уже есть два Proxy-сервера, которые поддерживают новый стандарт (официального прокси сервера всё еще нет, хотя он и в прошлый раз достаточно долго добавлял поддержку dd ключей)
Поддерживающие режим Fake TLS Proxy:
Какие клиенты поддерживают новый режим?
Бета версии Telegram Desktop, Telegram iOS и говорят, стабильная версия на Android.
Как попробовать?
Что происходит за кулисами?
Обратите внимание! Коннект будет идти до вашего сервера (IP) а вот в заголовке будет передан домен Google.com
Как уже ранее было сказано — при использовании HTTPS протокола ваш провайдер или DPI может руководствоваться только двумя критериями при блокировке соединения:
Переход прокси на Fake TLS делает его невидимым для вашего провайдера, а если сервер стоит в облаке от, скажем, Google и при согласовании используется какой-то домен Google — тогда и эвистический анализ не поможет, со стороны все будет выглядеть так, как буд-то какой-то сервис Google работает по HTTPS/TLS протоколу.
Минусы есть?
Небольшие, но есть — если мы будем обращатся к прокси используя браузер — соединение ожидаемо не установится (секрета то нет). Со стороны это будет выглядеть, как некорректно настроенный HTTPS сервер. Может ли это быть критерием для блокировки? — нет, сервер може ожидать например личного сертификата или другой информации.
Помимо этого — в будущем можно будет помимо секрета использовать связку секрет+домен (ненастоящий) в качестве поля аутентификации и если к серверу будет обращение с другим доменом — показывать вполне обычный сайт, а вот если с доменом который известен только вам — поднимать туннель MTProto.
Однако это станет возможным только после внедрения eSNI (шифрованного заголовка домена) — сейчас он передается без шифрования.
Конечно есть, на мой взгляд Telegram еще не использовал все средства для скрытия, помимо https/TLS имеет смысл использовать WebSocket для скрытия трафика — это еще сильнее усложнит идентификацию и классификацию трафика.
Заключение
Если у вас есть свой MTProto прокси сервер — изучите новый его стандарт, как только во всех публичных версиях Telegram клиентов он станет доступным — переведите всех пользователей на него.
Да, есть небольшая проблема — придётся обновить строку подключения у всех (секрет) он меняется, однако это позволит повысить успешность скрытия прокси.
Помимо перевода на новый стандарт — стоит перевести прокси на 443 порт (стандартный для HTTPS) и заблокировать не шифрованные подключения (ключи без dd и ee), а после миграции всех на ee вариант и dd ключи в том числе, благо прокси это умеют.
Так же не лишним будет установить перед прокси балансировщик с определением домена и при запросе домена отличного от настроенного в прокси — показывать вполне настоящий сайт, как только будет внедрён стандарт eSNI — это бесплатно для вас усилит защиту.
TLS protocol over proxy: technology advantages and features
Using a proxy server is very convenient when performing a large number of tasks. However, working with this tool sometimes involves some difficulties, the main of which is the lack of an encrypted connection. This flaw forces many users to turn to alternative technologies: VPN, Shadowsocks, Tor, and others. What to do if the project needs proxies? For such cases, you can use the TLS data encryption function.
What is the TLS Protocol?
TLS (Transport Layer Security) is a standard network model protocol that provides a secure connection between a user and a server. It protects the data of users who use a secure https connection to access web pages on the Network. TLS is an updated version of the SSL Protocol. The protocol «runs on top» of TCP connection, but there are no changes at the higher HTTP or SMTP level. But still, there are three functions: encryption of information transmitted from one device to another, authorship verification, and data integrity control to protect against spoofing.
Proxies with TLS encryption and HTTPS proxies
Most HTTP(S) proxies support a secure connection to a dedicated website. At the same time, the SSL or TLS protocols are used to protect users’ data, just like when connecting without a proxy server. However, information about which hosts the client accesses and whether a proxy is used is not disclosed.
TLS encrypted proxies differ from conventional HTTPS counterparts. Encryption of them occurs «on top» of all protocols used to establish a connection. In other words, not only personal data is hidden from prying eyes, but also other connection parameters, such as HTTP headers from the client and the proxy itself. It provides a high level of anonymity that rivals VPN technology while maintaining the convenience and simplicity of proxy servers for users. Setting up a proxy for commonplace use is also different. As a rule, regular browsers do not support the TLS over proxy function. Therefore, to successfully work through a proxy over an encrypted channel, you need to install specialized client applications, such as stunnel (www.stunnel.org). In the proxy settings, you specify port 443 to create a secure tunnel through which all traffic will be transmitted.
Differences between TLS proxy and VPN
A proxy server of this configuration is very similar to a VPN service. Indeed, both VPN and proxies with TLS provide access to external resources through a middleware server and transmit data between the client and server in encrypted form. However, these tools should not be equated. Each of them has its characteristics. VPN is a private network that is organized over a public network to ensure the security of data transmission inside it. This technology is often used both for corporate networks, for example, providing secure access of remote employees to confidential data, and for personal purposes, whether it is getting access to a foreign site or ensuring anonymity on the Internet. If we are only talking about spoofing the IP address and diverting traffic, the best solution is to use an intermediary server. Creating a VPN connection requires more additional operations: encapsulating network packets, assigning fake IP addresses in the VPN network itself, and altering the routing table.
A proxy server is a specialized software that connects to a resource server from its IP address, redirecting requests from the client and responding to them from websites. Since intermediation is the main feature of a proxy, this operation is quick and efficient. Often, the speed of data transmission over a high-quality proxy server does not concede to the speed of direct Internet connection.
Advantages of a proxy server with TLS
Why use a TLS encrypted proxy when you have a VPN? To answer this question, you should look at the advantages of using proxy servers to decide whether this technology is suitable for your range of tasks.
Below we have compiled 5 advantages of TLS encrypted proxy protocols over VPN:
1. High-speed data transfer.
High-speed data transfer. When proxying TCP connections, packets are retransmitted independently in the proxy client and proxy host sections. The proxy has its TCP buffers, and short-term I/O delays in one area will not affect the transmission time in the opposite part. The VPN only works at the network layer, and the computer will transmit lost TCP segments from the VPN client to the target server, which reduces the speed of the VPN;
2. Customization flexibility.
Proxy is convenient and easy to configure on any operating system. You can configure proxies for individual applications or queries to a particular domain, or use different proxies for different addresses;
3. HTTPS traffic disguise.
One of the main advantages of such proxies. TLS encryption runs on top of all network protocols, and the server can pass off all transmitted traffic as ordinary HTTPS packets. It can be useful if someone is using traffic filtering technology to block VPNs and other similar tools. The fact of VPN use is visible to the passive DPI even when using dedicated software. Using TLS over proxy avoids this problem;
4. Protection from an unsecured disconnection.
The VPN connection may be interrupted, the user will not notice that their traffic is no longer protected, so the work continues with his real IP address. If we are talking about a proxy, there are no such problems. If the proxy server goes down, the internet connection is lost, and there is no danger of establishing an unsecured connection;
5. Low access rights demands.
Proxy connection, unlike a VPN, does not require specific permissions from the server or user. What opens up opportunities for ordinary users to use it within corporate and home networks.
Where to find and try servers that support TLS over proxy? They are already available on RSocks! The TLS encryption feature is already available for all Private Personal proxies. Experience all the advantages of this technology!
Stunnel for working with private personal proxies via a TLS tunnel
Private personal proxies by RSocks (private personal proxy) support TLS encryption over proxy protocols.
Standard browsers out of the box do not support traffic tunneling to a proxy server, so to successfully use this feature, you need to work through specialized software. Below we will tell you how to quickly and easily set up a private proxy to work through Stunnel.
Start of operation. Installing Stunnel
To get started, you will need three elements:
You can download Stunnel from the official website
Here you can download installation files for any popular operating system.
Stunnel installation is standard and generally does not differ from other programs in your operating system.
The exception is that during installation, the program will ask you to enter data about your country, region, organization, etc.
You can fill in all these fields randomly if you don’t want to use your data.
Launching and configuring Stunnel
After launching Stunnel, a window with connection logs appears.
The first thing to do is to edit the configuration for working with our proxy.
Select from the menu Configuration → Edit Configuration
After clicking Edit Configuration in a standard text editor, the configuration file opens
The default configuration content looks something like this:
If you want to use multiple proxies, you can link other proxy servers on neighboring ports using similar units in the configuration:
[socks2]
client = yes
# Set another port
accept = 127.0.0.1:8081
# Address of another private personal proxy
connect = 33.***.***.133:443
Next step is to save the configuration file and upload a new config.
Configuration → Reload Configuration
This is the end of the setup. Stunnel is up and running!
Configuring the TLS proxy in the browser
After configuring stunnel, personal proxy servers were linked via an encrypted channel to localhost ports on our computer. Now it is enough to redirect all requests from the browser to localhost ports to work with the proxy.
To do this, go to the browser proxy settings and specify the IP address and localhost port that were used in the stunnel configuration inside the accept parameter.
Save your settings in your browser and get started! Access to private proxy via TLS tunnel is activated!
Authorization, when connecting to a personal proxy server, occurs in normal mode. A window for entering your username and password will appear in the browser, or the proxy server will start working instantly if you selected authorization via the client’s IP address.
When the TLS function is configured, the client and proxy work through an encrypted tunnel. It allows you to disguise all traffic as https packets to avoid blocking even when using dpi (deep packet inspection). It makes our proxies an excellent alternative to VPN services for working in networks where OpenVPN traffic is blocked.
Try it yourself and check the high level of privacy and security when working with a TLS proxy!
Основы HTTPS, TLS, SSL. Создание собственных X.509 сертификатов. Пример настройки TLSv1.2 в Spring Boot
Привет, Хабр! В современном мире абсолютное большинство сайтов используют HTTPS (Google даже снижает рейтинг сайтов работающих по HTTP в поисковой выдаче), а подключение к различным системам происходит по протоколу TLS/SSL. Поэтому любой разработчик рано или поздно сталкивается с этими технологиями на практике. Данная статья призвана помочь разобраться, если вы совершенно не в курсе что это такое и как оно устроено. Мы разберем как работает соединение по протоколу TLS, как выпустить собственные сертификаты и настроем TLS в Spring Boot приложении. Поехали!
Что не так с HTTP?
Симметричное шифрование предполагает наличие общего ключа одновременно у отправителя и получателя, с помощью которого происходит шифровка и дешифровка данных. Данный тип не требователен к ресурсам, однако существенно страдает безопасность из-за опасности кражи ключа злоумышленником.
При использовании ассиметричного шифрования существует открытый ключ, который можно свободно распространять, и закрытый ключ, который держится в секрете у одной из сторон. Этот тип работает медленно, относительно симметричного шифрования, однако скомпрометировать закрытый ключ сложнее.
Что происходит на практике
Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.
Для чего нужен идентификатор сессии? Как мы посмотрим далее, процесс установления TLS соединения затратен по времени и ресурсам. Предусмотрен механизм возобновления соединения с помощью отправки клиентом этого идентификатора. Если сервер тоже все еще хранит соответствующие настройки, то клиент и сервер смогут продолжить общение использую ранее выбранные алгоритмы и ключи.
Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).
Сервер случайно генерирует число 6, передает клиенту числа p = 17, g = 3, Ys = 3 6 mod 17 = 15
Клиент случайно генерирует число 7 и возвращает серверу Yc = 3 7 mod 17 = 11
Сервер считает итоговое число 11 6 mod 17= 8, и клиент 15 7 mod 17 = 8
После этого соединение считается установленным, и происходит передача полезной информации
Двусторонний TLS
Двусторонний TLS или Two Way TLS или mutual TLS (mTLS) означает проверку сертификата клиента. Сервер после своего сообщения Certificate посылает запрос сертификата клиента CertificateRequest. Клиент в ответ отправляет Certificate, сервер производит проверку, аналогичную проверке сертификата сервера клиентом. Далее настройка TLS происходит в описанном выше порядке.
TLSv1.3
Стоит отметить, что все выше написанное относится к TLSv1.2, которая начинает понемногу устаревать. В 2018 году была разработана новая версия 1.3 в которой: были запрещены уже ненадежные алгоритмы, ускорен процесс соединения, переработан протокол рукопожатия и др. Интернет медленно но верно обновляется до TLSv1.3, однако все еще большинство сайтов работают по протоколу TLSv1.2. Поэтому информация в этой статье остается актуальной.
Выпускаем собственные сертификаты
Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем «password» длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:
Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:
Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.
Теперь у нас есть сертификат, которому в будущем будут доверять наши клиент и сервер. Похожим образом сделаем приватные ключи и запросы на подпись сертификата для них:
После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем «password»:
Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:
Для удобства, все описанные выше действия упакованы в bash script.
Настройка TLS в Spring Boot приложении
Основой для нашего проекта послужит шаблон с https://start.spring.io/ с одной лишь зависимостью Spring Web. Для включения TLS указываем в application.properties:
После этого указываем Spring тип keystore, путь к нему и пароль:
Для проверки доступа создадим минимальный контроллер:
Запускаем проект. Попробуем сделать запрос с помощью curl:
На этот раз все сработало, TLS в Spring Boot работает! Мы на этом не остановимся, добавим в приложение аутентификацию клиента (указываем truststore):
Запускаем и снова пытаемся выполнить запрос:
Очевидно, что сервер закрыл соединение, так как curl не предоставил никакого сертификата. Дополним запрос клиентским сертификатом и его закрытым ключом:
Итоги
В данной статье мы разобрались как работает протокол TLS и для чего он нужен. На практике научились создавать собственные сертификаты и использовать их в Java приложении на Spring Boot. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!