Tls offload что это
Описание
Балансировка нагрузки с помощью FortiGate включает в себя все необходимые функции для распределения трафика между несколькими серверами в вашей инфраструктуре, развернутой в Selectel, включая как выделенные аппаратные серверы, так и виртуальные серверы в Облачной платформе Selectel.
FortiGate обеспечивает комплексную защиту вашей инфраструктуры и балансирует нагрузки серверов, распределяя потоки трафика по заданным правилам, что позволяет объединить в одном устройстве функции балансировщика нагрузки, Next Generation Firewall (NGFW) и защиту от угроз.
Балансировка нагрузки на основе решений FortiGate обеспечивает:
Балансировщик нагрузки поддерживает HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL или более низкоуровневые протоколы TCP/UDP или IP. Сохранение сеанса поддерживается на основе идентификатора сеанса SSL или на основе введенного файла cookie HTTP. 
Перед началом работы
Прежде чем настраивать балансировку нагрузки в графическом интерфейсе, включите отображение специального раздела настроек:
В данном примере будут рассмотрены настройки Load Balancing для HTTP и HTTPS на аппаратном FortiGate-100E, первоначальную базовую настройку которого можно провести согласно инструкциям по настройке межсетевых экранов. В качестве серверов используются облачные серверы в Облачной платформе Selectel.
FortiGate и проект в Облачной платформе соединены приватной сетью, для подключения которой используется L3VPN между регионами и услугами, что позволяет устанавливать за межсетевым экраном также выделенные серверы и серверы в Облаке на базе VMware.
Термины и определения
Методы балансировки нагрузки
Трафик может распределяться между серверами на основе методов:
Health Check
Health Check — механизм проверки работоспособности серверов для предотвращения отправки трафика балансировки нагрузки на неработающие серверы. Для проверки используется ICMP ping или другое более сложное тестирование TCP-соединений. Health Check удаляет из кластера балансировки нагрузки неработающие реальные серверы. Удаление реальных серверов из кластеров основано на настройках:
Типы Health Check по протоколам: TCP, HTTP, PING.
Virtual Server
Virtual Server — виртуальный сервер, на чей внешний IP-адрес поступает трафик, который перенаправляется к балансировщику нагрузки.
Real Server
Real Server — действительный, реальный, сервер, на который поступают запросы после балансировки. За каждым виртуальным сервером может быть закреплено несколько реальных серверов. Конфигурация реального сервера включает IP-адрес и номер порта, на котором реальный сервер принимает сеансы. Устройство FortiGate отправляет сеансы на IP-адрес реального сервера, используя номер порта назначения в реальной конфигурации сервера. Конфигурация сервера включает его IP-адрес и номер порта, на котором принимает сеансы.
SSL Offloading
SSL Offloading — механизм ускорения SSL-соединения клиентов с сервером, при котором операции шифрования производятся на FortiGate вместо самих серверов с помощью отдельного специального процессора. Данный механизм можно применить, только если для балансировки нагрузки задан тип одного из протоколов SSL (HTTPS, IMAPS, POP3S, SMTPS, SSL). FortiGate предоставляет возможность выбрать, какие сегменты SSL-соединения будут получать разгрузку SSL, определив режим:
HTTP multiplexing
HTTP multiplexing — функция, которая позволяет веб-клиенту использовать одно соединение TCP для всех запросов к серверу. Данная особенность снижает нагрузку на веб-сервер за счет установки единого соединения, по которому параллельно отправляются запросы и ответы. Каждый фрагмент ассоциируются с помощью специальных встроенных мета-данных, что обеспечивает возможность корректной обработки множества несвязанных запросов HTTP или HTTPS в различном порядке в одном и том же соединении. Более того, ответы получаются по мере их готовности, следовательно, тяжелые запросы не будут блокировать обработку и выдачу более простых объектов.
Например, если веб-браузеры пользователей совместимы только с HTTP 1.0, в котором данная функция не реализована, то включение опции HTTP multiplexing может повысить производительность между веб-сервером и FortiGate.
Persistence
Persistence — параметр, который сохраняет и отслеживает данные сеанса, чтобы убедиться, что пользователь подключается к одному и тому же серверу каждый раз, когда он делает запрос, являющийся частью одного и того же сеанса или последующих сеансов. HTTP cookie persistence использует внедренные файлы cookie для обеспечения сохраняемости.
При настройке Persistence FortiGate балансирует нагрузку нового сеанса на реальный сервер в соответствии с методом балансировки нагрузки. Если у сеанса есть HTTP cookie или идентификатор сеанса SSL, устройство FortiGate отправляет все последующие сеансы с одним и тем же файлом cookie HTTP или идентификатором сеанса SSL на один и тот же реальный сервер.
SSL Offloading: What is it? How does it work? What are the benefits?
What is SSL Offloading? Performing SSL at the Load Balancer level.
Today we’re going to cover a question that comes up from time to time, and may seem especially foreign to people without an IT background: What is SSL offloading? We’ll give a quick overview of what SSL offloading means, why you may want to do it and whether you should.
One of the misnomers about SSL/TLS and really with the way the internet works in general is that it’s a 1:1 connection. A person’s computer connects directly with a web server and communication goes directly from one to the other. In reality, it’s far more complicated than that, with sometimes upwards of a dozen stops between end points.
That’s an important piece of information to keep in mind as we start getting into SSL offloading.
So, what is SSL offloading and how does it work?
What is SSL offloading?
Before TLS 1.3, even before TLS 1.2, frankly, SSL/TLS used to legitimately add latency to connections. That’s what lent itself to the perception that SSL/TLS slowed down websites. Ten years ago, that was the knock on SSL certificates. “Oh they slow down your site.” And that was true at the time.
It’s not today, but in the past SSL/TLS was considered a bit resource hungry. For starters, you have the SSL/TLS handshake. It’s been refined to where it’s now a single roundtrip in TLS 1.3, but before that it took several roundtrips. Then, following the handshake, additional processing power had to be exerted to encrypt and decrypt the data being transmitted. As the additional load from SSL/TLS increases on the server, it’s no longer able to process at full capacity.
Again, a lot of this has been cleaned up in TLS 1.3, and HTTP/2 – which requires the use of SSL/TLS – helps to increase performance even more, but even with all of those improvements, SSL/TLS can still add latency with higher volumes of traffic.
So, what is SSL offloading? Well, to help offset the extra burden SSL/TLS adds, you can spin up separate Application-Specific Integrated Circuit (ASIC) processers that are limited to just performing the functions required for SSL/TLS, namely the handshake and the encryption/decryption. This frees up processing power for the intended application or website. That’s SSL offloading in a nutshell. Sometimes it’s also called load balancing. You may hear the term load balancer tossed around. A load balancer is any device that helps improve the distribution of workloads across multiple resources, for instance distributing the SSL/TLS workload to ASIC processors.
What are the advantages of SSL offloading?
SSL offloading has several benefits:
That last one is one of the most important: that in some cases SSL offloading can assist with traffic inspection. As important as encryption is, it has one major drawback: attackers can hide in your encrypted traffic. There’s no shortage of high-profile exploits that have occurred as a result of attackers hiding in HTTPS traffic, recently Magecart has been using HTTPS traffic to obfuscate the PCI it’s been exfiltrating from various payment pages.
Being able to inspect HTTPS traffic becomes almost compulsory once your organization reaches a certain size, and one of the best ways to do that is to offload your SSL/TLS processes.
How does SSL offloading work?
When we talk about SSL offloading there are two different ways to accomplish it:
Let’s start with SSL termination first because it’s a little bit simpler. Essentially it works this way, the proxy server or load balancer you use for the SSL offloading acts as the SSL terminator, which also acts as an edge device. When a client attempts to connect to a website, the client connects to the SSL terminator—that connection is HTTPS. But the connection between the SSL terminator and the application server is via HTTP.
Now, you may be asking how that doesn’t cause problems with the browser, it’s because the HTTP connection is taking place behind the scenes – on the internal network, protected by firewalls – the client still has a secure connection with the SSL terminator, which is acting as a pass-through.
Here’s a visualization of SSL Termination:
SSL Bridging is extremely similar conceptually, except rather than sending the traffic and requests on via HTTP, it re-encrypts everything before sending it to the application server.
Here’s a visualization of SSL Bridging:
Both allow you to perform traffic inspection and can help tremendously when you’re dealing with high volumes of traffic on larger networks.
Bear in mind, encryption is an incredibly CPU-intensive task. When the industry migrated from 1024-bit RSA keys to 2048-bit ones, the CPU-usage involved increased somewhere between 4-7 times depending on server. We’ll likely never even get to 4096-bit keys because frankly, at that point the increase in cpu-usage isn’t consummate to the improvement in security. That’s why we’re seeing a push towards more elliptic curve-based cryptosystems.
So let’s cover one last item: should you consider SSL offloading?
And frankly, that all comes down to you, your website and what you’re trying to do. A large media site like an ESPN or a CNN would be well-suited to use a load balancer owing to the volume of traffic they both handle. On the other hand, if you’re just running a website for a local bakery, you’d probably be fine just letting your server handle everything—especially with the improvements made by TLS 1.3.
That’s all for today, as always, leave any comments or questions below.
«Как это работает»: знакомство с 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. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.
Основы 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. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!