Основные различия между mtls и tls

Аутентификация в рукопожатии TLS 1.2

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

С другой стороны, если Диффи-Хеллман не выполняет аутентификацию, то что он делает? Как было сказано выше, DH часто используют совместно с криптографией на основе эллиптических кривых, чтобы обеспечить аутентификацию и обмен ключами.

Эллиптическая криптография (ECC) имеет гораздо меньшие размеры ключей, которые соответствуют эллиптической кривой, на которой они основаны. Для этого контекста есть пять подходящих кривых:

192 бит;
224 бита;
256 бит;
384 бит;
521 бит.

Но это не единственное различие между открытыми/закрытыми ключами ECC и ключами RSA. Они используются для двух совершенно разных целей во время рукопожатия TLS.

В RSA пара открытый/закрытый ключ используется как для проверки подлинности сервера, так и для обмена симметричным ключом сеанса. Фактически, именно успешное использование секретного ключа для расшифровки секрета (pre-master secret) аутентифицирует сервер.

С Диффи-Хеллманом пара открытый/закрытый ключ НЕ используется для обмена симметричным сеансовым ключом. Когда задействован Диффи-Хеллман, закрытый ключ фактически связан с прилагаемым алгоритмом подписи (ECDSA или RSA).

RSA-аутентификация

Процесс RSA-аутентификации связан с процессом обмена ключами. Точнее обмен ключами является частью процесса аутентификации.

Когда клиенту предоставляется SSL-сертификат сервера, он проверяет несколько показателей:

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

Если все эти проверки прошли, то проводится последний тест — клиент шифрует pre-master secret с помощью открытого ключа сервера и отправляет его. Любой сервер может попытаться выдать любой SSL/TLS-сертификат за свой. В конце концов, это общедоступные сертификаты. А так клиент может провести аутентификацию сервера, увидев закрытый ключ «в действии».

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

DH-аутентификация

Когда используются Диффи-Хеллман и ECDSA/RSA, аутентификация и обмен ключами разворачиваются бок о бок. И это возвращает нас к ключам и вариантам их использования. Открытый/закрытый ключ RSA используется как для обмена ключами, так и для аутентификации. В DH + ECDSA/RSA асимметричная пара ключей используется только для этапа цифровой подписи или аутентификации.

Когда клиент получает сертификат, он всё ещё проводит стандартные проверки:

проверяет подпись на сертификате,
цепочку сертификатов,
срок действия,
статус отзыва.

Но владение закрытым ключом подтверждается по-другому. Во время обмена ключами TLS-рукопожатия (шаг 4) сервер использует свой закрытый ключ для шифрования случайного числа клиента и сервера, а также свой DH-параметр. Он действует как цифровая подпись сервера, и клиент может использовать связанный открытый ключ для проверки, что сервер является законным владельцем пары ключей.

В чём разница между SSL и TLS

Если вы уже читали нашу статью про SSL, то наверняка заметили, что между двумя протоколами много общего: оба шифруют данные, оба используют секретные ключи, оба создают защищённые сессии. Так в чём же разница? Чтобы в этом разобраться, погрузимся ненадолго в историю.

Протокол SSL разработала компания Netscape в середине 1990-х, чтобы улучшить свой браузер Navigator (олды помнят). Для своей эпохи SSL был вполне хорош, но со временем в его безопасности нашлись серьёзные бреши. Одной из самых критичных стала небезопасная проверка паддинга.

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

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

Чтобы лучше понять, как это работает, представьте, что вы пытаетесь угадать чей-то пароль. Но вместо обычного «пароль неверный» система говорит вам ещё и о том, что он слишком длинный или в нём нет каких-то символов. Тем самым система помогает хакеру сузить количество вариантов «паролей».

Изображение: Skillbox Media

Исправить эту уязвимость одними обновлениями было невозможно — она была связана с самим дизайном SSL, а не конкретными реализациями. Именно из-за подобных проблем, а также из-за банкротства Netscape, разработка перешла в так называемый Инженерный совет интернета — IETF. Там протокол улучшили, исправили косяки безопасности и выпустили под новым названием — TLS.

