Posted:
Июн 16, 2023
Comments:
0 Comments

Tls безопасность: Что такое протокол безопасности TLS

Что такое протокол безопасности TLS

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

В 1995 году был внедрён SSL (англ. Secure Sockets Layer) — криптографический протокол, обеспечивающий безопасную связь между пользователем и сервером. Благодаря его работе можно было безопасно передавать информацию или обмениваться данными. Однако в 2014 году в его работе обнаружили уязвимости. И на основе SSL 3.0 был разработан новый стандарт — TLS.

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

  • отвечает за конфиденциальность передаваемых от компьютера к компьютеру данных,
  • проводит аутентификацию,
  • следит за целостностью передаваемой информации.

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

Защита данных c SSL

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

Заказать

TLS-протокол лежит в основе безопасного обмена информацией, но не обеспечивает его сам по себе. Чтобы защищённое соединение состоялось, нужно настроить одно из безопасных интернет-соединений, например — FTP (для передачи и загрузки файлов), IMAP/POP3/SMTP (для почтовых протоколов) и HTTPS (для интернет-страниц).

HTTPS — самый известный протокол безопасного соединения, который защищает данные на уровне браузера.




Однако, чтобы сайт заработал по безопасному соединению HTTPS, нужно выбрать и установить для сайта SSL-сертификат. Подробнее об этом читайте в статье Что такое протокол https и принципы его работы и Что такое secure sockets layer и как работает SSL.

Параметры безопасности протокола TLS

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

Протокол TLS обеспечивает защиту в три этапа:

  • Handshake,
  • False Start,
  • Chain of trust.

На этапе TLS Handshake (рукопожатие) происходит согласование параметров соединения (версии протокола, способа шифрования и соединения) между клиентом и сервером. Для этого используется обмен ключами по алгоритму RSA:




Для каждой такой проверки требуется большое количество вычислительных ресурсов. Чтобы не устанавливать новое соединение и не проверять сертификат повторно каждую транзакцию, была разработана процедура TLS False Start.

TLS False Start (фальстарт) — процедура возобновления сессии. Если транзакции выполняются в пределах одной запущенной сессии, данный этап позволяет пропустить процедуру Handshake. Протокол повторно использует те данные, которые уже были обработаны и подтверждены в начале сессии. При этом каждая сессия имеет свой срок жизни. Как только срок сессии истекает, с помощью TLS Handshake запускается новая сессия.

Также обязательная процедура TLS-соединения — TLS Chain of trust (цепочка доверия). Она отвечает за аутентификацию между клиентом и сервером. «Цепочка доверия» работает на основе регулярной проверки подлинности — соответствия сертификатов стандартам Сертификационных центров, которые их выдают. Подлинность сертификата регулярно проверяется в течение сессии. Если обнаружится, что сертификат скомпрометирован (то есть данные под его защитой были перехвачены), данные будут отозваны, транзакция не состоится и сессия будет прервана.

Таким образом, при передаче данных сначала вызывается процедура Handshake или False Start, которая согласовывает параметры, а затем Chain of trust, которая обеспечивает аутентификацию (проверку авторства передаваемой информации). Подробнее о принципах работы TLS читайте в официальной документации Datatracker.

Влияние SSL/TLS на SEO

SEO (Search Engine Optimization, поисковая оптимизация) – это всестороннее развитие и продвижение сайта для его выхода на первые позиции в результатах выдачи поисковых систем (SERPs). Поисковая оптимизация способствует увеличению посещаемости сайта.

Использование SSL-сертификата влияет на SEO-показатели, однако это влияние является скорее косвенным. С 2015 года Google отдаёт приоритет ранжирования (то есть назначения сайту места в поисковой выдаче) тем сайтам, которые работают по протоколу HTTPS. Такой же политики придерживается компании Яндекс и Mozilla.

Браузер Google Chrome — один из самых популярных браузеров в рунете. С недавнего времени Chrome отмечает HTTP-сайты как небезопасные:




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

Установка SSL/TLS

