Основы TLS (Transport Layer Security)

Что такое TLS

TLS — это криптографический протокол, обеспечивающий сквозную защиту данных, пересылаемых между приложениями через Интернет. Он в основном знаком пользователям благодаря его использованию в безопасном просмотре веб-страниц и, в частности, значку замка, который появляется в веб-браузерах при установлении безопасного сеанса. Однако его можно и даже нужно использовать для других приложений, таких как электронная почта, передача файлов, видео/аудио-конференции, обмен мгновенными сообщениями и передача голоса по IP, а также интернет-службы, такие, как DNS и NTP.

TLS произошёл от Secure Socket Layers (SSL), первоначально разработанном в Netscape Communication Corporation в 1994 году для защиты веб-сеансов. SSL 1.0 никогда не выпускался публично, в то время как SSL 2.0 был быстро заменён SSL 3.0, на котором основан TLS.

TLS был впервые указан в RFC 2246 в 1999 году как протокол, независимый от приложения, и, хотя он не имел прямого взаимодействия с SSL 3.0, при необходимости предлагал резервный режим. Однако в настоящее время SSL 3.0 считается небезопасным и объявлен устаревшим в соответствии с RFC 7568 в июне 2015 года с рекомендацией использовать TLS 1.2. TLS 1.3 описанный в августе 2018 года в RFC 8446 прекратил поддержку менее безопасных алгоритмов.

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

TLS обычно реализуется поверх TCP для шифрования протоколов прикладного уровня, таких как HTTP, FTP, SMTP и IMAP, хотя он также может быть реализован на UDP, DCCP и SCTP (например для приложений на основе VPN и SIP). Это известно как протокол дейтаграмм безопасности транспортного уровня DTLS и указано в RFC 6347, 5238 и 6083.

Зачем нужен TLS

Исторически данные передавались через Интернет в незашифрованном виде, и там, где использовалось шифрование, оно обычно применялось по частям для конфиденциальной информации, такой как пароли или платёжные реквизиты. Хотя ещё в 1996 году (в RFC 1984) было признано, что рост Интернета потребует защиты личных данных, за прошедший период стало всё более очевидным, что возможности перехватчиков и злоумышленников больше и более распространены, чем считалось ранее. Поэтому в ноябре 2014 года IAB опубликовали заявление, призывающее разработчиков и операторов протоколов сделать шифрование нормой для интернет-трафика, что, по сути, означает сделать его конфиденциальным по умолчанию.

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

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

Поэтому рекомендуется, чтобы все клиенты и серверы настаивали на обязательном использовании TLS в своих коммуникациях и, желательно, самой последней версии TLS 1.2 (на момент перевода статьи TLS 1.3). Для полной безопасности необходимо использовать его в сочетании с общедоступной инфраструктурой открытых ключей X.509 (PKI) и, желательно, с DNSSEC, чтобы аутентифицировать, что система, с которой устанавливается соединение, действительно является тем, на что она претендует быть.

Как работает TLS

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

При симметричной криптографии данные шифруются и расшифровываются с помощью секретного ключа, известного как отправителю, так и получателю; обычно 128 бит, но предпочтительнее 256 бит (всё, что меньше 80 бит, теперь считается небезопасным). Симметричная криптография эффективна с точки зрения вычислений, но наличие общего секретного ключа означает необходимость безопасного обмена им.

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

Преимущество асимметричной криптографии заключается в том, что процесс обмена ключами шифрования необязательно должен быть безопасным, но математическая связь между открытым и закрытым ключами означает, что требуются гораздо большие размеры ключей. Рекомендуемая минимальная длина ключа составляет 1024 бита, предпочтительнее 2048 бит, но это в тысячу раз больше вычислительной мощности, чем симметричные ключи эквивалентной силы (например, 2048-битный асимметричный ключ приблизительно эквивалентен 112-битному симметричному ключу) и делает асимметричное шифрование слишком медленным для многих целей.

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

Можно использовать множество различных методов генерации и обмена ключами, включая RSA, Diffie-Hellman (DH), Ephemeral Diffie-Hellman (DHE), Elliptic Curve Diffie-Hellman (ECDH) и Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). DHE и ECDHE также обеспечивают прямую секретность, благодаря чему сеансовый ключ не будет скомпрометирован, если один из закрытых ключей будет получен в будущем, хотя предполагается, что слабая генерация случайных чисел и/или использование ограниченного диапазона простых чисел позволяют взломать даже 1024-битные ключи DH на уровне состояния вычислительных ресурсов. Однако их можно считать проблемами реализации, а не протокола, и существуют инструменты для тестирования более слабых наборов шифров.

При использовании TLS также желательно, чтобы клиент, подключающийся к серверу, мог подтвердить право собственности на открытый ключ сервера. Обычно это выполняется с использованием цифрового сертификата X.509, выданного доверенной третьей стороной, известной как Центр Сертификации CA, который подтверждает подлинность открытого ключа. В некоторых случаях сервер может использовать самозаверяющий сертификат, которому клиент должен явно доверять (браузеры должны отображать предупреждение при обнаружении ненадёжного сертификата), но это может быть приемлемо в частных сетях и/или там, где возможно безопасное распространение сертификатов.