Новый протокол обзавёлся более совершенными механизмами шифрования и аутентификации, а также проверкой добавленных блоков. Да, атаку с неправильным паддингом стало провернуть не так-то просто:

Изображение: Skillbox Media

Что такое TLS

TLS, или transport layer security, — это протокол, который защищает данные во время их передачи по Сети. Он работает на четвёртом, транспортном, уровне сетевой модели OSI, где отвечает за создание безопасных сессий обмена данными между браузером и сервером.

Изначально TLS использовали в основном для соединения со страницами оплаты — однако сейчас он работает почти на каждом уважающем себя сайте. Понять, что сайт использует TLS, легко: если его адрес начинается с https, а рядом красуется символ замочка — значит, ваши данные защищены.

Аббревиатура HTTPS означает, что сайт использует защищённую версию протокола HTTP — Hypertext Transfer Protocol Secure. По сути, это и есть обычный HTTP, только нашпигованный средствами защиты, за которые как раз и отвечает TLS.

Скриншот: Skillbox Media

Чтобы понять, как работает TLS, проведём аналогию с фильмом «Чёрная пантера». Если помните, у вакандийцев есть два характерных атрибута коммуникации. Во-первых, это фирменные приветствия со скрещёнными на груди руками, которые позволяют им узнавать друг друга. А во-вторых, конечно, вакандийский язык, понятный в основном жителям этой страны.

То же самое и с компьютерами. Когда вы заходите на сайт, защищённый TLS, ваш браузер и сервер сначала жмут друг другу руки: устанавливают соединение, обмениваются секретными ключами и выбирают алгоритмы шифрования. А потом начинают общение на загадочном языке, понятном только им.

Основные различия между Mtls и Tls

MTLS (mutual Transport Layer Security) и TLS (Transport Layer Security) — это протоколы шифрования, которые обеспечивают безопасность связи между клиентом и сервером в интернете. Они позволяют защищать данные, передаваемые между узлами сети, от несанкционированного доступа и подделки.

Определение и работа

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

MTLS — это усовершенствованная версия TLS, в которой и клиент и сервер аутентифицируют друг друга. Он использует сертификаты для подтверждения подлинности обоих узлов и обеспечивает двустороннюю аутентификацию.

Аутентификация

Основное отличие между MTLS и TLS заключается в способе аутентификации.

В TLS только сервер аутентифицирует клиента путем проверки его сертификата. Клиент может быть уверен, что он общается с правильным сервером, но сервер не получает информацию о клиенте.
В MTLS оба узла — клиент и сервер — аутентифицируют друг друга. При этом каждый узел предоставляет свой сертификат для подтверждения своей подлинности.

Цель

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

MTLS имеет дополнительную цель — обеспечить двустороннюю аутентификацию между клиентом и сервером. Он позволяет обеим сторонам проверить подлинность идентификатора друг друга и установить доверие между ними.

Применение

Так как MTLS предоставляет более высокий уровень безопасности, он широко используется в приложениях, где требуется надежная аутентификация. Например, в системах банковского или медицинского характера.

TLS, с другой стороны, используется в большинстве веб-серверов и браузеров для обеспечения безопасного соединения по протоколу HTTPS.

Why is mTLS Important?

Using mTLS is vital to ensuring two-way authentication between servers or services on a network. It helps minimize the chances of data transferred between each party from being intercepted.

More Secure Communication With Third-Party Clients

Authenticating internal requests using mTLS comes with relative certainty that each party in the transaction is valid. However, what happens when you introduce an external client? The confidence level that they can be trusted decreases. Using mTLS helps you be more confident in providing access to those external requests.

Less Reliant on Insecure Static Login Methods

Static login methods are more administrative intensive. You must stay on top of changing the password regularly, monitoring its usage, and making sure it is properly protected.

More Difficult for a Hacker to Impersonate a Remote API Call