В компании REG.RU вы можете приобрести SSL-сертификат, который работает по TLS версии 1.2. Для этого выберите подходящий сертификат и выполните три шага — закажите, активируйте и установите его на сайт.

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

Проверка сайта на SSL/TLS

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

Рассмотрим вариант проверки сайта с помощью сервиса SSL Server Test. Для этого:

  1. org/HowToStep»>
    1.

    В браузере перейдите на страницу SSL Server Test.



  2. 2.

    В поле «Hostname» введите домен и нажмите Submit:






  3. 3.

    Дождитесь окончания проверки. В блоке «Configuration» вы увидите протоколы, которые поддерживает сайт:





Такой результат показывает, что сайт работает по безопасному подключению TLS версии 1.2. Если в результатах выдачи вы увидите «Yes» напротив пунктов SSL 2 или 3 — значит сайту нельзя доверять.

Помогла ли вам статья?

Да

раз уже помогла

Что такое TLS / Хабр

Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.

Общие сведения о TLS


Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.


Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:

После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.

Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.

Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).

 

Шифрование, аутентификация и целостность


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

  • Шифрование – сокрытие информации, передаваемой от одного компьютера к другому;

  • Аутентификация – проверка авторства передаваемой информации;

  • Целостность – обнаружение подмены информации подделкой.


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

Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, который предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).

Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.

Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.

 

TLS Handshake


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

Разберём подробнее каждый шаг данной процедуры:

  1. Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.

  2. После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).

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

  4. Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.

  5. Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.

  6. Клиент расшифровывает полученное сообщение, сверяет MAC, и если всё хорошо, то соединение считается установленным и начинается обмен данными приложений.


Ясно, что установление соединения TLS является, вообще говоря, длительным и трудоёмким процессом, поэтому в стандарте TLS есть несколько оптимизаций. В частности, имеется процедура под названием “abbreviated handshake”, которая позволяет использовать ранее согласованные параметры для восстановления соединения (естественно, если клиент и сервер устанавливали TLS-соединение в прошлом). Данную процедура рассмотрена подробнее в пункте «Возобновление сессии».

Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.

 

Обмен ключами в протоколе TLS


По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.

На текущий момент, все браузеры при установке соединения TLS отдают предпочтение именно сочетанию алгоритма Диффи-Хеллмана и использованию временных ключей для повышения безопасности соединения.

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

 

Возобновление сессии TLS


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

Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.

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

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

Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.

 

TLS False Start


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

Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:

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

 

TLS Chain of trust


Аутентификация является неотъемлемой частью каждого TLS соединения. Рассмотрим простейший процесс аутентификации между Алисой и Бобом:

  1. И Алиса, и Боб генерируют собственные открытые и закрытые ключи.

  2. Алиса и Боб обмениваются открытыми ключами.

  3. Алиса генерирует сообщение, шифрует его своим закрытым ключом и отправляет Бобу.

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


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

Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:

Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).

В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.

Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:

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

Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.

Здесь очевидно присутствует некоторая техническая нерациональность: для проверки лишь одного сертификата требуется запрашивать весь список отозванных сертификатов, что влечёт замедление работы. Для борьбы с этим был разработан механизм под названием «Протокол статусов сертификатов» (OCSP – Online Certificate Status Protocol). Он позволяет осуществлять проверку статуса сертификата динамически. Естественно, это снижает нагрузку на пропускную способность сети, но в то же время порождает несколько проблем:

  • Центры сертификации должны справляться с нагрузкой в режиме реального времени;

  • Центры сертификации должны гарантировать свою доступность в любое время;

  • Из-за запросов реального времени центры сертификации получают информацию о том, какие сайты посещал каждый конкретный пользователь.


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

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

Что такое TLS и как он работает?

Transport Layer Security (TLS) шифрует данные, отправляемые через Интернет, чтобы гарантировать, что перехватчики и хакеры не смогут увидеть, что вы передаете, что особенно полезно для частной и конфиденциальной информации, такой как пароли, номера кредитных карт и личная переписка. На этой странице объясняется, что такое TLS, как он работает и почему его следует развертывать.

Что такое TLS?

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

