TLS( Transport Layer Security)

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

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 25.04.2022
Размер файла 866,9 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Оглавление

ВВЕДЕНИЕ

ОСНОВНАЯ ЧАСТЬ

ЦЕЛЬ ПРОТОКОЛА TLS

ПРИНЦИП РАБОТЫ TLS. TLS HANDSHAKE

ПРИНЦИП РАБОТЫ TLS. TLS RECORD

TLS-СЕРТИФИКАТЫ. СТАНДАРТ X.509

АЛГОРИТМЫ, ИСПОЛЬЗУЮЩИЕСЯ В TLS

АУТЕНТИФИЦИРОВАННОЕ ШИФРОВАНИЕ СО СВЯЗАННЫМИ ДАННЫМИ (AEAD)

КЛЮЧЕВЫЕ ОТЛИЧИЯ SSL И TLS

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

ВВЕДЕНИЕ

Протокол TLS (Transport Layer Security) является одним из наиболее популярных протоколов, предназначенных для установления защищенного канала связи в сети Интернет. Он основан на спецификации протокола SSL (Secure Sockets Layer) версии 3.0, но за время своего существования претерпел довольно много изменений. Самой актуальной версией протокола на текущий момент является версия TLS 1.3, однако версия TLS 1.2 все еще остается наиболее распространенной.

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

Одним из самых распространённых применений TLS является HTTPS. HTTPS стремительно вытесняет незащищённую версию (HTTP): доля зашифрованного веб-трафика растёт, скорее всего, в скором будущем весь веб-трафик будет зашифрован. В новой версии HTTP/2 защита информации средствами TLS должна использоваться по умолчанию. Также по протоколу TLS могут защищаться соединения по FTP, IMAP, POP3 и SMTP и т.д. Благодаря такому положению дел, TLS - один из самых изученных, исследованных протоколов современного Интернета.

Типичная сессия TLS-соединения состоит из следующих шагов:

· Handshake. Аутентификация сервера. Аутентификация клиента, создание и согласование сессионных ключей, предназначенных для кодирования данных.

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

· В ходе сессии могут происходить повторные handshake-соединения.

· В случае разрыва соединения автоматически производится закрытие сессии.

ОСНОВНАЯ ЧАСТЬ

Цель протокола TLS

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

Предполагается, что TLS работает поверх существующего между узлами "потокового" соединения (с которым обычно связан "сокет" - откуда старое название SSL, Secure Sockets Layer). Сейчас, в большинстве случаев, TLS будет работать поверх TCP (рис.1). Именно TCP отвечает за установление соединения, разбивку данных на пакеты, гарантированную доставку этих пакетов (при наличии соединения, естественно) и за разные другие телекоммуникационные моменты. TLS предполагает, что между узлами установлено надёжное соединение, поэтому, например, протокол не охватывает повторную отправку потерянных пакетов данных.

Рис.1. Место TLS в стеке протоколов Интернета

TLS использует установленный канал связи для передачи TLS-сообщений, одного из базовых "строительных блоков" протокола. Эти сообщения кардинальным образом отличаются от пакетов данных (IP-пакетов в TCP/IP) и представляют собой структуру более высокого уровня. TCP позволяет надёжно обмениваться данными, но содержимое пакетов (за исключением специальных случаев) может быть легко прочитано кем-то, кто имеет доступ к каналу связи. Хуже того, этот кто-то может заменить пакеты или изменить передаваемые в них данные. Именно для защиты от этих угроз и используется TLS.

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

1) обеспечить конфиденциальность, то есть реализовать защиту от утечек передаваемой информации;

2) обеспечить обнаружение подмены, то есть реализовать сохранение целостности передаваемой информации;

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

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

Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:

· Безопасность: симметричное шифрование защищает передаваемую информацию от прочтения посторонними лицами.

· Аутентификация: "личность" участника соединения можно проверить с помощью асимметричного шифрования.

· Целостность: каждое сообщение содержит код (Message Authentication Code, MAC), с помощью которого можно проверить, что данные не были изменены или потеряны в процессе передачи.

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

TLS использует концепцию клиент-сервер, которая, в логике данного протокола, во многом совпадает с логикой клиент-сервер TCP: например, и там, и там соединение инициирует клиент. Протокол TLS делится на два слоя: TLS Record и TLS Handshake.

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