Credentials used in this method are still susceptible to being compromised. However, the complexity requires more sophisticated skills to impersonate an authentication attempt.

Uses Fewer Network Resources

Using mTLS means your APIs talk directly to one another. As a result, you won’t need to use a network tunnel to communicate.

Certificate, Public/Private Keys: Must know concepts about mTLS

Certificates

A (digital) certificate is a small computer file issued by a certificate authority (CA) to authenticate a user, an application, or an organization. A digital certificate contains information such as- the name of the certificate holder, serial number of the certificate, expiry date, public key, and signature of the certificate issuing authority.

Certificate Authority (CA)

A certificate authority (CA) is a trusted 3rd party that verifies user identity and issues an encrypted digital certificate containing the applicant’s public key and other information. Notable CAs are VeriSign, Entrust, LetsEncrypt, Safescript Limited, etc.

Root CA/ Certificate Chain

Certificate Authority hierarchies are created to distribute the workloads of issuing certificates. There can be entities issuing certificates from different CA at various levels. In the multi-level hierarchy (like parent and child) of CAs, there is one CA at the top, called the Root CA (refer the below image). Each CA would also have its certificate issued by the parent CA, and the root CA will have self-signed certificates.

To ensure the CA (which issued the certificate to the client/server) is trusted, the security protocol suggests that entities send their digital certificate and the entire chain leading up to the root CA.

Public and Private Key Pair

While creating certificates for an entity, the CA would generate a public and a private key- commonly called a public key pair. The public and private keys are used to authenticate their identity and encrypt data. Public keys are published, but the private key is kept secret. If you are interested to learn about the algorithms to generate public keys- RSA, DSA, ECDSA, ).

X.509 Certificate

It is a special category of the certificate, defined by the International Telecommunications Union, which binds an application’s identity (hostname, organization name, etc.) to a public key using a digital signature. It is the most commonly used certificate in all the security protocols SSL/TLS/mTLS for securing web applications.

Обмен ключами RSA

Называть это обменом ключами RSA на самом деле неправильно. На самом деле это RSA-шифрование. RSA использует асимметричное шифрование для создания ключа сеанса. В отличие от DH, пара открытого/закрытого ключей играет большую роль.

Вот как это происходит:

Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
Клиент генерирует pre-master secret (a), а затем использует открытый ключ сервера для его шифрования и отправки на сервер.
Сервер расшифровывает pre-master secret с помощью соответствующего закрытого ключа. Теперь обе стороны имеют все три входных переменных и смешивают их с некоторыми псевдослучайными функциями (PRF) для создания мастер-ключа.
Обе стороны смешивают мастер-ключ с ещё большим количеством PRF и получают совпадающие сеансовые ключи.

Обмен ключами DH

Вот как работает ECDH:

Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
Одна сторона выбирает секретный номер, называемый pre-master secret (a), и вычисляет: xa mod y. Затем отправляет результат (A) другому участнику.
Другая сторона делает то же самое, выбирая свой собственный pre-master secret (b) и вычисляет xb mod y, а затем отправляет обратно своё значение (B).
Обе стороны заканчивают эту часть, принимая заданные значения и повторяя операцию. Один вычисляет ba mod y, другой вычисляет ab mod y.

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

Рукопожатие TLS 1.2 для DH

Теперь, когда мы узнали, чем DH отличается от RSA, посмотрим, как выглядит рукопожатие TLS 1.2 на основе DH.

Опять же, между этими двумя подходами существует множество сходств. Мы будем использовать ECDHE для обмена ключами и ECDSA для аутентификации.

