Tls порт: Что такое TLS / Хабр
Что такое 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 и показана на рисунке:
Разберём подробнее каждый шаг данной процедуры:
- Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.
- После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).
- Сервер утверждает версию используемого протокола, выбирает способ шифрования из предоставленного списка, прикрепляет свой сертификат и отправляет ответ клиенту (при желании сервер может так же запросить клиентский сертификат).
- Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.
- Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.
- Клиент расшифровывает полученное сообщение, сверяет 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 соединения. Рассмотрим простейший процесс аутентификации между Алисой и Бобом:
- И Алиса, и Боб генерируют собственные открытые и закрытые ключи.
- Алиса и Боб обмениваются открытыми ключами.
- Алиса генерирует сообщение, шифрует его своим закрытым ключом и отправляет Бобу.
- Боб использует полученный от Алисы ключ, чтобы расшифровать сообщение и таким образом проверяет подлинность полученного сообщения.
Очевидно, что данная схема построена на доверии между Алисой и Бобом. Предполагается, что обмен открытыми ключами произошёл, например, при личной встрече, и, таким образом, Алиса уверена, что получила ключ непосредственно от Боба, а Боб, в свою очередь, уверен, что получил открытый ключ Алисы.
Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:
Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.
Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:
Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.
Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.
Здесь очевидно присутствует некоторая техническая нерациональность: для проверки лишь одного сертификата требуется запрашивать весь список отозванных сертификатов, что влечёт замедление работы. Для борьбы с этим был разработан механизм под названием «Протокол статусов сертификатов» (OCSP – Online Certificate Status Protocol). Он позволяет осуществлять проверку статуса сертификата динамически. Естественно, это снижает нагрузку на пропускную способность сети, но в то же время порождает несколько проблем:
- Центры сертификации должны справляться с нагрузкой в режиме реального времени;
- Центры сертификации должны гарантировать свою доступность в любое время;
- Из-за запросов реального времени центры сертификации получают информацию о том, какие сайты посещал каждый конкретный пользователь.
Собственно, во всех современных браузерах оба решения (OCSP и CRL) дополняют друг друга, более того, как правило имеется возможность настройки предпочитаемой политики проверки статуса сертификата.
Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.
Протоколы SSL/TLS: особенности, назначение, применение
Сетевые протоколы SSL и TLS являются криптографическими протоколами, обеспечивающими аутентификацию и защиту от несанкционированного доступа, нарушения целостности передаваемых данных. Протоколы SSL/TLS предназначены для исключения подмены идентификатора на клиентской или серверной стороне, раскрытия или искажения данных. Для этих целей используется надежный метод аутентификации, применяются шифрование канала связи и коды целостности сообщений. Стандартным портом, устанавливаемым по умолчанию для SSL/TLS, является порт 443 для HTTPS, 465 для SMTPS (электронная почта), 636 для LDAPS, 563 для NNTPS, 994 для IRCS (чат), 995 для POP3S.
Протокол SSL
Протокол SSL разработан компанией Netscape для защиты данных между сервисными и транспортными протоколами. Первая обнародованная версия была выпущена в 1995 году. Широко используется для VoIP-приложений, сервисов обмена мгновенными сообщениями. SSL представляет собой безопасный канал, имеющий следующие свойства:
-
Частный канал. Обеспечивается шифрование всех сообщений после диалога, необходимого для определения ключа шифрования. -
Канал является аутентифицированным. Для клиентской стороны аутентификация выполняется опционально, а с серверной — обязательна. -
Надежность канала. При транспортировке сообщений осуществляется проверка целостности с использованием MAC.
Протокол SSL использует как симметричный, так и асимметричный ключи.
Особенности и назначение протокола SSL
Протокола SSL обеспечивает решение двух задач — шифрование передаваемой информации и передача информации именно туда, куда требуется (аутентификация). Основное назначение протокола — предоставление надежного способа обмена данными между приложениями. Реализация SSL выполнена в виде многослойной среды, которая используется для безопасной передачи информации посредством незащищенных каналов связи.
Многослойная структура представлена слоем протокола подтверждения подключения и слоем протокола записи. Первым слоем выступает транспортный протокол, например, TCP — вместе с SSL Record Protocol данные слои образуют ядро SSL, которое впоследствии участвует в формировании сложных инфраструктур.
Среди основных особенностей протокола SSL следует отметить программно-платформенную независимость. В настоящее время протокол SSL не обеспечивает должную защиту — на смену ему пришел протокол TLS.
Протокол TLS
Протокол TLS представляет собой криптографический протокол, который применяется для защищенной передачи данных между различными узлами в сети интернет. Данный протокол нашел применение в VoIP-приложениях, веб-браузерах, приложениях для мгновенного обмена сообщениями. TLS реализован на спецификации SSL 3.0. Разработкой и развитием протокола занимается компания IETF.
К основным мерам безопасности, которые обеспечивает протокол TLS, относятся:
-
Применение ключа для проверки кода аутентификации сообщения. -
Исключена вероятность понижения версии TLS или подмены на менее защищенный сетевой протокол. -
Сообщение с подтверждением связи содержит хэш всех сообщений, которыми обменивались стороны. -
Использование нумерации записей приложения с применением MAC. -
Применение псевдослучайной функции, разбивающей входные сообщения на 2 части, каждая из которых обрабатывается разной хэш-функцией.
Особенности и назначение протокола TLS
В протоколе TLS используются следующие алгоритмы:
-
RC4, Triple DES, SEED, IDEA и др. для симметричного шифрования. -
RSA, DSA, Diffie-Hellman и ECDSA для проверки подлинности ключей. -
MD5, SHA и SHA-256/384 для хэш-функций.
Приложения осуществляют обмен записями, которые хранят в себе данные. Записи могут быть сжаты, дополнены, зашифрованы или же идентифицированы. При этом в каждой записи указываются данные о длине пакета и используемой версии TLS.
В общем случае применение криптографии в протоколах SSL/TLS значительно снижает производительность приложений, зато обеспечивает надежную защиту передачи данных. Протоколы не требуют практически никаких настроек с клиентской стороны, считаются самыми распространенными протоколами защиты в сети интернет.
TLS и SSL: Необходимый минимум знаний
TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.
Что такое SSL и что такое TLS?
SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.
Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:
SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года
Принцип работы SSL и TLS
Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:
Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.
Установка соединения обеспечивается в несколько этапов:
1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.
2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать
3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.
4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.
5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.
6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.
Корневой сертификат
Чуть выше я упомянул корневой сертификат. Это сертификат авторизационного центра, подпись которым подтверждает, что сертификат, который подписан, является именно тем, который принадлежит соответствующему сервису. В самом сертификате обычно содержится ряд информационных полей, в которых содержится информация об имени сервера, которому выдан сертификат, и сроках действия этого сертификата. Если срок действия сертификата истек, он признается недействительным.
Запрос на подпись (CSR, Certificate Sign Request)
Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.
Клиентский сертификат
Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.
Цепочка действий по генерации сертификатов
Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.
Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.
$ openssl genrsa -out root.key 2048 Generating RSA private key, 2048 bit long modulus ..........+++ ...........................................+++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:IT Service Common Name (e.g. server FQDN or YOUR name) []:My Company Root Certificate Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] Getting Private key
Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.
Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.
Просмотр информации о сертификате
Содержимое сертификата можно просмотреть таким образом:
$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] notAfter=Jan 22 11:49:41 2025 GMT
Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.
Серверный сертификат
Для подписи сертификата для сервера нам нужно выполнить следующие действия:
1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно
В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата
$ openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus ...................................................................................+++ ..........................+++ e is 65537 (0x10001) $ openssl req -new -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:IT Service Common Name (e.g. server FQDN or YOUR name) []:www.mycompany.com Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] notAfter=Jan 25 12:22:32 2016 GMT
Таким образом сертификат сервера подписан и мы будем знать, какой организацией выдан этот сертификат. После подписи готовый сертификат можно использовать по назначению, например, установить на веб-сервер.
Установка SSL/TLS-сертификата на сервер с nginx
Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:
1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private
2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):
server {
listen 443;
server_name www.mycompany.com;
root html;
index index.html index.htm;
ssl on;
ssl_certificate server.pem;
ssl_certificate_key server.key;
ssl_session_timeout 5m;
# Не рекомендуется использовать SSLv3 !!!
# Он здесь только для примера
ssl_protocols SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
ssl_prefer_server_ciphers on;
location / {
try_files $uri $uri/ =404;
}
}3) Перезапустить nginx
4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.
Установка SSL/TLS-сертификата на сервер с Apache
Установка SSL/TLS-сертификата на Apache выглядит примерно так же.
1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории
2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен
3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin [email protected]
DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.pem
SSLCertificateKeyFile /etc/ssl/private/server.key
# Эта директива добавляет файл, содержащий список
# всех сертификатов, которыми подписан сертификат сервера
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:
<IfModule mod_ssl.c>
Listen 443
</IfModule>
Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку
NameVirtualHost *:443
Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf
4) Перезапустить веб-сервер Apache
Создание клиентского сертификата
Клиентский сертификат создается примерно так же, как серверный.
$ openssl genrsa -out client.key 2048 Generating RSA private key, 2048 bit long modulus ........................+++ ..................................................+++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:Saint-Petersburg Locality Name (eg, city) []:^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petrersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Engineering Common Name (e.g. server FQDN or YOUR name) []:Ivan Ivanov Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] notAfter=Jan 25 13:17:15 2016 GMT
Если необходим клиентский сертификат в формате PKCS12, создаем его:
$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Enter Export Password: Verifying - Enter Export Password:
Теперь можно использовать клиентский сертификат для работы с нашим сервером.
Настройка nginx на использование клиентских сертификатов
Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:
# Корневой сертификат(ы), которым(и) подписан клиентский ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Возможные варианты: on | off | optional | optional_no_ca ssl_verify_client optional; # Глубина проверки цепочки сертификатов, которыми подписан клиентский ssl_verify_depth 2;
После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.
Настройка Apache на использование клиентских сертификатов
Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:
# Директория, содержащая корневые сертификаты для проверки клиентов SSLCARevocationPath /etc/apache2/ssl.crl/ # или файл, содержащий сертификаты SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Опция верификации клиента. Возможные варианты: # none, optional, require and optional_no_ca SSLVerifyClient require # Глубина просмотра цепочки подписей. По умолчанию 1 SSLVerifyDepth 2
Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.
«Прослушка» информации о сертификате при помощи openssl
Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.
На стороне сервера запускаем прослушку порта при помощи openssl:
openssl s_server -accept 443 -cert server.pem -key server.key -state
На стороне клиента обращаемся к серверу, например, culr’ом:
curl -k https://127.0.0.1:443
В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.
Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:
openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3
Со стороны сервера ошибка выглядит так:
140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:
Со стороны клиента так:
curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):
curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key
Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.
Безопасность
При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.
В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.
- Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
- Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
- Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
- Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
- Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
- Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
- Нажмите, чтобы поделиться в Skype (Открывается в новом окне)
TLS и SSL протоколы: все, что нужно знать о них.
Автор Исхаков Максим На чтение 4 мин. Просмотров 605 Опубликовано Обновлено
Кибербезопасность может восприниматься как минное поле со всеми ее сложностями. Вы можете не знать, что такое SSL или TLS, но это важно. TLS – это то, благодаря чему хакеры не могут шпионить за вашим трафиком и красть данные вашей карты, пока вы используете интернет-банкинг. Но как это работает?
Определение SSL и TLS
SSL и TLS – это криптографические протоколы, которые шифруют и аутентифицируют данные, передаваемые от клиента (т. е. вашего устройства, запрашивающего веб-сайт) на сервер, компьютер или приложение.
SSL является предшественником TLS. Впервые протокол SSL был выпущен в свет в 1995 году. Однако у него было много уязвимостей, поэтому год спустя он был заменен SSL v3.0. Последнее тоже не было идеальным, поэтому TLS был введен в 1999 году. Большинство устройств и браузеров перешли на TLS v1.2. Однако многие люди настолько привыкли к термину SSL, что будут называть TLS SSLом. Большинство сейчас используют двойной термин SSL/TLS для лучшего понимания.
Зачем сайтам нужен SSL/TLS?
SSL/TLS взаимодействуют с HTTP и является тем, что добавляет S – HTTPS. HTTP – это прикладной протокол, который передает данные из браузера на сервер или, проще говоря, доставляет результаты поиска в ваш браузер. Однако HTTP соединения небезопасны сами по себе. Это все равно, что отправлять свои данные в открытый доступ – их может увидеть любой желающий. HTTP уязвим для атак, что означает, что любой, кто шпионит за трафиком, может украсть ваш логин или данные карты.
Вот почему был введен HTTPS. Это комбинация HTTP, которая обрабатывает механику передачи данных и SSL/TLS, который обрабатывает шифрование данных. Благодаря шифрованию SSL/TLS ваши данные безопасности – любой, кто следит за вашим трафиком, теперь может видеть только зашифрованные данные. В наши дни большинство сайтов используют HTTPS.
Как работает SSL?
SSL/TLS шифрование можно разделить на два этапа: handshake SSL/TLS и record layer SSL/TLS. Стоит углубится в них более подробно.
Что такое SSL handshake?
Это форма связи между клиентом и сервером, где оба решают, какая версия протокола будет использоваться для их дальнейшего взаимодействия. Как это работает на практике?
- Клиент посылает запрос “привет” на сервер, с которым он хочет связаться. Он включает в себя типы шифров (алгоритмы шифрования), которые может поддерживать клиент.
- Сервер отправляет’ привет ‘ обратно со своим сертификатом SSL и его открытым ключом. Клиент и сервер здесь используют асимметричную криптографию для обмена защищенными сообщениями. Это означает, что клиенту нужен открытый ключ сервера для шифрования сообщений, а серверу нужны два ключа – частный и открытый – для его расшифровки. Никто, шпионящий за трафиком, не может расшифровать их сообщения.
- Затем клиент использует открытый ключ сервера для создания предварительного pre-master и отправляет его на сервер. Это будет использоваться для создания ключей сеанса и повышения уровня связи до симметричного шифрования. Теперь оба конца будут использовать только закрытые ключи. Симметричная криптография сделает их связь намного быстрее и будет использовать меньше ресурсов.
- Сервер расшифровывает pre-master, использует его для создания симметричного ключа и обменивается им с клиентом. При установленном симметричном шифровании они теперь могут обмениваться зашифрованными сообщениями. Трафик защищен.
Уровень записи SSL/TLS
Именно здесь происходит шифрование. Данные отправляются из приложения пользователя и шифруются. В зависимости от шифра, он также может быть сжат. Затем он отправляется дальше на сетевой транспортный уровень, который определяет, как отправить данные на целевое устройство.
Что такое SSL-сертификат и зачем он нужен?
Серверы, поддерживающие протокол TLS, будут иметь сертификаты SLS, хотя правильнее было бы называть их сертификатами SSL/TLS. Они приобретаются с платформ хостинга и необходимы во время процесса handshake SSL/TLS, чтобы удостовериться, что они действительно являются провайдерами безопасного соединения.
Однако протоколы – это не то же самое, что сертификаты. Какой протокол будет использоваться при подключении, SSL или TLS, определяется вашим браузером и конфигурациями целевого сервера, а не сертификатом сайта. Можно подключиться к сайту, который имеет HTTPS, но использует устаревший протокол SSL v3.0.
Такие соединения уязвимы для атак. Большинство новых браузеров укажут это в вашем URL. Просто посмотрите на закрытые зеленые висячие замки и символы HTTPS. Если вы беспокоитесь о случайном подключении к сайту, который поддерживает только SSL v3.0, то можете вручную отключить SSL соединения. Но это может привести к обрыву связи.
На видео: SSL/TLS: история уязвимостей
знакомство с SSL/TLS / Блог компании 1cloud.ru / Хабр
Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.
Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.
/ Flickr / David Goehring / CC-BY
SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.
Цель протокола — обеспечить защищенную передачу данных. При этом для аутентификации используются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Первый тип шифрования более ресурсоемкий, поэтому его комбинация с симметричным алгоритмом помогает сохранить высокую скорость обработки данных.
Рукопожатие
Когда пользователь заходит на веб-сайт, браузер запрашивает информацию о сертификате у сервера, который высылает копию SSL-сертификата с открытым ключом. Далее, браузер проверяет сертификат, название которого должно совпадать с именем веб-сайта.
Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.
Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.
Алгоритмы шифрования
Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.
Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.
Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.
Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.
Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.
DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.
ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.
Более короткий ключ также влияет на время обработки данных, которое заметно сокращается. Этот факт и то, что алгоритм эффективно обрабатывает большое количество подключений, сделали его удобным инструментом для работы с мобильной связью. В SSL-сертификатах можно использовать сразу несколько методов шифрования для большей защиты.
Хеш и MAC
Цель хеш-алгоритма — преобразовывать все содержимое SSL-сертификата в битовую строку фиксированной длины. Для шифрования значения хеша применяется закрытый ключ центра сертификации, который включается в сертификат как подпись.
Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.
В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.
Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.
Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.
Сертификаты бывают разные
Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.
Domain Validation, или сертификаты с проверкой домена, подходят для некоммерческих сайтов, так как они подтверждают только веб-сервер, обслуживающий определенный сайт, на который был осуществлен переход. Этот вид сертификата самый дешевый и популярный, но не может считаться полностью безопасным, так как содержит только информацию о зарегистрированном доменном имени.
Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.
Extended Validation, или сертификат с расширенной проверкой, считается самым надежным. Собственно, зеленый замочек или ярлык в браузере означает как раз то, что у сайта есть именно такой сертификат. О том, как разные браузеры информируют пользователей о наличии сертификата или возникающих ошибках можно почитать тут.
Он нужен веб-сайтам, которые проводят финансовые транзакции и требуют высокий уровень конфиденциальности. Однако многие сайты предпочитают перенаправлять пользователей для совершения платежей на внешние ресурсы, подтвержденные сертификатами с расширенной проверкой, при этом используя сертификаты OV, которых вполне хватает для защиты остальных данных пользователей.
Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.
Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.
Получить SSL-сертификат можно и самостоятельно: пара ключей для этого генерируется через любой генератор, например, бесплатный OpenSSL. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.
P.S. Дополнительно по теме из блога IaaS-провайдера 1cloud:
Протокол TLS | Microsoft Docs
-
- Чтение занимает 2 мин
В этой статье
Область применения. Windows Server (Semi-Annual Channel), Windows Server 2016, Windows 10Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows 10
В этой статье для ИТ-специалистов описывается принцип работы протокола TLS и приводятся ссылки на RFC-документы IETF по протоколу TLS 1,0, TLS 1,1 и TLS 1,2.This topic for the IT professional describes how the Transport Layer Security (TLS) protocol works and provides links to the IETF RFCs for TLS 1.0, TLS 1.1, and TLS 1.2.
Протоколы TLS (и SSL) расположены между уровнем протокола приложения и уровнем TCP/IP, где они могут защищать и передавать данные приложений на транспортный уровень.The TLS (and SSL) protocols are located between the application protocol layer and the TCP/IP layer, where they can secure and send application data to the transport layer. Поскольку протоколы работают между уровнем приложения и транспортным уровнем, TLS и SSL могут поддерживать несколько протоколов уровня приложений.Because the protocols work between the application layer and the transport layer, TLS and SSL can support multiple application layer protocols.
Для TLS и SSL предполагается, что используется транспорт, ориентированный на соединение, обычно TCP.TLS and SSL assume that a connection-oriented transport, typically TCP, is in use. Этот протокол позволяет клиентским и серверным приложениям обнаруживать следующие угрозы безопасности:The protocol allows client and server applications to detect the following security risks:
Вмешательство в сообщениеMessage tampering
Перехват сообщенийMessage interception
Подделка сообщенийMessage forgery
Протоколы TLS и SSL можно разделить на два уровня.The TLS and SSL protocols can be divided into two layers. Первый уровень состоит из протокола приложения и трех протоколов подтверждения: протокол подтверждения, протокол изменений шифра и протокол оповещения.The first layer consists of the application protocol and the three handshaking protocols: the handshake protocol, the change cipher spec protocol, and the alert protocol. Второй уровень — протокол записи.The second layer is the record protocol. На следующем рисунке показаны различные слои и их элементы.The following image illustrates the various layers and their elements.
Уровни протокола TLS и SSLTLS and SSL protocol layers
Поставщик услуг SChannel использует протоколы TLS и SSL без изменений.The Schannel SSP implements the TLS and SSL protocols without modification. Протокол SSL является частным, но в результате задача инженерного проектирования Интернета выдает общедоступные спецификации TLS.The SSL protocol is proprietary, but the Internet Engineering Task Force produces the public TLS specifications. Сведения о том, какие версии TLS или SSL поддерживаются в версиях Windows, см. в разделе протоколы в TLS/SSL (Schannel SSP).For information about which TLS or SSL version is supported in Windows versions, see Protocols in TLS/SSL (Schannel SSP). В следующей таблице перечислены спецификации для каждой версии TLS.The following table lists the specifications for each TLS version. Каждая спецификация содержит следующие сведения:Each specification contains information about:
Протокол записи TLSThe TLS Record Protocol
Протоколы подтверждения TLS: — Изменение протокола оповещений протокола шифра -The TLS Handshaking Protocols: — Change cipher spec protocol — Alert protocol
Криптографические вычисленияCryptographic Computations
Обязательные комплекты шифровMandatory Cipher Suites
Протокол прикладных данныхApplication Data Protocol
RFC 5246 — версия 1.2 протокола TLS.RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2
RFC 4346 — версия 1.1 протокола TLS;RFC 4346 — The Transport Layer Security (TLS) Protocol Version 1.1
RFC 2246 — версия 1.0 протокола TLS;RFC 2246 — The TLS Protocol Version 1.0
Возобновление сеанса TLSTLS session resumption
Представленный в Windows Server 2012 R2, поставщик общих служб SChannel реализовал серверную часть возобновления сеанса TLS.Introduced in Windows Server 2012 R2 , the Schannel SSP implemented the server-side portion of TLS session resumption. Реализация RFC 5077 на стороне клиента была добавлена в Windows 8.The client-side implementation of RFC 5077 was added in Windows 8.
Устройства, подключающие TLS к серверам, часто требуют переподключения.Devices that connect TLS to servers frequently need to reconnect. Возобновление сеанса TLS снижает затраты на установку TLS-подключений, так как возобновление включает в себя сокращенное подтверждение TLS.TLS session resumption reduces the cost of establishing TLS connections because resumption involves an abbreviated TLS handshake. Это упрощает несколько попыток возобновления работы, позволяя группе TLS-серверов возобновить сеансы TLS друг друга.This facilitates more resumption attempts by allowing a group of TLS servers to resume each other’s TLS sessions. Это изменение обеспечивает следующие возможности для любого клиента TLS, поддерживающего RFC 5077, включая Windows Phone и устройства Windows RT:This modification provides the following savings for any TLS client that supports RFC 5077, including Windows Phone and Windows RT devices:
Уменьшение использования ресурсов на сервереReduced resource usage on the server
Сниженная пропускная способность, повышающая эффективность клиентских подключенийReduced bandwidth, which improves the efficiency of client connections
Сокращение времени, затраченного на подтверждение TLS из-за возобновления соединенияReduced time spent for the TLS handshake due to resumptions of the connection
Сведения о возобновлении сеанса TLS без отслеживания состояния см. в документе IETF RFC 5077.For information about stateless TLS session resumption, see the IETF document RFC 5077.
Согласование протокола приложенияApplication protocol negotiation
В Windows Server 2012 R2 и Windows 8.1 появилась поддержка, позволяющая согласование протокола приложения TLS на стороне клиента.Windows Server 2012 R2 and Windows 8.1 introduced support that allows client-side TLS application protocol negotiation. Приложения могут использовать протоколы в рамках стандартной разработки HTTP 2,0, а пользователи могут получать доступ к веб-службы, таким как Google и Twitter, с помощью приложений, использующих протокол SPDY.Applications can leverage protocols as part of the HTTP 2.0 standard development, and users can access online services such as Google and Twitter by using apps running the SPDY protocol.
Сведения о том, как работает согласование протокола приложений, см. в разделе Расширение согласования протокола прикладного уровня TLS.For information about how application protocol negotiation works, see Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension.
Поддержка TLS для расширений указание имени сервераTLS support for Server Name Indication extensions
Компонент указания имени сервера (SNI) расширяет возможности протоколов SSL и TLS для правильной идентификации сервера в случае, когда на одном сервере запущено несколько виртуальных образов.The Server Name Indication (SNI) feature extends the SSL and TLS protocols to allow proper identification of the server when numerous virtual images are running on a single server. В сценарии размещения виртуальной среды несколько доменов (каждый с собственным потенциально отличающимся сертификатом) размещаются на одном сервере.In a virtual hosting scenario, several domains (each with its own potentially distinct certificate) are hosted on one server. В этом случае сервер не может заранее узнать, какой сертификат следует отправить клиенту.In this case, the server has no way of knowing beforehand which certificate to send to the client. SNI позволяет клиенту сообщать целевой домен ранее по протоколу, что позволяет серверу правильно выбирать нужный сертификат.SNI allows the client to inform the target domain earlier in the protocol, and this allows the server to correctly select the proper certificate.
Дополнительные функциональные возможности:This additional functionality:
Позволяет размещать несколько веб-сайтов SSL с одним сочетанием протокола Интернета и портаAllows you to host multiple SSL websites on a single Internet Protocol and port combination
Сниженное использование памяти при размещении нескольких веб-сайтов, работающих по протоколу SSL, на единственном веб-сервере.Reduces the memory usage when multiple SSL websites are hosted on a single web server
Позволяет большему пользователю одновременно подключаться к веб-сайтам SSLAllows more users to connect to SSL websites simultaneously
Про порты и шифрование в почтовых серверах / Хабр
При настройке сервера исходящей почты на почтовом клиенте вы видите 3 опции для шифрования — без шифрования, SMTPS и STARTTLS, а также 3 возможных порта — 25, 465, 587. Что тут выбрать и для чего — давайте разбираться.
Видео
Previous Режимы работы почтовых серверов
Next > DNS записи для почтовых серверов
Когда вы отправляете кому-то сообщение, ваш почтовый клиент использует протокол ESMTP для передачи этого сообщения, а затем ваш почтовый сервер использует тот же протокол, если ему нужно передать это сообщение на другой сервер. И хотя все говорят и пишут SMTP, речь обычно идёт про ESMTP – тот же самый SMTP, но с набором расширений, таких как авторизация и шифрование. Да, когда-то SMTP не поддерживал даже авторизацию.
Теперь немного про SMTPS. Когда-то интернет был настолько простым, что всё в нем передавалось в открытом виде. Потом появились криптографические протоколы шифрования, тот же самый SSL. И сервисы, которые раньше передавали информацию в открытом виде, начали заворачивать трафик в SSL.
Но сделать это на тех же стандартных портах оказалось непросто – клиент и сервер должны договориться о методе шифрования, а чтобы сервис на одном порту одновременно работал для одних с шифрованием, а для других без – требовало бы изменений в протоколах. И чтобы не усложнять всё, начали лепить отдельные порты для шифрованных соединений – так появился 443 для HTTPS и 465 для SMTPS. Но тут спохватились – выделенных портов мало, количество сервисов растёт, а если еще каждый для своих целей будет использовать по несколько портов с шифрованием и без – беда.
И в итоге решили немного доработать протоколы. В некоторых случаях это не очень получилось, например для HTTP, а в случае с SMTP получился вполне себе годный вариант. Для этого в SMTP добавили расширение STARTTLS. Вообще, расширение STARTTLS используется не только для SMTP, в целом это команда для начала переговоров о шифровании. В отличие от SMTPS, который использует выделенный порт 465 и сразу шифрует соединение, STARTTLS лишь расширение для SMTP, а значит сессия инициируется как обычная SMTP сессия. Почтовые сервера приветствуют друг друга, а потом предлагают начать шифроваться и выбирают доступные криптографические протоколы.
В итоге с появлением STARTTLS из стандартов решили убрать SMTPS на 465 порту как отдельный сервис. Из стандартов убрали, но сервис остался, и до сих пор используется. Насчёт шифрования я еще сделаю отдельную тему, а пока поговорим про STARTTLS.
Ранее я сказал, что при STARTTLS почтовые сервера или клиент/сервер открывают соединение без шифрования, а потом договариваются о шифровании. Для шифрования они используют тот же самый SSL/TLS. Но что, если они не смогут договориться? Получится, они будут общаться в незашифрованном виде? По интернету? А между тем, договариваются они без какого-либо шифрования, тем самым легко обмануть сервер или клиент отсутствием доступных методов шифрования. И в своё время уличили одного из провайдеров в такой атаке. И нафиг тогда такое шифрование нужно, спросите вы. Не всё так безнадёжно. На самом деле, администратор может отключить возможность передачи почты, если не удалось договориться о шифровании, а почтовые клиенты обязаны предупреждать о том, что сервер не поддерживает шифрования.
И так, мы разобрались с тем, что есть SMTP, который работает по 25 порту, есть SMTPS, который работает по 465, но есть еще один порт – 587, который также используется почтовым сервером.
Как вы заметили, почтовые клиенты подключаются к серверам по SMTP. И почтовые сервера подключаются друг к другу тоже по SMTP. Также я говорил в прошлой части, что есть такие сервера – релей хосты, которые пересылают почту. По определённым причинам, в основном человеческим, в интернете есть релей хосты, которые позволяют неавторизованным пользователям перенаправлять сообщения с любого адреса. И эти хосты появляются каждый раз, когда нерадивый админ поднимает почтовый сервер, а это бывает нередко. Как итог, злоумышленники поднимают временные сервера или заражают компьютеры пользователей, которые рассылают спам через эти релей хосты без авторизации.
Как итог, некоторые интернет провайдеры блокируют любые подключения пользователей к 25 порту.
Между серверами в интернете этот порт открыт, а вот для пользователей сделали отдельный сервис – MSA (message submission agent – агент отправки почты), тем самым отделив подключения пользователей от подключения серверов, которые общаются по прежнему по MTA. Вообще, даже на 25 порту работает MSA, но официальный порт для него – 587. Так что мешает спамерам использовать этот порт? То что на MSA, как правило, обязательна авторизация пользователей. Это не единственная причина существования MSA – так как он работает с почтовыми клиентами, он лучше оптимизирован под работу клиентов – сразу предупреждает о каких-либо ошибках в сообщениях, например, отсутствии доменного адреса получателя.
И напоследок, давайте проследим за процессом отправки почтового сообщения. Для этого используем wireshark, почтовый клиент и gmail аккаунт. Всё начинается со стандартного TCP хэндшейка, после чего запускается SMTP сессия. В рамках сессии почтовый клиент и сервер приветствуют друг друга, после чего почтовый клиент предлагает зашифровать сессию, сервер даёт согласие, после чего происходит обмен ключами и начинается зашифрованная сессия TLSv1.3, после чего в зашифрованном виде клиент авторизуется и передаёт сообщение, которое не видно для перехватчика трафика.
Что такое порт SSL? Техническое руководство для HTTPS
Получите сведения о SSL
Secure Sockets Layer (SSL) — это технология, отвечающая за аутентификацию данных и шифрование для интернет-соединений. Он шифрует данные, передаваемые через Интернет между двумя системами (обычно между сервером и клиентом), чтобы они оставались конфиденциальными. А с растущей важностью конфиденциальности в Интернете вам следует ознакомиться с портом SSL.
Поскольку данные могут быть отправлены с использованием SSL или без него, один из способов указать безопасное соединение — это номер порта. По умолчанию соединения HTTPS используют порт TCP 443. Незащищенный протокол HTTP использует порт 80.
Обычно используемые TCP-порты
Тем, кто отвечает за настройку и управление веб-хостингом, полезно знать номера для общих служб, таких как порт SSL. Используйте приведенные ниже таблицы, чтобы быстро найти номера портов и их основные функции.
Интернет
| Порт № | Функция |
|---|---|
| 80 | HTTP |
| 443 | SSL |
| 21 | FTP |
| 990 | FTP |
| 22 | SFTP / SSH |
| 3306 | MySQL |
Электронная почта
| Порт № | Функция |
|---|---|
| 110 | POP — входящий |
| 995 | POP SSL — входящий |
| 143 | IMAP — входящие |
| 993 | IMAP SSL — входящий |
| 25, 80, 3535 | SMTP — исходящий |
| 465 | SMTP SSL — исходящий |
Вы можете увидеть, какие порты GoDaddy использует для электронной почты — помимо поиска информации о портах SSL — в Справочном центре GoDaddy.
cPanel
| Порт № | Функция |
|---|---|
| 2082 | cPanel Входящий TCP |
| 2083 | cPanel SSL входящий TCP |
| 2086 | WHM TCP, входящий |
| 2087 | WHM SSL TCP, входящий |
| 2089 | WHM SSL TCP, входящий |
| 2095 | Веб-почта Входящий TCP |
| 2096 | Веб-почта SSL TCP, входящий |
Вы можете увидеть, какие порты GoDaddy использует для cPanel, в Справочном центре GoDaddy.
Как работают HTTPS и SSL?
HTTP не является отдельным протоколом от HTTPS. Скорее, HTTPS работает путем установления безопасного HTTP-соединения с использованием SSL. Следовательно, стеки протоколов для HTTP и HTTPS выглядят одинаково:
| Слой | Стек протоколов HTTP | Стек протоколов HTTPS |
|---|---|---|
| Уровень приложения | HTTP | HTTP |
| Уровень безопасности | SSL (TLS) | |
| Транспортный уровень | TCP | TCP |
| Сетевой уровень | IP | IP |
| Уровень канала данных | Сетевые интерфейсы | Сетевые интерфейсы |
Единственная разница в том, что HTTPS работает поверх SSL.Для создания этого безопасного подключения к Интернету на веб-сервере устанавливается сертификат SSL. Сертификат SSL удостоверяет личность организации для активации протокола HTTPS, чтобы данные могли безопасно передаваться с веб-сервера в веб-браузер.
Различия между сертификатами и протоколами
Протокол HTTPS и сертификат SSL — это два разных, но очень важных фактора в создании безопасного интернет-соединения.
- Протокол HTTPS обеспечивает канал, по которому данные шифруются и безопасно передаются.
- просто используются для аутентификации важной информации, когда пользователь Интернета пытается отправить информацию через безопасное соединение.
Сертификаты SSL
Следовательно, безопасное соединение определяется конфигурацией вашего сервера, а не самим сертификатом.
В чем разница между SSL и TLS?
Transport Layer Security (TLS) — это обновление протокола SSL. Первоначальный протокол SSL был разработан Netscape еще в 1995 году и опубликован как SSL 2.0. С тех пор были внесены обновления для обеспечения более надежного и безопасного шифрования.
В 1999 году TLS 1.0 был выпущен как обновление SSL 3.0. С тех пор TLS стал основной технологией, используемой для защиты данных через интернет-соединения и SSL. Однако, поскольку термин SSL более широко известен, название сохраняется, несмотря на то, что технология обесценивается.
Почему я должен беспокоиться о моем порте SSL?
Казалось бы, небольшой нюанс, ваш порт SSL важен по ряду причин.Во-первых, HTTP теряет популярность. На самом деле, согласно отчету Google о прозрачности HTTPS, более 70 процентов веб-страниц загружаются через HTTPS в Google Chrome в США. Помимо причины, по которой «это делают все», существует масса преимуществ использования HTTPS по сравнению с HTTP.
Ограничьте подверженность преступной деятельности с помощью SSL
HTTPS предлагает дополнительный уровень защиты от цифрового подслушивания, с помощью которого злоумышленники отслеживают сетевую активность, чтобы украсть ценную информацию, например учетные данные для входа.Поскольку HTTPS зашифрован, это помогает предотвратить этот вид преступной деятельности.
HTTPS требуется для соответствия PCI
Если вы собираете информацию о кредитной карте на своем веб-сайте, индустрия платежных карт требует от вас использовать HTTPS.
HTTPS может загружать веб-страницы быстрее, чем HTTP
HTTPS не только обеспечивает более безопасный просмотр, но и может положительно повлиять на время загрузки содержимого вашего сайта. Если вам нужны доказательства, убедитесь сами.
Сделайте просмотр веб-страниц более надежным
Большинство основных веб-браузеров указывают, является ли сайт безопасным, в адресной строке с помощью значка замка или слова «безопасный».
веб-браузеры, такие как Chrome, стремятся предупреждать пользователей, когда они заходят на сайт, не использующий HTTPS.
SSL может повысить ваш SEO
HTTPS предпочитают основные поисковые системы и обычно считают полезным для SEO.Крайне важно правильно реализовать HTTPS и предпринять несколько дополнительных шагов, чтобы воспользоваться преимуществами SEO. Следуйте этому контрольному списку миграции HTTPS для SEO, чтобы убедиться, что вы все поняли правильно.
Как мне получить SSL?
Сертификаты SSL
можно приобрести в центре сертификации (CA), например в GoDaddy. После покупки сертификата следуйте инструкциям вашего хостинг-провайдера, чтобы установить сертификат SSL.
.
SSL, TLS и STARTTLS | Fastmail
Это информационная страница об истории SSL, TLS и STARTTLS и различиях между этими протоколами. Если вам нужна информация о настройке вашего почтового клиента , перейдите сюда.
Часто возникает путаница в отношении различных терминов SSL , TLS и STARTTLS .
SSL и TLS — это стандартная технология для шифрования соединений между двумя компьютерами.Это предотвращает слежку за этими сообщениями третьими лицами.
TLS является преемником SSL. Он поддерживается всеми современными и безопасными системами, обрабатывающими интернет-трафик, включая Fastmail. Термины SSL и TLS часто переключаются и используются как синонимы.
STARTTLS отличается от SSL и TLS. До того, как шифрование стало стандартным, многие соединения между почтовым клиентом и сервером
были сделаны небезопасно. Это подвергает личную информацию опасности быть украденной.STARTTLS помог снизить этот риск, взяв существующее небезопасное соединение и обновив его.
к защищенному соединению, использующему SSL / TLS. STARTTLS работает с SSL или TLS.
Номера версий SSL / TLS
Номера версий SSL и TLS в порядке от старых к новейшим:
- SSL версии 2
- SSL версии 3
- TLS версии 1.0
- TLS версии 1.1
- TLS версии 1.2
- TLS v1.3.
Когда соединение выполняется с портом, имеющим SSL или TLS, или когда небезопасное соединение повышается до безопасного с помощью STARTTLS, обе стороны соединения соглашаются на конкретное
версия в зависимости от того, что поддерживается.Это может означать, что если сервер поддерживает новейшую версию TLS v1.3, но почтовый клиент, подключающийся к серверу, поддерживает только
TLS v1.1, обе стороны могут использовать TLS v1.1.
Хотя сегодня почти все онлайн-сервисы поддерживают SSL / TLS, не все сервисы поддерживают новейшую версию TLS v1.3. SSL официально устарел (по состоянию на май 2018 г.) и больше не используется
современными онлайн-сервисами. Текущее программное обеспечение поддерживает TLS v1.0, TLS v1.1 и TLS v1.2, и многие сайты и службы теперь настоятельно рекомендуют по крайней мере TLS v1.2 за общий
улучшенный профиль безопасности.
TLS против проблемы именования STARTTLS
Одна из причин путаницы в названиях этих различных технологий заключается в том, что некоторые программы электронной почты неправильно используют термин TLS, хотя им следовало использовать STARTTLS.
Более старые версии Thunderbird, в частности, использовали «TLS», чтобы обозначить, что STARTTLS следует использовать для обновления соединения, и соединение должно завершиться неудачей, если STARTTLS не поддерживается.
В этих версиях также использовался термин «TLS, если доступен».«TLS, если доступен» означает, что программа попытается использовать STARTTLS для обновления соединения, если сервер поддерживает это, но в противном случае будет использовать небезопасное соединение.
История аутентификации электронной почты
Чтобы понять SSL / TLS и STARTTLS, необходимо понять историю, лежащую в основе этих стандартов, и то, как отрасль развивалась для борьбы с существующим поведением пользователей и клиентов и новыми угрозами.
SSL / TLS и STARTTLS еще не были изобретены, когда IMAP, POP и SMTP уже были хорошо развиты.Добавление к ним надлежащего шифрования без нарушения существующего поведения было серьезной проблемой.
SSL / TLS против номеров портов открытого текста / STARTTLS
В зависимости от типа подключения и поддерживаемого шифрования могут потребоваться разные номера портов.
Поскольку такие технологии электронной почты, как IMAP, POP и SMTP, уже существовали, когда был изобретен SSL / TLS, ожидались соединения с обычным текстом через стандартные порты 143 , 110 и 25 .Хотя многие службы поддерживали использование STARTTLS для обновления соединения на этих портах, если клиент также не поддерживал это, существовал риск получения конфиденциальной информации, например
пароли передаются в виде обычного текста. Это подвергало пароли значительному риску кражи, если злоумышленник наблюдал за соединением.
Для повышения безопасности было решено выбрать три новых порта. Эти порты ожидали подключения SSL / TLS немедленно, поэтому они отказались от любых попыток передать любую информацию в виде обычного текста.Это защищало конфиденциальную информацию, такую как пароли и адреса электронной почты — информация либо передавалась безопасно, либо не передавалась вообще. Это
называется «неявным TLS», что означает, что ожидается, что обе стороны соединения будут поддерживать зашифрованные соединения.
| Обычный протокол | Протокол с неявным TLS | |
|---|---|---|
| IMAP | Порт 143 | Порт 993 |
| ПОП | Порт 110 | Порт 995 |
| SMTP | Порт 25 | Порт 465 |
Проблема с несколькими номерами портов
Через некоторое время после того, как были согласованы эти новые порты для поддержки неявного TLS, было решено, что наличие двух портов для каждого протокола было расточительным.Только для поддержки
Один порт, STARTTLS был создан как способ для клиента подключаться через обычный текст, а затем обновлять соединение до безопасного, использующего SSL / TLS.
Это тоже не было идеальным решением. Уже были реальные пользователи, которые использовали новые номера портов со своими почтовыми клиентами. Почтовые клиенты могут быть очень долговечными, поэтому
отключение новых портов было неудобным для пользователя вариантом.
Также были проблемы с безопасностью при использовании одного порта и обновлении соединения.Хотя механизмы были
добавлен к каждому протоколу, чтобы сообщить клиентам, что
соединение поддерживает обновление до безопасного соединения, и они не должны пытаться войти в систему, пока обновление не будет завершено, некоторые клиентские программы проигнорировали это и отправили
пароли и имена пользователей в любом случае поверх обычного текста. Даже если сервер отклонил соединение, данные для входа все равно были отправлены в незашифрованном виде, что сделало их уязвимыми.
Другое программное обеспечение проигнорировало инструкцию сервера об обновлении соединения и просто отправило пользователю в ответ ошибку входа.Это вызвало много путаницы в том, что было не так.
Поскольку обе эти проблемы вызвали серьезные проблемы для существующих клиентов, большинство служб продолжали использовать соединения в виде обычного текста на одном номере порта и предлагали
безопасные неявные соединения SSL / TLS на втором номере порта.
Сегодня многие почтовые службы, в том числе Fastmail, теперь полностью отключают вход по протоколу IMAP и POP с открытым текстом на портах 143 и 110 , оставляя зашифрованные соединения.
на портах 993 и 995 как единственный вариант.Это гарантирует, что все клиенты будут использовать зашифрованные соединения SSL / TLS для защиты конфиденциальных данных.
SMTP STARTTLS как исключение
Есть одно исключение из этого спора об использовании SSL / TLS и STARTTLS: SMTP.
SMTP изначально был разработан для передачи сообщений. Передача сообщений через SMTP происходит между разными серверами, которые не предназначены для прямого взаимодействия с клиентом.
По этой причине на ранних этапах разработки не было необходимости учитывать проблемы с почтовыми клиентами, такие как передача информации о пароле пользователя в открытом виде.
Лишь позже SMTP начал использоваться для передачи сообщения , а также для передачи сообщений. На заре появления почтовых клиентов, настроенных для отправки с использованием SMTP, эти
использовал порт 25 , тот же порт, который использовался в самих почтовых системах для передачи. В более крупных системах пересылки почты можно было заблокировать порт 25 , чтобы он
может использоваться только доверенными IP-адресами. Конечно, это было невозможно сделать для многих тысяч домашних IP-адресов, использующих SMTP в своих почтовых клиентах для электронной почты.
отправка, и поэтому порт 587 был определен для отправки сообщения.
Использование порта 587 вместо 25 для отправки сообщений стало популярным примерно в то же время, когда важность использования шифрования для защиты конфиденциальных данных стала
хорошо известные и определялись расширения шифрования для SMTP. Порт 587 , определенный специально для отправки сообщений, поддерживается
переход на безопасное соединение с STARTTLS.
Порт 465 также был определен для отправки SMTP, и в отличие от порта 587 , 465 специально поддерживал неявный TLS, как порт 993 для IMAP и 995 для POP.На данный момент,
однако отрасль ожидала, что все соединения для IMAP, POP и SMTP будут безопасно обновляться с использованием STARTTLS вместо предпочтительного неявного TLS.
сегодня. По этой причине вскоре после определения порта 465 он был отозван. Ожидалось, что все клиенты перейдут на использование STARTTLS на порту 587 .
Программное обеспечение почтового клиента
может прослужить очень долго, и большинству пользователей может быть сложно самостоятельно вносить изменения в порты и настройки сервера.Многие почтовые клиенты также
в настоящее время разработан для работы только с неявным SSL / TLS на порту 465 . Это сделало очень трудным удаление порта 465 в качестве опции для клиентов, даже если это было
официально отозван.
Службы
, поддерживающие SMTP для отправки сообщений, теперь требуют, чтобы клиенты, подключающиеся через стандартный порт 587 , обновили соединение с помощью STARTTLS и вошли в систему.
с именем пользователя и паролем.
В 2018 году официальная рекомендация снова изменилась на использование неявного TLS через порт 465 .Из-за долгожительства
клиентское программное обеспечение электронной почты, ожидается, что пройдет очень много времени, прежде чем порт 587 будет закрыт.
Поскольку службы теперь переместили пользователей от использования порта 25 для отправки электронной почты, теперь они могут заблокировать этот порт для пользователей и использовать его только для внутренних целей.
предполагаемая цель передачи электронной почты. Порт 25 был значительным источником спама из-за заражения компьютеров пользователей спамом, рассылающим вирусы, поэтому
значительно уменьшил количество спама, отправляемого через службы, которые заблокировали этот порт.
В настоящее время существует равномерное распределение пользователей, использующих неявный SSL / TLS с портом 465 , и пользователей, обновляющих свое соединение с помощью STARTTLS, используя порт 587 .
Fastmail продолжит предлагать оба варианта в обозримом будущем.
.
Сеть 101: безопасность транспортного уровня (TLS)
Сеть через браузер (O’Reilly)
Введение
Протокол SSL был первоначально разработан в Netscape для обеспечения
безопасность транзакций электронной торговли в Интернете, которая требует шифрования для
защищать личные данные клиентов, а также аутентификацию и целостность
гарантии для обеспечения безопасной транзакции. Для этого SSL
протокол был реализован на уровне приложений, непосредственно поверх TCP
(Рисунок 4-1), что позволяет
протоколы над ним (HTTP, электронная почта, обмен мгновенными сообщениями и многие другие) для
работать без изменений, обеспечивая безопасность связи, когда
общение по сети.
При правильном использовании SSL сторонний наблюдатель может только сделать вывод
конечные точки подключения, тип шифрования, а также частоту и
приблизительный объем отправленных данных, но не может читать или изменять какие-либо
фактические данные.
Рисунок 4-1. Безопасность транспортного уровня (TLS)
Когда протокол SSL был стандартизирован IETF, он был переименован
к безопасности транспортного уровня (TLS). Многие используют имена TLS и SSL
взаимозаменяемы, но технически они разные, поскольку каждый
описывает другую версию протокола.
SSL 2.0 был первой публично выпущенной версией протокола, но
он был быстро заменен на SSL 3.0 из-за ряда обнаруженных средств защиты
недостатки. Поскольку протокол SSL был проприетарным для Netscape, IETF
предприняли попытку стандартизировать протокол, в результате чего появился RFC 2246,
который был опубликован в январе 1999 года и стал известен как TLS 1.0. поскольку
затем IETF продолжил итерацию протокола для решения
недостатки безопасности, а также расширение ее возможностей: TLS 1.1 (RFC 4346)
был опубликован в апреле 2006 г., TLS 1.2 (RFC 5246) в августе 2008 г. и работает
сейчас ведется определение TLS 1.3.
Тем не менее, пусть обилие номеров версий не вводит вас в заблуждение:
ваши серверы всегда должны отдавать предпочтение и согласовывать последнюю стабильную версию
протокола TLS для обеспечения максимальной безопасности, возможностей и
гарантии исполнения. Фактически, некоторые критически важные для производительности функции, такие как
как HTTP / 2, явно требуют использования TLS 1.2 или выше и будет прервано
в противном случае связь. Хорошая безопасность и производительность идут рука об руку.
TLS был разработан для работы поверх надежного транспортного протокола
типа TCP. Однако он также был адаптирован для работы с дейтаграммами.
протоколы, такие как UDP. Безопасность транспортного уровня дейтаграмм (DTLS)
протокол, определенный в RFC 6347, основан на протоколе TLS и может
предоставить аналогичные гарантии безопасности при сохранении дейтаграммы
модель доставки.
§Шифрование, аутентификация и целостность
Протокол TLS предназначен для предоставления трех основных услуг:
все приложения, работающие над ним: шифрование, аутентификация и данные
целостность. Технически вам не обязательно использовать все три в каждом
ситуация. Вы можете принять решение о принятии сертификата без подтверждения его
подлинность, но вы должны быть хорошо осведомлены о рисках безопасности и
последствия этого. На практике безопасное веб-приложение будет
использовать все три услуги.
- Шифрование
Механизм обфускации того, что отправляется с одного хоста на другой.
- Аутентификация
Механизм проверки действительности предоставленной идентификации
материал.- Целостность
Механизм обнаружения фальсификации и подделки сообщений.
Чтобы установить криптографически безопасный канал данных,
одноранговые узлы должны договориться о том, какие наборы шифров будут использоваться, и
ключи, используемые для шифрования данных.Протокол TLS определяет четко определенный
последовательность рукопожатия для выполнения этого обмена, которую мы рассмотрим в
подробно в TLS Handshake.
Гениальная часть этого рукопожатия и причина, по которой TLS работает в
На практике это связано с использованием криптографии с открытым ключом (также известной как
криптография с асимметричным ключом), что позволяет одноранговым узлам согласовывать
общий секретный ключ без необходимости устанавливать какие-либо предварительные знания о каждом
другое, и сделать это по незашифрованному каналу.
В рамках рукопожатия TLS протокол также позволяет обоим партнерам
подтвердить свою личность. При использовании в браузере это
механизм аутентификации позволяет клиенту проверить, что сервер
кем он себя называет (например, вашим банком), а не просто притворяется
быть местом назначения, подделав его имя или IP-адрес. Эта
проверка основана на установленной цепочке доверия — см.
Цепочка доверия и
Центры сертификации.Кроме того, сервер может опционально
проверить личность клиента — например, прокси-сервер компании может
аутентифицировать всех сотрудников, каждый из которых может иметь свой уникальный
сертификат, подписанный компанией.
Наконец, с шифрованием и аутентификацией, протокол TLS
также предоставляет собственный механизм формирования сообщений и подписывает каждое сообщение
с кодом аутентификации сообщения (MAC). Алгоритм MAC — односторонний
криптографическая хеш-функция (фактически контрольная сумма), ключи к которой
согласовываются обоими одноранговыми узлами.Всякий раз, когда отправляется запись TLS,
Значение MAC создается и добавляется для этого сообщения, а получатель
затем можно вычислить и проверить отправленное значение MAC, чтобы гарантировать, что сообщение
целостность и подлинность.
В совокупности все три механизма служат основой для безопасного
общение в сети. Все современные веб-браузеры поддерживают
множество наборов шифров, способных аутентифицировать как клиента, так и
сервер, и прозрачно выполнять проверки целостности сообщений для каждого
запись.
§Прокси, посредники, TLS и новые протоколы на
Интернет
Расширяемость и успех HTTP создали яркий
экосистема различных прокси и посредников в сети: кеш
серверы, шлюзы безопасности, веб-ускорители, фильтры содержимого и многие другие
другие. В некоторых случаях нам известно об их наличии (явное
прокси), а в других полностью прозрачны до конца
пользователь.
К сожалению, сам успех и наличие этих серверов
создал проблему для всех, кто пытается отклониться от HTTP / 1.Икс
протокол любым способом: некоторые прокси-серверы могут просто передавать новый HTTP
расширения или альтернативные форматы проводов, которые они не могут интерпретировать, другие
могут продолжать слепо применять свою логику, даже если они не должны этого делать, и
некоторые, например устройства безопасности, могут предполагать наличие злонамеренного намерения, если
здесь ничего нет.
Другими словами, на практике отклонение от четко определенного
семантика HTTP / 1.x на порту 80 часто приводит к ненадежным развертываниям:
у некоторых клиентов нет проблем, у других же возникают непредсказуемые и непредсказуемые
трудно воспроизводимое поведение — e.г. один и тот же клиент может видеть разные
поведения при миграции между разными сетями.
Из-за такого поведения появились новые протоколы и расширения HTTP, такие как
поскольку WebSocket, HTTP / 2 и другие должны полагаться на установку HTTPS
туннель для обхода промежуточных прокси и обеспечения надежного
модель развертывания: зашифрованный туннель скрывает данные от всех
посредники. Если вы когда-нибудь задумывались, почему большинство руководств по WebSocket
скажет вам использовать HTTPS для доставки данных мобильным клиентам, это
Почему.
§HTTPS везде
Незашифрованная связь — через HTTP и другие протоколы — создает большой
количество уязвимостей конфиденциальности, безопасности и целостности. Такие
обмены подвержены перехвату, манипуляции и
олицетворение и может раскрыть учетные данные пользователей, историю, личность и
другая конфиденциальная информация. Наши приложения должны защищать себя,
и наши пользователи против этих угроз путем доставки данных по HTTPS.
- HTTPS защищает целостность веб-сайта
Шифрование предотвращает вторжение злоумышленников в обмен
данные — например, переписывание контента, внедрение нежелательных и вредоносных
контент и так далее.- HTTPS защищает конфиденциальность и безопасность пользователя
Шифрование не позволяет злоумышленникам прослушивать обмен
данные. Каждый незащищенный запрос может раскрыть конфиденциальную информацию о
пользователь, и когда такие данные собираются по нескольким сеансам, может
использоваться для деанонимизации их личности и раскрытия других конфиденциальных
Информация.Вся активность просмотра, с точки зрения пользователя,
следует считать конфиденциальными и конфиденциальными.- HTTPS обеспечивает широкие возможности в Интернете
Растущее число новых функций веб-платформы, таких как доступ
геолокация пользователей, фотографирование, запись видео, включение офлайн
взаимодействие с приложением и многое другое требует явного согласия пользователя, что в
очередь, требует HTTPS. Предоставляемые гарантии безопасности и целостности
по HTTPS — важные компоненты для обеспечения безопасности пользователя
разрешение рабочего процесса и защита своих предпочтений.
Чтобы продолжить, как Internet Engineering Task Force (IETF)
Совет по архитектуре Интернета (IAB) выпустил руководство для
разработчиков и разработчиков протоколов, которые настоятельно рекомендуют
HTTPS:
По мере того, как наша зависимость от Интернета растет, риски и
ставки для всех, кто на это полагается. В итоге это наш
ответственность как разработчиков приложений, так и пользователей за обеспечение
что мы защищаем себя, разрешая HTTPS повсюду.
Стандарт только для HTTPS
опубликованный Управлением управления и бюджета Белого дома, является
отличный ресурс для дополнительной информации о необходимости HTTPS, и
практические советы по его развертыванию.
§Давайте
Зашифровать
Распространенное возражение и препятствие на пути к широкому внедрению
HTTPS был требованием для покупки сертификатов у одного из
доверенные органы — см. Цепь доверия и
Центры сертификации.Проект Let’s Encrypt запущен в 2015 году.
решает эту конкретную проблему:
«Let’s Encrypt — бесплатный, автоматизированный и открытый сертификат.
авторитет, предоставленный вам исследовательской группой Internet Security
(ISRG). Цель Let’s Encrypt и протокола ACME —
позволяют настроить HTTPS-сервер и получить его автоматически
получить сертификат, доверенный браузеру, без участия человека
вмешательство.»
Посетите веб-сайт проекта, чтобы узнать, как настроить его самостоятельно
сайт. Нет никаких ограничений, теперь любой может получить доверенный
сертификат для своего сайта, бесплатно.
§TLS
Рукопожатие
Прежде, чем клиент и сервер смогут начать обмен данными приложения
через TLS необходимо согласовать зашифрованный туннель: клиент и
сервер должен согласовать версию протокола TLS, выберите
ciphersuite и при необходимости проверьте сертификаты.К сожалению, каждый из
для этих шагов требуются новые пакеты (рис. 4-2) между клиентом и
сервер, который добавляет автозагрузку
.
STARTTLS против SSL против TLS за 5 минут
С таким количеством аббревиатур, связанных с шифрованием электронной почты, нетрудно заблудиться. Вряд ли электронное письмо отправляется без SSL или TLS. STARTTLS часто ассоциируется с ними, а STLS то и дело появляется. Как насчет ECC и RSA? Оставим их на следующий раз. Присоединяйтесь к нам на этот раз, чтобы обсудить роль SSL / TLS и STARTTLS в шифровании электронной почты.
SSL и TLS — о чем они все?
Как вы можете прочитать в нашей статье о безопасности SMTP, этот протокол не защищен по умолчанию.Таким образом, злодеям в Интернете довольно легко перехватить электронную почту и использовать конфиденциальную информацию. К счастью, существуют методы шифрования, которые немного усложняют их жизнь.
SSL (Secure Socket Layer) и его преемник TLS (Transport Layer Security) — это два криптографических протокола, используемых при передаче электронной почты. Оба полагаются на набор закрытых и открытых ключей для превращения сообщений в бесполезные строки символов. Если на каком-либо этапе такое электронное письмо будет перехвачено, оно не принесет никакой пользы тем, кто поставил под угрозу вашу безопасность.
SSL был первоначально разработан Netscape в 1995 году и быстро внедрен в популярные в то время почтовые клиенты (включая их собственный клиент). Четыре года спустя был представлен новый стандарт TLS, предлагающий более надежный профиль безопасности.
SSL с тех пор устарел, но все еще широко используется вместе со своим младшим братом. Фактически, оба имени используются взаимозаменяемо, и вы часто можете найти ссылку на SSL при обращении к TLS.Термин «SSL / TLS» также широко используется.
Какова роль STARTTLS?
STARTTLS — это не протокол, а команда протокола электронной почты. Он используется, чтобы сообщить почтовому серверу, что почтовый клиент (например, Gmail, Outlook и т. Д.) Хочет обновить существующее небезопасное соединение до безопасного, используя SSL или TLS.
Обратите внимание, что имя STARTTLS не означает, что можно установить только TLS-соединение. SSL также можно использовать с этой командой.
STARTTLS, кроме SMTP, также используется с протоколом IMAP, традиционно используемым для получения писем с почтового сервера.POP3, другой протокол для получения электронной почты, использует аналогичную команду под названием STLS.
Как работают TLS / SSL и STARTTLS?
Чтобы понять роль шифрования при передаче электронной почты, нам нужно вкратце объяснить, что такое «рукопожатие». Точно так же, как люди во многих культурах, как правило, пожимают друг другу руки в начале разговора, почтовые клиенты и серверы также следуют аналогичному ритуалу.
Когда электронное письмо отправлено, клиент обращается к серверу, чтобы проверить его надежность.Он сообщает, какие версии SSL / TLS совместимы, а также способ шифрования, которого можно ожидать от него. Сервер отвечает своим цифровым сертификатом, чтобы подтвердить свою личность. После проверки обе стороны генерируют и обмениваются уникальным ключом, который теперь будет использоваться для расшифровки сообщений.
Для того, чтобы произошло «рукопожатие», сначала необходимо установить соединение между клиентом и сервером. По умолчанию соединение SMTP не защищено и поэтому уязвимо для атак. Вот почему обе стороны будут пытаться установить безопасное соединение.Есть два подхода:
- с оппортунистическим SSL / TLS (он же явный SSL / TLS), клиент выполнит команду STARTTLS для обновления соединения до зашифрованного. Если сервер совместим и ошибок не возникает, будет установлено защищенное соединение TLS или SSL. Если что-то не удается, будет установлена передача в виде обычного текста.
- с принудительным SSL / TLS (он же неявный SSL / TLS), клиент попытается установить безопасное соединение, не спрашивая сервер о его совместимости.В случае успеха будет установлено безопасное соединение и последует рукопожатие. Если сервер несовместим или время ожидания соединения истекло, передача будет прервана.
Оба широко используются в наши дни и используют выделенные порты для этих передач.
Какие порты используются для неявного и явного SSL / TLS?
В течение многих лет порт 25 использовался по умолчанию как для отправки электронных писем на MTA (почтовые серверы), так и для их ретрансляции между MTA. Со временем это привело к тому, что через этот порт было отправлено огромное количество спама (и так оно и есть).
С тех пор было анонсировано
новых портов, а 25 были ограничены в основном для целей ретрансляции SMTP. Порт 587 стал самым популярным вариантом для отправки по протоколу SMTP.
Хотя этот порт не требует использования STARTTLS, платформы, использующие его, в большинстве случаев требуют. Кроме того, они также требуют имени пользователя и пароля для аутентификации, что еще больше затрудняет подделку реальных учетных записей. Если вы хотите использовать явный SSL / TLS, вам следует выбрать порт 587. В качестве альтернативы также обычно используется порт 2525.
В течение короткого периода времени порт 465 был рекомендованным портом для отправки электронной почты. Это решение было быстро отменено в пользу порта 587, но многие клиенты и серверы уже реализовали его. Таким образом, он стал обычной альтернативой 587 для тех, кто желает использовать неявный SSL / TLS (принудительное зашифрованное соединение, а не попытки обновить его с помощью STARTTLS).
В наши дни многие почтовые клиенты, Gmail и Yahoo! включены, используйте порт 465 (для неявного SSL / TLS) и 587 (для явного SSL / TLS), в то время как другие ограничивают себя только 587.
Тем не менее, все должно измениться, поскольку предпринимаются дальнейшие попытки принудительно использовать TLS как на клиентах, так и на серверах. В 2018 году Инженерная группа Интернета (IETF) рекомендовала использовать неявный TLS через порт 465. Время покажет, станет ли STARTTLS излишним в один прекрасный день или оба подхода будут использоваться рука об руку в ближайшие годы.
Подробнее о портах SMTP читайте в другой нашей статье.
IMAP и POP (в основном POP3) также используют разные порты для неявного и явного SSL / TLS.IMAP получает электронные письма через порт 143, когда STARTTLS установлен, и через порт 993, когда используется неявный SSL / TLS. POP использует порты 110 и 995 соответственно.
История версий SSL / TLS
Как мы упоминали ранее, протокол SSL устарел уже несколько лет, и TLS считается наиболее надежным средством шифрования электронной почты. Несмотря на это, некоторые платформы все еще используют SSL, несмотря на его уязвимости.
Как вы уже знаете, SSL и TLS взаимозаменяемы.Таким образом, нередко можно увидеть, что клиент или сервер предлагает своим пользователям новейшее шифрование SSL. Но не стоит отчаиваться. Вероятно, это TLS, который обеспечивает их передачу. Однако быстрое исследование не повредит.
Вот сводка всех версий SSL / TLS, опубликованных на сегодняшний день:
| Протокол | Год публикации | Текущее состояние |
| SSL 1.0 | Не публиковалось | Не публиковалось |
| SSL 2.0 | 1995 | Не рекомендуется с 2011 г. |
| SSL 3.0 | 1996 | Не рекомендуется с 2015 г. |
| TLS 1.0 | 1999 | Будет прекращено в 2020 г. |
| TLS 1.1 | 2006 | Будет прекращено в 2020 г. |
| TLS 1,2 | 2008 | Активно поддерживается |
| TLS 1,3 | 2018 | Активно поддерживается |
SSL 1.0 никогда не публиковался, так как серьезные недостатки безопасности были обнаружены еще до того, как о нем было объявлено. В результате SSL 2.0 стал первым широко доступным протоколом.
С выпуском TLS 1.3 в 2018 году первые две версии TLS должны быть устаревшими. Если вы собираетесь выбрать поставщика и сравниваете разные предложения, убедитесь, что ваш сервис работает на TLS 1.2 или новее.
Подведение итогов
Имейте в виду, что даже с такой древней технологией, как SMTP, все может измениться довольно быстро.Может быть представлена новая версия TLS или даже совершенно другой протокол. Некоторые порты могут стать избыточными, в то время как другие станут популярными. Когда это произойдет, мы обязательно обновим статью, но постараемся всегда быть в курсе последних новостей и тенденций в отрасли.
Следите за нашим блогом, и вы узнаете много нового об отправке электронной почты, протоколах и подходах. Кроме того, попробуйте Mailtrap бесплатно и никогда больше случайно не спамите своих клиентов. Береги себя!
Если вам понравилась эта статья, поделитесь ею и поделитесь ею.Мы будем очень признательны.
.