Рис.2. Схема TLS Handshake

В HTTPS рукопожатие TLS происходит после завершения успешного рукопожатия TCP. Шаги процедуры TLS Handshake можно разделить на три этапа:

I. Клиент посылает сообщение ClientHello, состоящее из:

1. Открытый ключ клиента key_share, полученный по протоколу Диффи-Хеллмана или идентификаторы секретных ключей pre_shared_key, если используется шифрование по заранее заданному секретному ключу, известному обоим узлам сети; pre_shared_key содержит список идентификаторов симметричных ключей, известных клиенту.

2. Предполагаемый режим обмена секретными ключами psk_key_exchange_modes;

3. Модель алгоритма цифровой подписи signature_algorithms, которая указывает алгоритмы подписи, которые может принять клиент. Также может быть добавлено расширение «signature_algorithms_cert», чтобы указать алгоритмы подписи, специфичные для сертификата.

II. Сервер отвечает следующими сообщениями:

1. Ответная часть открытого ключа key_share или выбранный идентификатор секретного ключа pre_shared_key;

2. Серверное сообщение EncryptedExtensions для передачи в зашифрованном виде дополнения, включающие в себя параметры тонкой настройки;

3. При необходимости аутентификации, серверное сообщение CertificateRequest для получения клиентского сертификата;

4. Сертификат сервера Certificate

5. Сообщение Certificate_verify, которое содержит цифровой сертификат сервера;

6. Сообщение о завершении процедуры рукопожатия Finished

III. Клиент проверяет сертификат сервера, генерирует итоговый секретный ключ (в случае выбора данного способа генерации) и отправляет сообщения:

1. Сообщение о завершении процедуры рукопожатия Finished (формальная отправка для подтверждения);

2. В случае запроса клиентского сертификата отправляет свой сертификат Certificate;

3. Зашифрованное сообщение (с этого момента происходит шифрование данных).

При этом аутентификация может быть полностью исключена (анонимный режим), однако типичный сценарий использования подразумевает аутентификацию, по крайней мере, сервера клиентом. При этом, в TLS 1.3 сервер может перейти к отправке данных полезной нагрузки (Application Data на схеме) непосредственно после серверного Finished - это возможно потому, что к этому моменту сервером уже получен первый набор симметричных ключей.

Если клиент не предоставил валидный открытый ключ, сервер сообщает о несоответствие с помощью HelloRetryRequest, и клиенту необходимо перезапустить рукопожатие уже с валидным «key_share», как показано на рисунке 3. Если невозможно согласовать общие криптографические параметры, сервер должен прервать рукопожатие с соответствующим предупреждением.

Рис.3. Схема полного TLS рукопожатия с несовпадающими параметрами

Полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных. После завершения рукопожатия сервер может отправить клиенту идентификатор PSK(Pre-Shared Key), который соответствует уникальному ключу, полученному из начального рукопожатия. Затем клиент может использовать этот идентификатор PSK в будущих рукопожатиях для согласования использования связанного PSK. Если сервер принимает PSK, тогда контекст безопасности нового соединения криптографически привязывается к исходному соединению, а ключ, полученный из начального рукопожатия, используется для начальной загрузки криптографического состояния вместо полного рукопожатия.

На рисунке 4 показана пара рукопожатий, в которых первое рукопожатие устанавливает PSK, а второе рукопожатие использует его:

Рис.4. Схема возобновления TLS-соединения

Поскольку сервер аутентифицируется через PSK, он не отправляет сертификат или сообщение CertificateVerify. Когда клиент предлагает возобновление через PSK, ему следует также предоставлять серверу расширение «key_share», чтобы позволить серверу отклонить возобновление и вернуться к полному рукопожатию, если это необходимо. Сервер отвечает расширением «pre_shared_key», чтобы договориться об использовании установления ключа PSK, и может (как показано здесь) ответить расширением «key_share», чтобы выполнить установление ключа по протоколу Диффи-Хеллмана, тем самым обеспечивая прямую секретность.

Последовательность возобновления TLS соединения:

I. После предыдущего рукопожатия:

S(сервер) -> C(клиент): новый сеансовый тикет: тикет представляет собой PSK идентификатор и информацию о его сроке службы. Сервер может послать несколько тикетов при первом подключении.