Как и в случае с RSA, клиент начинает с сообщения «Client Hello», которое включает в себя список шифронаборов, а также случайное число клиента.
Сервер отвечает своим сообщением «Server Hello», которое включает в себя выбранный шифронабор и случайное число сервера.
Сервер отправляет свой SSL-сертификат. Как и при TLS-рукопожатии RSA клиент выполнит серию проверок подлинности сертификата, но, поскольку сам DH не может аутентифицировать сервер, необходим дополнительный механизм.
Чтобы провести аутентификацию, сервер берёт случайные числа клиента и сервера, а также параметр DH, который будет использоваться для вычисления сеансового ключа, и шифрует их с помощью своего закрытого ключа. Результат будет выполнять роль цифровой подписи: клиент использует открытый ключ для проверки подписи и того, что сервер является законным владельцем пары ключей, и ответит своим собственным параметром DH.
Сервер завершает эту фазу сообщением «Server Hello Done».
В отличие от RSA, клиенту не нужно отправлять pre-master secret на сервер с использованием асимметричного шифрования, вместо этого клиент и сервер используют параметры DH, которыми они обменялись ранее, чтобы получить pre-master secret. Затем каждый использует pre-master secret, который он только что рассчитал, для получения одинакового сеансового ключа.
Клиент отправляет сообщение «Change Cipher Spec», чтобы сообщить другой стороне о своём переходе на шифрование.
Клиент отправляет финальное сообщение «Finished», чтобы сообщить, что он завершил свою часть рукопожатия.
Аналогично, сервер отправляет сообщение «Change Cipher Spec».
Рукопожатие завершается сообщением «Finished» от сервера.

Принцип работы TLS

TLS (Transport Layer Security) является криптографическим протоколом, который обеспечивает защищенное соединение между клиентом и сервером. Основной принцип работы TLS заключается в том, что он создает защищенный туннель между двумя узлами сети, который позволяет им обмениваться данными, не подвергая информацию риску перехвата или изменения.

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

Для защиты данных TLS использует различные алгоритмы шифрования, такие как AES (Advanced Encryption Standard) и RSA (Rivest-Shamir-Adleman). Кроме того, TLS обеспечивает аутентификацию, что позволяет клиенту и серверу быть уверенными в том, что они оба доверяют друг другу.

Важно отметить, что TLS не только обеспечивает конфиденциальность и аутентификацию данных, но и защищает от атак на подделку или изменение передаваемых данных. Он также обеспечивает целостность данных, что означает, что данные не могут быть изменены в процессе передачи без обнаружения

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

Certificate Management

Tyk provides you with two options to manage certificates: plain files or certificate storage with a separate API.

All configuration options, which require specifying certificates, support both plain file paths or certificate IDs. You are able to mix them up, and Tyk will automatically distinguish file names from certificate IDs.

The Tyk Gateway and Dashboard Admin APIs provide endpoints to create, remove, list, and see information about certificates. For the Gateway, the endpoints are:

Create: with PEM body. Returns
Delete:
Get info: . Return meta info about certificate, something similar to:

Get info about multiple certificates: .
Returns array of meta info objects, similar to above.
List all certificate IDs:

The Dashboard Admin API is very similar, except for a few minor differences:

Endpoints start with instead of , e.g. , , etc.
All certificates are managed in the context of the organisation. In other words, certificates are not shared between organisations.

Certificate storage uses a hex encoded certificate SHA256 fingerprint as its ID. When used with the Dashboard API, Tyk additionally appends the organisation id to the certificate fingerprint. It means that certificate IDs are predictable, and you can check certificates by their IDs by manually
generating certificate SHA256 fingerprint using the following command:

You may notice that you can’t get the raw certificate back, only its meta information. This is to ensure security. Certificates with private keys have special treatment and are encoded before storing. If a private key is found it will be encrypted with AES256 algorithm 3 using the secret, defined in file. Otherwise, the certificate will use the value in .

MDCB

Mutual TLS configuration in an MDCB environment has specific requirements. An MDCB environment usually consists of a management environment and slaves who, using MDCB, sync configuration.
The Management and slave environments usually do not share any secrets; thus a certificate with private keys encoded with secret in management Gateway will not be accessible to slaves.

To solve this issue, you need set in the MDCB configuration file to the same value as specified in your management Gateway configuration file. By knowing the original secret, MDCB will be able to decode private keys, and
send them to client without password. Using secure connection between slave Gateways and MDCB is required in this case. See MDCB setup page for use_ssl usage.