TLS произошел от Secure Socket Layers (SSL), который был первоначально разработан Netscape Communications 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 также в настоящее время (по состоянию на декабрь 2015 г.) находится в разработке и прекратит поддержку менее безопасных алгоритмов.

Следует отметить, что 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 по умолчанию. Однако использование TLS для электронной почты и некоторых других приложений по-прежнему часто не является обязательным, и, в отличие от веб-браузеров, предоставляющих визуальные подсказки, пользователям не всегда очевидно, зашифрованы ли их соединения.

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

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

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

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

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

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

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

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

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

Что такое ЦС?

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

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

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

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

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

Одним из недостатков системы PKI X.509 является то, что третьи стороны (ЦС) могут выдавать сертификаты для любого домена, независимо от того, действительно ли запрашивающий объект владеет им или иным образом контролирует его. Проверка обычно выполняется посредством проверки домена, а именно отправки электронного письма со ссылкой для проверки подлинности на адрес, который, как известно, несет административную ответственность за домен. Обычно это один из стандартных контактных адресов, таких как «[email protected]», или технический контакт, указанный в базе данных WHOIS, но это оставляет себя открытым для атак «человек посередине» на протоколы DNS или BGP или, проще говоря, , пользователи, регистрирующие административные адреса в доменах, которые не были зарезервированы. Возможно, что еще более важно, сертификаты с проверкой домена (DV) не утверждают, что домен имеет какие-либо отношения с юридическим лицом, даже если может показаться, что домен таковым является.

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

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

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

404: Страница не найдена

Безопасность

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

Что я могу сделать сейчас?

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

Поиск

  • Узнайте последние новости.
  • Наша домашняя страница содержит самую свежую информацию об информационной безопасности.
  • Наша страница «О нас» содержит дополнительную информацию о сайте, на котором вы находитесь, «Безопасность».
  • Если вам нужно, свяжитесь с нами, мы будем рады услышать от вас.

Поиск по категории

Сеть


  • 9 способов заставить модернизацию сети работать

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


  • SONiC NOS сталкивается с проблемами, связанными с мейнстримом

    По оценкам Gartner, менее 200 предприятий используют SONiC из потенциального рынка ЦОД в 100 000 предприятий. Один…


  • 12 распространенных сетевых протоколов и объяснение их функций

    Работа в сети заставляет Интернет работать, но ни один из них не может быть успешным без протоколов. Общие сетевые протоколы и их функции …

ИТ-директор


  • FTC предупреждает бизнес об использовании биометрической информации

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


  • 3 совета по стратегии управления корпоративными данными

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


  • Как один ИТ-директор способствует трансформации бизнеса с помощью технологий

    Том Пек, CIDO в Sysco, делится ценными мыслями о ключевой роли, которую ИТ-директора играют в качестве движущей силы трансформации при управлении …

Корпоративный настольный компьютер


  • Что включает в себя новый Microsoft Intune Suite?

    Учитывая все недавние изменения названий продуктов и надстроек Microsoft для управления конечными точками, ИТ-специалистам необходимо знать, что такое Intune…


  • Нужен ли macOS сторонний антивирус на предприятии?
    Компьютеры Mac

    известны своей безопасностью, но это не означает, что они защищены от вирусов и других угроз. ИТ-команды могут изучить …


  • Устройства, которые работают только с Microsoft Teams, в нашем будущем?

    Microsoft Teams постоянно росла и добавляла новые функции, так что же дальше с этой многофункциональной платформой? Может быть …

Облачные вычисления


  • 3 правила адаптации политик управления изменениями в облаке

    Наличие политики управления изменениями может свести к минимуму риск внесения изменений. Следуйте этим правилам, чтобы адаптироваться к изменениям в облаке…


  • Как создать виртуальную машину Google Cloud Spot

    Виртуальная машина Google Cloud Spot может помочь вам воспользоваться скидками, но вы должны быть осторожны, чтобы не запускать на ней определенные приложения. Узнать…


  • Google удваивает генеративный ИИ

    На Google I/O 2023 Пол Нашавати из Enterprise Strategy Group комментирует улучшения ИИ в поиске Google, фотографиях, картах и ​​.

    This entry was posted in Популярное