II. Следующее рукопожатие

1) С->S: сообщение Client Hello

Сообщение ClientHello содержит:

· Список PSK идентификаторов (тикетов) предыдущего рукопожатия

· Режим обмена PSK ключом

· Открытый ключ Д-Ф, если сервер решит произвести полное рукопожатие

2) S->С: сообщение ServerHello

Сообщение ClientHello содержит:

· Выбранный PSK или открытый ключ Д-Ф, если сервер решит произвести полное рукопожатие

· ServerFinish - MAC всего рукопожатия

3) C->S: сообщение ClientFinish - MAC всего рукопожатия

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

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

· Разбиение исходящих сообщений на блоки нужного размера и "склеивание" входящих сообщений.

· Сжатие исходящих сообщений и распаковку входящих (используется не всегда).

· Применение кода аутентификации к исходящим сообщениям и проверку входящих с помощью MAC.

· Шифрование исходящих сообщений и дешифровку входящих.

· После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.

Cостав записи:

· Content type: тип сообщения -- подтверждение связи (22), обычное сообщение (23) или оповещение (21).

· Version: версия TLS.

· Length: длина оставшейся части сообщения.

· Payload: собственно зашифрованные данные.

· MAC: код аутентификации.

· Padding: "отступ" для получения нужного размера сообщения.

Рис.5. Состав записи

Код аутентификации сообщения - важнейший элемент защиты информации в TLS. В версиях до 1.3 обычно используется HMAC, с той или иной хеш-функцией. Современная версия TLS 1.3 использует шифры только в режиме аутентифицированного шифрования (а именно - AEAD). Этот режим не нуждается в отдельном MAC, так как целостность данных гарантирует сам алгоритм шифрования (более подробно в «Алгоритмы, использующиеся в TLS»).

TLS-сертификаты. Стандарт X.509

TLS-сертификаты (SSL-сертификаты - устаревшее название, являющееся синонимом) играют важную роль в современной инфраструктуре TLS. У TLS-сертификата одно предназначение: привязать открытый ключ к некоторому сетевому имени. Например, сопоставить ключ 0xA3VEF7...DA3107 имени example.com. TLS-сертификаты не содержат никакой секретной информации. Они не являются непосредственными носителями ключей шифрования передаваемых данных в TLS.

Открытый ключ, который содержится в сертификате, принадлежит искомому серверу, с которым клиент планирует установить соединение. Однако открытый ключ может быть подменён третьей стороной на другой, имитирующий легитимный ключ сервера. Для того, чтобы можно было обнаружить подобную подмену, служит инфраструктура удостоверяющих центров, которая даёт клиенту механизм проверки принадлежности ключа. То есть клиент соглашается верить некоторой третьей стороне (не злоумышленнику, а удостоверяющему центру - УЦ), что эта третья сторона проверила соответствие ключа и сетевого имени (в вебе это обычно домен). Результат такой проверки подтверждается подписью УЦ, которую он ставит на сертификате сервера. Для подписи сейчас используются криптосистемы RSA (повсеместно) и ECDSA (поддержка этой криптосистемы до сих пор ограничена - соответствующие сертификаты доступны не у всех УЦ).

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

В SSL/TLS используются сертификаты формата X.509, это очень старый формат, изначально разрабатывавшийся для телеграфа, но позже адаптированный для использования в Интернете, в частности, в вебе.

Сертификат представляет собой электронный документ, имеющий определённую спецификацией структуру. Так, каждый сертификат содержит поля Issuer и Subject. Поле Issuer определяет имя стороны, выпустившей данный сертификат (поставившей на нём подпись), а поле Subject - имя стороны, для которой сертификат выпущен. В случае веба, в Issuer обычно указано имя из сертификата УЦ (не обязательно корневого), а в Subject, для серверного сертификата, - доменное имя, адресующее сайт.