Связь без mTLS по-прежнему важна

При переносе рабочих нагрузок в сервисную сетку может потребоваться убедиться, что связь без mTLS разрешена. Не для всех сервисов, которые вы создаете, будет включен mTLS. Строго включив mTLS в вашей сервисной сетке, пространстве имен или приложении, вы рискуете сломать свое приложение. Вероятно, это такая же большая проблема, как нарушение безопасности. Другой сценарий, в котором вам может потребоваться включить связь без mTLS, — это когда вы хотите, чтобы ваши службы взаимодействовали с внешними службами, отличными от mTLS. Поскольку рабочие нагрузки, основанные на микросервисах, имеют тенденцию становиться довольно сложными, у вас могут возникнуть трудности с определением места возникновения проблемы.

Популярный инструмент Service Mesh Istio поставляется с тремя различными настройками для mTLS:

Строгий: разрешает только связь mTLS.
Отключено: разрешено только взаимодействие без mTLS.

Istio по умолчанию включает разрешающий режим на всех своих прокси. Это лучший способ, если вы только начинаете миграционный путь. Разрешающий режим не является безопасным, поскольку мошеннические микросервисы все еще могут взаимодействовать с вашими критически важными сервисами. Однако поначалу вашим приоритетом должно быть обеспечение того, чтобы ваши рабочие нагрузки не прерывались. Затем вы можете постепенно реализовать строгую настройку в зависимости от того, как взаимодействуют сервисы.

How Do I Implement mTLS?

The Hard Part of mTLS: Proving Identity

While mTLS offers significant security advantages, it offers some implementation challenges, not least of which is establishing a secure mechanism for services to prove their identity to each other.

For regular TLS, it used to be hard to manage the certificates that prove the identity of a server to its clients. With the advent of Let’s Encrypt and the ACME protocol, that’s now much easier. However, managing service identity and certificates in a dynamic (and mostly private) environment like Kubernetes is harder because there are many ephemeral services that need strong, provable identities, but can’t practically use a public ACME service.

Rolling your own automated certificate management system is impractical and risky. Getting mTLS certificate management right is hard and the consequences of getting it wrong are bad. You need a trusted, proven way to do it. A service mesh is purpose-built to provide the infrastructure you need to safely and securely implement mTLS between services.

Use a Service Mesh, the NIST Standard for Microservices Security

In its standards for microservices security, the National Institute of Standards and Technology (NIST) recommends using a service mesh as a dedicated infrastructure layer to provide core network security features. One of those core features is strong service identity and certificate management to support mTLS. And, Istio—the most widely used service mesh—gives you mTLS support out of the box. Istio transparently provides the infrastructure—including secure naming, strong service identity, and certificate management—for secure communications between your Kubernetes workloads as well as for connections to and from the outside world.

If you want the details of NIST’s standards for microservices security and how Tetrate helps meet them, check out Tetrate’s Guide to Federal Security Requirements for Microservices.

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это ):

cert.pem — это сертификат SSL/TLS;
key.pem — это ключ к сертификату.

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

Ещё пример, когда такое решение пригодится — на CloudFlare, настроенном на Flexible SSL, плагин Broken Link Checker при сканировании выдаёт ошибки доступа к изображениям . И тут тоже помогут самоподписанные сертификаты на 443 порту сайта.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

Допустим, самоподписанные сертификаты сгенерированы командой выше и располагаются в каталоге . Тогда, чтобы настроить редирект с HTTPS на HTTP для нового сайта , мы можем использовать следующую конфигурацию ( заменяем на свой домен, — на свой IP сервера):

server {
 server_name example.com   www.example.com;
 listen 1.2.3.4:443 ssl; ### Вместо 1.2.3.4 нужно подставить IP сервера

 ssl_certificate /root/cert.pem; # Путь к самоподписанному сгенерированному сертификату
 ssl_certificate_key /root/key.pem; # Путь к ключу самоподписанного сертификата

 rewrite ^(.*) http://$host$1 permanent; 
}