Что такое CA

Certificate Authority (CA) — это организация, которая выдаёт цифровые сертификаты, соответствующие стандарту ITU-T’s X.509 для инфраструктур открытых ключей (PKIs). Цифровые сертификаты удостоверяют открытый ключ владельца сертификата (известный как субъект) и то, что владелец контролирует домен, защищённый сертификатом. Таким образом, CA действует как доверенная третья сторона, которая даёт клиентам (известным как проверяющие стороны) уверенность в том, что они подключаются к серверу, управляемому проверенной организацией.

Сами сертификаты конечного объекта проверяются через цепочку доверия, начинающуюся с корневого сертификата, также известную как якорь доверия. С помощью ассиметричной криптографии можно использовать закрытый ключ корневого сертификата для подписи других сертификатов, которые затем могут быть проверены с использованием открытого ключа корневого сертификата и, следовательно, унаследовать доверие выдавшего CA. На практике сертификаты конечного объекта обычно подписываются одним или несколькими промежуточными сертификатами (иногда называемыми подчинёнными или подчинёнными CA), поскольку это защищает корневой сертификат в случае неправильного выпуска или компрометации сертификата конечного объекта.

Доверие к корневым сертификатам обычно устанавливается путём физического распространения корневых сертификатов в операционных системах или браузерах. Основные программы сертификации проводятся Microsoft (Windows), Apple (OSX и iOS) и Mozilla (Firefox и Linux) и требуют, чтобы CA соответствовали строгим техническим требованиям и заполняли WebTrust, ETSI EN 319 411-3 (ранее TS 102 042) или аудит ISO 21188:2006 для включения в их дистрибутивы. WebTrust — это программа, разработанная Американским институтом сертифицированных бухгалтеров и Канадским институтом дипломированных бухгалтеров, ETSI — Европейским институтом стандартов в области телекоммуникаций, а ISO — Международной организацией по стандартизации.

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

Однако также возможно создать частые центры сертификации и установить доверие посредством безопасного распространения и установки корневых сертификатов в клиентских системах. Примеры включают центры сертификации RPKI, управляемые региональными интернет-регистраторами (AfriNIC, APNIC, ARIN, LACNIC and RIPE NCC), которые выдают сертификаты локальным интернет-реестрам, подтверждающим IP-адреса и номер AS, которыми они владеют; а также International Grid Trust Federation (IGTF), которая обеспечивает якорь доверия для выдачи серверных и клиентских сертификатов, используемых машинами в распределённых научных вычислениях. В этих случаях корневые сертификаты можно безопасно загрузить и установить с сайтов с помощью сертификата выданного общедоступным доверенным CA.

Одним из недостатков системы PKI X.509 является то, что третьи лица (CA) могут выдавать сертификаты для любого домена, независимо от того, действительно ли запрашивающий объект владеет им или иным образом контролирует его. Проверка обычно выполняется посредством проверки домена, а именно отправкой электронного письма со ссылкой для проверки подлинности на адрес, который, как известно, несёт административную ответственность за домен. Обычно это один из стандартных контактных адресов, таких как hostmaster@domain или технический контакт указанный в базе данных WHOIS, но это оставляет себя открытым для атак человек посередине на протоколы DNS или BGP, или, проще говоря, пользователи, регистрирующие административные адреса в доменах, которые не были зарезервированы. Возможно, что ещё более важно, сертификаты с проверкой домена Domain Validated (DV) не утверждают, что домен имеет какие-либо отношения с юридическим лицом, даже если может показаться, что домен является таковым.

По этой причине центры сертификации всё чаще поощряют использование сертификатов с проверкой организации Organisation Validated (OV) и расширенной проверкой Extended Validation (EV). С сертификатами OV запрашивающий объект подвергается дополнительным проверкам, таким как подтверждение названия организации, адреса и номера телефона с использованием общедоступных баз данных. С сертификатом EV проводятся дополнительные проверки юридического учреждения, физического местонахождения и личности лиц, намеревающихся действовать от имени запрашивающей организации.

Конечно, это по-прежнему не предотвращает случайную или мошенническую выдачу центрами сертификации неправильных сертификатов, а также были случаи нарушения безопасности, когда центры сертификации обманом выдавали поддельные сертификаты. Несмотря на существенное ужесточение процедур безопасности после нескольких громких инцидентов, система по-прежнему зависит от доверия третьих сторон, что привело к разработке протокола DNS-based Authentication of Named Entities (DANE), как указано в RFC 6698, 7671, 7672 и 7673.

С помощью DANE администратор домена может сертифицировать свои открытые ключи, сохраняя их в DNS или альтернативно указывая, какие сертификаты должен принимать клиент. Это требует использования DNSSEC, который криптографически подтверждает доверенность записей DNS, хотя DNSSEC ещё не получил широкого распространения, а основные браузеры в настоящее время требуют установки надстройки для поддержки DANE. Кроме того, DNSSEC и DANE по-прежнему будут требовать проверки владельцев доменов, которую, скорее всего, должны будут выполнять реестры доменов и/или регистраторы, а не центры сертификации.