Клиент получает сертификаты (в большинстве случаев - это цепочка, но может быть и единственный серверный сертификат) в сообщении Certificate, выстраивает их в последовательность, где каждый сертификат удостоверяет следующий, проверяет подписи и соответствие имени из серверного сертификата имени сервера, с которым планирует установить соединение. Проверка имени является важнейшим аспектом, так как злоумышленник может выпустить доверенный сертификат для своего имени сервера, но предъявлять его под именем другого сервера (перехватив сеанс тем или иным способом). В таком случае, полностью валидный сертификат злоумышленника будет отличаться от легитимного только указанным именем и ключом. Например, сертификат выпущен для example.com, а предъявляется для test.ru. (Такое несоответствие также является одной из самых распространённых ошибок настройки TLS-серверов.)

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

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

Основные современные претензии к TLS-сертификатам касаются сложившейся административной структуры УЦ. Так, пока что никакая распространённая технология не мешает УЦ выпустить "подменный" сертификат, позволяющий прозрачно перехватывать TLS-соединения, используя атаку типа "человек посередине". Но такие технологии разрабатываются и успешно внедряются, к ним относится инициатива Certificate Transparency (поддерживаемая Google), Certificate Pinning или Public Key Pinning, когда в браузерах сохраняются (и обновляются) заведомо корректные для данного узла сертификаты или открытые ключи, а также технология DANE, использующая DNS в качестве дополнительной системы контроля.

Алгоритмы, использующиеся в TLS

В версии TLS 1.3 набор шифров (Cipher Suites) был существенно уменьшен по сравнению с версией TLS 1.2 и принадлежит классу шифров AEAD. Данные наборы регистрируются и хранятся в специальном реестре TLS IANA, в котором присваивается уникальный идентификационные номер. Из-за этого у протокола версии 1.3 отсутствует обратная совместимость с более ранними версиями даже при использовании одинаковых наборов шифров.

В текущей версии протокола доступны следующие алгоритмы:

· для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр, проверка подписи сертификатов), Diffie-Hellman (безопасный обмен ключами), Diffie-Hellman на эллиптических кривых

· для симметричного шифрования передаваемых данных: AES и CHACHA20;

· для хеш-функций: SHA-256/384.

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

· TLS_AES_128_CCM_SHA256

· TLS_AES_256_GCM_SHA384

· TLS_AES_128_GCM_SHA256

· TLS_CHACHA20_POLY1305_SHA256

· TLS_AES_128_CCM_8_SHA256

протокол безопасная передача данные

Рис.6. Расшифровка названий криптонаборов доступных в TLS

В TLS 1.3 шифры служат как раз тому, что известно под именованием AEAD (аутентифицированное шифрование с присоединёнными данными). Это означает, что они делают сразу несколько вещей одновременно:

· Шифруют данные с помощью ключа. Это сохраняет конфиденциальность данных, то есть гарантирует, что никто кроме владельца ключа не сможет их прочесть.

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

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

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

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

Аутентифицированное шифрование со связанными данными (AEAD)

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

Первый шаг -- шифрование. Текстовое сообщение проходит через алгоритм симметричного шифрования. Этот алгоритм шифрования также принимает в качестве входных данных общий секретный ключ и одноразовый код, выбранный случайным образом (nonce) или вектор инициализации (IV). Он вернет зашифрованное сообщение.

Второй шаг -- аутентификация. Незашифрованное сообщение, секретный ключ и nonce становятся входными данными для алгоритма MAC. Этот MAC алгоритм ведёт себя как криптографическая хеш-функция, на выходе получается MAC или код аутентификации сообщения. Теперь этот MAC будет прикреплен к зашифрованному сообщению и окончательный результат отправляется второму участнику.

Из-за этого этот MAC называется тегом аутентификации. В TLS 1.3, кроме зашифрованного сообщения, мы также хотим аутентифицировать некоторые связанные данные, такие как адреса, порты, версия протокола или номер последовательности. Эта информация не зашифрована и известна обеим сторонам. Таким образом, связанные данные также являются входными параметрами для алгоритма MAC, и из-за этого весь процесс называется аутентифицированным шифрованием со связанными данными, или, сокращенно, AEAD.

Чтобы проверить, что зашифрованное сообщение не было изменено во время передачи можно просто выполнить алгоритм в обратном порядке. Имея зашифрованное сообщение с MAC, расшифровываем его и отделяем MAC. Затем незашифрованное сообщение отправляется в алгоритм MAC вместе с общим секретным ключом и nonce, которые использовались при шифровании. Обычно nonce добавляется к зашифрованному сообщению перед отправкой получателю. Связанные данные также поступают в алгоритм MAC, и на выходе будет другой MAC. В конце сравниваем два значения MAC. Если они разные, то зашифрованное сообщение было изменено.