server {
    server_name example.com   www.example.com;
    listen 1.2.3.4:80 ; ### Вместо 1.2.3.4 нужно подставить IP сервера

    ### Остальные правила ###
}

Производительность

Одним из важных факторов при выборе между MTLS и TLS является производительность системы. В данном разделе рассмотрим основные различия между MTLS и TLS в контексте производительности.

MTLS

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

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

Также следует учитывать, что MTLS может потребовать дополнительных вычислительных ресурсов для обработки шифрования и расшифрования данных, что может негативно сказываться на производительности системы.

TLS

В отличие от MTLS, TLS (Transport Layer Security) обеспечивает меньший уровень безопасности, но может быть более производительным. Это связано с тем, что процесс аутентификации при использовании TLS требует меньше ресурсов, чем MTLS.

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

Также следует отметить, что TLS может быть более производительным в плане вычислений. Поскольку TLS обычно использует шифрование симметричных ключей, которые требуют меньше вычислительной мощности, чем шифрование с асимметричными ключами, которое часто используется в MTLS.

Таким образом, при выборе между MTLS и TLS следует учитывать компромисс между уровнем безопасности и производительностью системы.

Chapter 2: “Follow the chain, where does it lead you?”

In large systems, servers may not store all root and intermediate certificates locally, but use external storage instead. RFC 4387 explains the concept of a certificate store: an interface you can use to lazily access certificates during chain validation. These stores are implemented over different protocols, such as HTTP, LDAP, FTP, or SQL queries.

some X.509 certificate extensions that can contain information about where to find the issuer and CA certificates. For instance, the Authority Information Access (AIA) extension contains a URL pointing to the Issuer’s certificate. If this extension is used for validation, there is a high chance that you can exploit it to perform an SSRF attack. Also, Subject, Issuer, Serial, and their alternative names can be used to construct SQL or LDAP queries, creating opportunities for injection attacks.

When certificate stores are in use, you should think of these values as “untrusted user input” or “Insertion points,” similar to those we have in Burp Suite’s Intruder. And what attackers will really love is that all of these values can be used in queries before the signature is checked.

Example: CVE-2023-33201 LDAP injection in Bouncy Castle

To demonstrate an example of this vulnerability, we’ll use LDAPCertStore from the Bouncy Castle library. Bouncy Castle is one of the most popular libraries for certificate validation in Java. Here is an example of how you can use this store to build and validate a certificate chain.

Under the hood, Bouncy Castle uses the Subject field from the certificate to build an LDAP query. The Subject field is inserted in the filter, without—you guessed it—any escaping.

So, if the Subject contains any special characters, it can change the syntax of the query. In most cases, this can be exploited as a blind ldap query injection. Therefore, it might be possible to use this vulnerability to extract other fields from the LDAP directory. The exploitability depends on many factors, including whether the application exposes any errors or not, and it also depends on the structure of the LDAP directory.

In general, whenever you incorporate user-supplied data into an LDAP query, special characters should be properly filtered. That’s exactly how this CVE has been patched in the Bouncy Castle code.

How MTLS improves security

While MTLS isn’t a one-stop-shop for all of your application’s security needs, it provides a level of protection against some attack vectors like:

Man-in-the-middle attacks: Here, an attacker could impersonate the server while communicating with the client (or impersonate the client while communicating with the server). With MTLS, the attacker needs to have to get both a fake server certificate that is trusted by the client and a fake client certificate that is trusted by the server. This is much harder as opposed to regular TLS where they only need to control one end of the communication.
Impersonation attacks (Phishing and Credential Stuffing): In cases where an attacker already has the client credentials (e.g via phishing or leaked passwords), they still need to obtain a legitimate certificate to be successful.
Replay attacks: This is a variation of the man-in-the-middle attack where TCP requests are intercepted and maliciously resent (or replayed). MTLS mitigates this by ensuring that requests with no valid certificate associated with it won’t be successful.