Ключевые отличия SSL и TLS

* SSL имеет много ошибок и уязвим для известных атак, чем TLS. В последних версиях TLS было исправлено большинство ошибок, поэтому он невосприимчив к атакам.

* TLS имеет новые функции и поддерживает новые алгоритмы по сравнению с SSL.

* После атаки POODLE использование SSL стало очень уязвимым, и в новых версиях веб-браузеров SSL будет отключен по умолчанию. Однако во всех браузерах TLS включен по умолчанию.

* TLS поддерживает новые наборы алгоритмов аутентификации и обмена ключами, такие как ECDH-RSA, ECDH-ECDSA, PSK и SRP.

* Наборы алгоритмов кода аутентификации сообщений, такие как HMAC-SHA256 / 384 и AEAD, доступны в последних версиях TLS, но не в SSL.

* SSL был разработан и отредактирован под Netscape. Однако TLS находится в ведении Инженерной группы Интернета в качестве стандартного протокола и, следовательно, доступен в соответствии с RFC.

* Существуют различия в реализации протокола, например, в обмене ключами и получении ключей.

Заключение

TLS - это современный протокол безопасной передачи данных по небезопасной сети, который пришел на смену SSL, который уже не рекомендуется к использованию. TLS активно развивается, последняя версия 1.3 вышла в марте 2018 года. Протокол активно работает со многими процессами сетевого взаимодействия: передачей файлов, VPN-подключением (в некоторых реализациях для обмена ключами), службами обмена мгновенными сообщениями или IP-телефонией.

В TLS используется гибридное шифрование:

· Симметричное шифрование для передачи данных

· Ассиметричное шифрование для обмена ключами

Было сокращено количество криптонаборов до 5, самых безопасных, что убрало путаницу и упростило настройку протокола. Алгоритм RSA был исключен из списка алгоритмов для обмена ключами симметричного шифрования, что позволило достичь совершенной прямой секретности (Perfect Forward Secrecy, PFS).

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

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

Список используемых источников

1. Александр Венедюхин, Ключи, шифры, сообщения: как работает TLS [Электронный ресурс] https://tls.dxdt.ru/tls.html

2. David Wong, A Readable Specification of TLS 1.3 [Электронный ресурс] https://www.davidwong.fr/tls13/

3. SSL/TLS [Электронный ресурс]

https://neerc.ifmo.ru/wiki/index.php?title=SSL/TLS

4. Заметки по выбору шифров TLS 1.3[Электронный ресурс]

https://itnan.ru/post.php?c=1&p=554070

5. Варвара Николаева, Что такое TLS-рукопожатие и как оно устроено [Электронный ресурс] https://tproger.ru/articles/tls-handshake-explained/

6. Что такое TLS [Электронный ресурс] https://habr.com/ru/post/258285/

Размещено на Allbest.ru

...

Подобные документы

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

    курсовая работа [779,8 K], добавлен 15.04.2012

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

    дипломная работа [802,6 K], добавлен 28.09.2015

  • Механизм создания и обмена пакетами в сети передачи информации на основе стека протоколов ZigBee. Принцип действия, особенности работы и коммутации с другими протоколами, определение основных методов и способов защиты информации, передаваемой в сети.

    курсовая работа [2,6 M], добавлен 12.09.2012

  • Особенности организации передачи данных в компьютерной сети. Эталонная модель взаимодействия открытых систем. Методы передачи данных на нижнем уровне, доступа к передающей среде. Анализ протоколов передачи данных нижнего уровня на примере стека TCP/IP.

    курсовая работа [1,0 M], добавлен 07.08.2011

  • Монтаж и прокладывание локальной сети 10 Base T. Общая схема подключений. Сферы применение компьютерных сетей. Протоколы передачи информации. Используемые в сети топологии. Способы передачи данных. Характеристика основного программного обеспечения.

    курсовая работа [640,0 K], добавлен 25.04.2015

  • Описание основных типов станций протокола HDLC. Нормальный, асинхронный и сбалансированный режимы работы станции в состоянии передачи информации. Методы управления потоком данных. Формат и содержание информационного и управляющего полей протокола HDLC.

    лабораторная работа [77,1 K], добавлен 02.10.2013

  • История создания и развития сети Internet. Дейтаграммный принцип передачи пакетов. Принцип работы виртуального канала. Начало официального распространения IP-доступа и WWW-технологий. Разработка нового протокола – HTTP. Этапы развития Интернет в России.

    презентация [6,1 M], добавлен 13.12.2013

  • Понятие, особенности и уровни промышленных сетей. Сравнение протоколов передачи данных HART, Industrial Ethernet, Foundation Filedbus, CAN, Modbus, их достоинства и недостатки. Физический и канальный уровни сети Profibus. Распределение функций управления.

    презентация [812,9 K], добавлен 29.11.2013

  • Создание информационной сети Интернет и электронной почты. Процесс и протокол передачи гипертекста. Программа просмотра интернет-страниц. Использование новейшей технологии DSL. Скорость передачи данных. Беспроводные сети с использованием радиоканалов.

    реферат [22,0 K], добавлен 22.04.2011

  • Технология построения сетей передачи данных. Правила алгоритма CSMA/CD для передающей станции. Анализ существующей сети передачи данных предприятия "Минские тепловые сети". Построение сети на основе технологии Fast Ethernet для административного здания.

    дипломная работа [2,5 M], добавлен 15.02.2013

  • Компоненты технологий, направленных на обеспечение безопасности данных. Аутентификация (с авторизацией), сохранение целостности данных, активная проверка установленной политики безопасности. Версии приложений и принцип работы сервера защиты TACACS.

    курсовая работа [144,7 K], добавлен 16.01.2010

  • Центральные магистрали передачи данных. Улучшение параметров мультисервисной сети за счет использования имитационного моделирования. Сети с трансляцией ячеек и с установлением соединения. Коммутация в сети Ethernet. Многоуровневая модель протоколов.

    курсовая работа [2,3 M], добавлен 25.06.2014

  • Протокол для поддержания системы передачи сообщений, обеспечение непрерывной работы SMTP-сервера. Примеры использования команды LIST, работа через протокол POP3, особенности авторизации. Условия работы режима "обновление". Пример сеанса с POP3 сервером.

    реферат [16,1 K], добавлен 03.05.2010

  • Анализ применяемых технологий в мультисервисных сетях. Сосуществование сетей АТМ с традиционными технологиями локальных сетей. Характеристика сети передачи данных РФ "Электросвязь" Кемеровской области. Схема организации сети передачи данных, каналы связи.

    дипломная работа [642,3 K], добавлен 02.11.2010

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

    магистерская работа [2,1 M], добавлен 11.10.2013

  • Компьютеры и используемая в офисе компании "АйТи Сервисез" периферия. Выбор сетевых решений. Протокол передачи данных. Построение и этапы внедрения локальной вычислительной сети по технологии Token Ring. Требования к надежности и стабильности сети.

    курсовая работа [706,4 K], добавлен 16.04.2016

  • Беспроводные и проводные системы передачи данных. Методы обеспечения безошибочности передачи данных в сетях. Оценка зависимости показателей эффективности. Снижение вероятности появления ошибки сбора данных в соответствии с предъявленными требованиями.

    дипломная работа [309,0 K], добавлен 14.10.2014

  • Топологии компьютерных сетей. Методы доступа к каналам связи. Среды передачи данных. Структурная модель и уровни OSI. Протоколы IP и TCP, принципы маршрутизации пакетов. Характеристика системы DNS. Создание и расчет компьютерной сети для предприятия.

    курсовая работа [2,3 M], добавлен 15.10.2010

  • Темы исследований в информатике. Основные идеи, которые лежат в основе работы компьютеров. Первая отечественная ЭВМ. Вычислительная сложность алгоритма. Протокол передачи данных. Понятие компьютерной программы. Вычислительная мощность компьютера.

    презентация [271,0 K], добавлен 01.11.2014

  • Понятие о протоколе Secure Sockets Layer. "Безопасный канал", основные свойства. Использование протокола, его недостатки. Интерфейс программы EtherSnoop. Фазы протокола диалога. Публичные ключи, особенности распространения. Обмен данными в Интернете.

    реферат [1,4 M], добавлен 31.10.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.