На протяжении более трех десятилетий протоколы SSL и TLS защищают миллиарды онлайновых транзакций. То, что началось как амбициозный проект безопасности компании Netscape в 1994 году, превратилось в сегодняшние сложные стандарты шифрования. История SSL насчитывает шесть основных версий протокола, бесчисленные улучшения в области безопасности и фундаментальные изменения в нашем представлении о веб-безопасности.
Понимание версий SSL/TLS — это не просто знание того, какие протоколы устарели. Речь идет о том, чтобы понять, как каждая уязвимость, атака и прорыв сформировали нынешний ландшафт, в котором TLS 1.3 обеспечивает безопасность 95% зашифрованного веб-трафика.
Оглавление
- Рождение протокола SSL в Netscape
- SSL 3.0 — полная переработка протокола
- TLS 1.0 — Эра стандартизации IETF
- TLS 1.1 и TLS 1.2 — дополнительные улучшения безопасности
- TLS 1.3 — современный стандарт безопасности
- Распространенные заблуждения о версионировании SSL/TLS
- Роль центров сертификации в эволюции SSL/TLS
- Вехи развития отрасли, определившие принятие HTTPS
- Основные уязвимости в системе безопасности, которые способствовали эволюции протоколов
- Будущее протоколов SSL/TLS
Сэкономьте 10% на SSL-сертификатах, сделав заказ в SSL Dragon сегодня!
Быстрая выдача, надежное шифрование, 99,99% доверия к браузерам, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10
Рождение протокола SSL в Netscape
SSL 1.0 — Неизданная первая попытка (1994)
Тахер Эльгамал, главный научный сотрудник компании Netscape, разработал оригинальный протокол Secure Sockets Layer в 1994 году. Но SSL 1.0 так и не увидел свет. Исследователи безопасности из Netscape обнаружили критические недостатки еще до публичного релиза — уязвимости достаточно серьезные, чтобы отменить всю версию.
Урок был очевиден: криптографические протоколы нуждаются в тщательной проверке перед внедрением. Эта неудача, хотя и разочаровывающая, заложила основу для тщательного тестирования, которое определит будущие разработки SSL и TLS.
SSL 2.0 — первый публичный выпуск (1995 г.)
Когда появился SSL? Ответ — в феврале 1995 года, когда компания Netscape включила SSL 2.0 в комплект поставки Navigator 1.1. В этой версии SSL были представлены основополагающие концепции, которые используются и по сей день: рукопожатие SSL процесс, цифровые сертификатыX.509 и аутентификация сервера.
Но у SSL 2.0 были проблемы. Он полагался на MD5 для аутентификации сообщений, использовал один и тот же ключ для шифрования и аутентификации, и в нем отсутствовала защита самого рукопожатия. Злоумышленники могли понизить уровень соединения до более слабого 40-битного шифрования так, чтобы ни одна из сторон этого не заметила.
IETF официально отказалась от SSL 2.0 в марте 2011 года в RFC 6176. К тому времени большинство серверов уже перешли на новый уровень.
SSL 3.0 — полная переработка протокола
Основные усовершенствования по сравнению с SSL 2.0 (1996)
Пол Кочер, Фил Карлтон и Алан Фрайер полностью переписали протокол SSL для версии 3.0, выпущенной в ноябре 1996 года. Они отделили транспортный уровень данных от уровня сообщений, добавили поддержку обмена ключами Диффи-Хеллмана и шифр-сюиты Fortezza, а также реализовали надлежащий 128-битный ключ.
В SSL 3.0 также было введено сжатие записей и более гибкое согласование набора шифров. Позже IETF задокументировала его в RFC 6101, признав его историческую важность. На протяжении почти двух десятилетий SSL 3.0 служил запасным вариантом для устаревших систем.
Уязвимость POODLE и устаревание SSL 3.0
В октябре 2014 года команда безопасности Google обнаружила POODLE (Padding Oracle on Downgraded Legacy Encryption). Атака использовала то, как SSL 3.0 обрабатывает набивку в режиме cipher block chaining (CBC). Злоумышленники могли расшифровывать защищенные HTTP-куки, заставляя браузеры переходить с TLS на SSL 3.0.
IETF отреагировала быстро, отменив SSL 3.0 в июне 2015 года в RFC 7568. Это ознаменовало конец эры SSL. Когда люди спрашивают о«последней версии SSL«, ответом будет SSL 3.0, потому что сам SSL больше никогда не обновлялся. Эстафета перешла к Transport Layer Security.
TLS 1.0 — Эра стандартизации IETF
Переход от SSL к TLS (1999)
К концу 1990-х годов IETF хотела стандартизировать протоколы интернет-безопасности. Тим Диркс и Кристофер Аллен возглавили работу по превращению SSL в открытый стандарт. Компании Microsoft и Netscape вели переговоры о наименовании — «Безопасность транспортногоуровня» стала компромиссом, который закрепился.
TLS 1.0, опубликованный как RFC 2246 в январе 1999 года, был, по сути, SSL 3.1 с новым именем. Различия были незначительными, но достаточно существенными, чтобы нарушить совместимость. Вы не могли смешивать клиентов SSL 3.0 с серверами TLS 1.0 без тщательной реализации.
Основные отличия от SSL 3.0
В TLS 1.0 была усовершенствована базовая криптография. Он заменил собственный код аутентификации сообщений (MAC) SSL на HMAC, стандартизированный криптографами. Функция извлечения ключа изменилась, чтобы предотвратить некоторые теоретические атаки. Система оповещений расширилась за счет более специфических кодов ошибок.
TLS 1.0 также требует поддержки шифр-сюитов DSS/DH, обеспечивая реализацию большей гибкостью. Эти изменения казались незначительными, но они отражали переход от собственной разработки к стандартизации под руководством сообщества. Теперь IETF контролировала развитие протокола.
TLS 1.1 и TLS 1.2 — дополнительные улучшения безопасности
Защита TLS 1.1 от CBC-атак (2006)
Выпущенный в апреле 2006 года в RFC 4346, TLS 1.1 устранил специфические уязвимости CBC. Самое большое изменение? Явные векторы инициализации (IVs) заменили неявные IVs. Это не позволило злоумышленникам предугадать IV и использовать цепочку блоков шифра.
TLS 1.1 также улучшил обработку ошибок для записей с набивкой. Вместо того, чтобы выявлять конкретные ошибки заполнения, он возвращает общее предупреждение bad_record_mac. Эти изменения защитили от BEAST (Browser Exploit Against SSL/TLS), обнаруженного несколько лет спустя, в 2011 году.
Были созданы реестры параметров IANA, что сделало управление наборами шифров более организованным. Однако внедрение происходило медленно. Многие организации полностью отказались от TLS 1.1, ожидая более существенных улучшений TLS 1.2.
TLS 1.2 Улучшенная гибкость (2008)
Когда был выпущен TLS 1.2? В августе 2008 года, в документе RFC 5246. Это обновление принесло самые значительные изменения со времен SSL 3.0. Протокол перешел от жестко закодированных комбинаций MD5/SHA-1 к псевдослучайным функциям (PRF), задаваемым шифром. SHA-256 стал новым стандартом.
В TLS 1.2 появились режимы шифрования с аутентификацией и дополнительными данными (AEAD), включая AES-GCM и ChaCha20-Poly1305. Это дало реализации гибкость в выборе алгоритмов хэширования и подписи. Эта возможность адаптации оказалась крайне важной по мере развития криптографических стандартов.
Этот протокол широко используется и сегодня. Около 95,8% веб-сайтов по-прежнему поддерживают TLS 1.2, часто работая вместе с TLS 1.3. В марте 2021 года IETF совместно отменила TLS 1.0 и 1.1 в RFC 8996, сделав TLS 1.2 минимально приемлемым стандартом.
Сэкономьте 10% на SSL-сертификатах, сделав заказ в SSL Dragon сегодня!
Быстрая выдача, надежное шифрование, 99,99% доверия к браузерам, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10
TLS 1.3 — современный стандарт безопасности
Пять лет в разработке (2018)
Для появления TLS 1.3 потребовалось десятилетие. IETF опубликовала RFC 8446 в августе 2018 года после 28 черновиков и длительного сотрудничества. В основе редизайна лежали простота и производительность. Рабочая группа удалила устаревшие функции, упростила рукопожатие и устранила целые классы уязвимостей.
Google, Mozilla, Microsoft и Apple быстро добавили поддержку. К 2019 году все основные браузеры могли согласовывать соединения TLS 1.3. Cloudflare и другие провайдеры CDN включили его по умолчанию. Последняя версия TLS не только повысила безопасность, но и сделала зашифрованные соединения более быстрыми.
Революционные улучшения в области безопасности
В TLS 1.3 удалено все сломанное или ослабленное. Наборы шифров SHA-1, MD5, RC4, DES и 3DES? Исчезли. Статический обмен ключами RSA и Диффи-Хеллмана? Устранены. Теперь протокол требует идеальной прямой секретности используя эфемерный Diffie-Hellman для всех соединений.
Рукопожатие изменилось коренным образом. Каждое сообщение после ServerHello шифруется, скрывая переговоры от посторонних глаз. Функция извлечения ключа перешла на HMAC-based Extract-and-Expand (HKDF), обеспечивая лучшие криптографические гарантии.
В TLS 1.3 также появился режим 0-RTT (zero round-trip time). Клиенты могут отправлять зашифрованные данные в первом сообщении ранее связавшимся с ними серверам, устраняя задержки при рукопожатии. Упрощенная машина состояний сделала реализацию менее подверженной ошибкам. ECC вошел в базовую спецификацию вместе с новыми алгоритмами подписи, такими как RSA-PSS.
Принятие и сосуществование в настоящее время
Какова последняя версия TLS? TLS 1.3 удерживает это звание. Но TLS 1.2 в ближайшее время никуда не денется. Организациям нужно время, чтобы обновить серверы, проверить совместимость и обновить клиентское программное обеспечение. Большинство сайтов, заботящихся о безопасности, теперь поддерживают обе версии, позволяя клиентам выбирать наилучший из доступных вариантов.
Сосуществование работает хорошо. Серверы согласовывают наивысшую взаимно поддерживаемую версию. Клиенты, которые не могут работать с TLS 1.3, возвращаются к TLS 1.2. Такой постепенный переход предотвращает катастрофы совместимости, которые были характерны для предыдущих переходов.
Распространенные заблуждения о версионировании SSL/TLS
Почему не существует TLS 2.0
Какова дата выхода TLS 2.0? Нет ни одного. TLS 2.0 не существует и никогда не будет существовать. IETF использует инкрементную версификацию: TLS 1.0, 1.1, 1.2, 1.3. Следующая версия, если она появится, будет TLS 1.4 или, возможно, TLS 2.0, но переход сразу к «TLS 2.0» после SSL 3.0 вызвал бы огромную путаницу.
Люди часто ожидают, что протоколы будут использовать основные номера версий (как программное обеспечение, которое переходит от версии 1 к версии 2). Но криптографические протоколы развиваются более консервативно, каждый выпуск основывается на предыдущем.
Терминология SSL и TLS
Попросите «SSL-сертификат», и Вы получите сертификат, который работает с TLS 1.2 и TLS 1.3. Индустрия по-прежнему использует «SSL» в маркетинге, потому что это знакомо. Даже несмотря на то, что текущая версия SSL технически не существует (SSL закончился на версии 3.0), этот термин прижился.
Такие центры сертификации, как DigiCert и Sectigo, продают «SSL-сертификаты», которые используют исключительно протокол TLS. Это сбивает с толку, но не причиняет вреда. Просто помните: когда кто-то упоминает SSL в 2026 году, он почти наверняка имеет в виду TLS.
Роль центров сертификации в эволюции SSL/TLS
Разработка типов валидации
Ранние SSL-сертификаты были дорогими и медленными. Бизнес-валидация требовали нескольких дней или недель ручной проверки. В 2002 году компания GeoTrust представила Удостоверение доменовавтоматизировав этот процесс путем проверки владения доменом через электронную почту или записи DNS.
Сертификатырасширенной проверки появились в 2007 году, обещая наивысшую гарантию с зелеными адресными строками в браузерах. Компания Let’s Encrypt начала свою работу в 2015 году, предлагая бесплатные сертификаты Domain Validation с помощью автоматической выдачи. За ней последовала компания Cloudflare с собственной программой бесплатных сертификатов. Эти изменения демократизировали HTTPSсделав шифрование доступным для небольших сайтов.
Сокращение срока действия сертификата
Сроки действия сертификатов продолжали сокращаться. В 2015 году базовые требования снизили максимальный срок действия с пяти лет до трех. Два года стали пределом в 2018 году. В 2020 году Safari от Apple ввел ограничение в один год, что заставило другие браузеры последовать его примеру.
Теперь индустрия стремится к еще более короткому жизненному циклу сертификатов. Форум CA/Browser Forum определил четкое сокращение сроков действия сертификатов: 200 дней с 15 марта 2026 года,100 дней с 15 марта 2027 года и всего 47 дней к 15 марта 2029 года.
Этот сдвиг делает ручное управление сертификатами непрактичным, подталкивая организации к автоматизированным решениям, таким как Certificate-as-a-Service (CaaS) на базе ACME, где проверка, выдача и продление сертификатов осуществляются автоматически.
Вехи развития отрасли, определившие принятие HTTPS
Google продвигает HTTPS
В августе 2014 года Google объявил HTTPS сигналом ранжирования. Это единственное решение изменило историю SSL. У вебмастеров, которые игнорировали шифрование, внезапно появились деловые причины для беспокойства. К 2016 году половина всего веб-трафика была зашифрована.
Chrome 68 сделал следующий шаг в июле 2018 года, пометив все HTTP-сайты как «Небезопасно.» Предупреждение появлялось в адресной строке для каждой незашифрованной страницы. Сегодня более 95% веб-трафика использует HTTPS. Google превратил шифрование из лучшей практики безопасности в требование бизнеса.
Эволюция индикаторов безопасности браузеров
Помните зеленую адресную строку Extended Validation? Ее больше нет. Chrome убрал ее в 2020 году после того, как исследования показали, что пользователи не замечают и не понимают ее. Исчезает и сам значок замка, его заменяют нейтральные индикаторы, которые скорее нормализуют HTTPS, чем поощряют его.
Chrome 69 убрал текст «Secure», оставив только висячий замок. Нынешние браузеры делают акцент на предупреждении о небезопасных соединениях, а не на восхвалении безопасных. Послание: HTTPS — это ожидание по умолчанию, а не что-то особенное.
Основные уязвимости в системе безопасности, которые способствовали эволюции протоколов
Известные атаки на SSL/TLS
POODLE поразил SSL 3.0 в 2014 году, эксплуатируя уязвимости оракула в режиме CBC. Злоумышленники могли расшифровывать защищенные файлы cookie, понижая уровень соединения и многократно изменяя шифротекст. Атака уничтожила SSL 3.0 в течение нескольких месяцев.
BEAST нацелился на TLS 1.0 в 2011 году, используя аналогичную слабость CBC. Злоумышленники могли расшифровывать HTTPS-куки, внедряя код на стороне клиента и наблюдая за зашифрованными ответами. Для устранения проблемы потребовалось внедрить явные IVs в TLS 1.1.
В 2013 году компания BREACH злоупотребила сжатием HTTP. Атака не была направлена на сам протокол TLS, но показала, как решения на прикладном уровне влияют на безопасность. Heartbleed, обнаруженный в 2014 году, раскрыл критическую OpenSSL ошибку в реализации, которая приводила к утечке закрытых ключей и пользовательских данных.
Извлеченные уроки
Каждая уязвимость доказывает одно и то же: обратная совместимость опасна. Сохранение старых протоколов для устаревших систем создает векторы атак. Индустрия научилась агрессивно устаревать и принудительно обновляться.
Исследователи безопасности тоже заслуживают благодарности. Публичное раскрытие уязвимостей ускорило процесс усовершенствования. Если бы не POODLE, SSL 3.0 мог бы и сегодня скрываться в конфигурациях серверов.
Будущее протоколов SSL/TLS
Постквантовая криптография
Квантовые компьютеры угрожают существующим алгоритмам шифрования. Криптография RSA и эллиптических кривых может устареть, когда квантовые машины достигнут достаточного масштаба. NIST занимается стандартизацией постквантовых алгоритмов, разработанных для противостояния квантовым атакам.
TLS потребуются обновления для поддержки этих квантовоустойчивых алгоритмов. Переход будет нелегким, постквантовая криптография использует более крупные ключи и другие математические подходы. Но эволюция протокола, которая привела нас от SSL 2.0 к TLS 1.3, доказала, что сообщество может справиться с серьезными переходами.
Развивающиеся технологии
DTLS (Datagram Transport Layer Security) расширяет TLS на UDP-соединения. QUICразработанный компанией Google и стандартизированный IETF, интегрирует шифрование непосредственно в транспортный уровень. Эти протоколы опираются на криптографические основы TLS, при этом адаптируясь к различным условиям использования.
Альтернативы на основе блокчейна, такие как Remme, экспериментируют с распределенной PKI. Центры сертификации продолжают развиваться, автоматизируя все больше процессов и поддерживая более короткие сроки действия. Что будет после TLS 1.3? Скорее всего, это будут постепенные улучшения, а не полная переделка. В TLS 1.3 большинство вещей было сделано правильно.
Оставайтесь в курсе событий с сертификатами SSL Dragon, готовыми к TLS 1.3
Понимать эволюцию протоколов — это одно. Реализация современных стандартов шифрования — совсем другое. SSL Dragon предоставляет цифровые сертификаты, полностью совместимые с TLS 1.3 и TLS 1.2 и поддерживающие новейшие криптографические протоколы и наборы шифров.
Мы предлагаем быструю выдачу сертификатов, надежное шифрование и 99,99% доверия к браузерам благодаря партнерству с ведущими центрами сертификации, включая DigiCert, Sectigo и GeoTrust. Наши автоматизированные решения по управлению сертификатами помогут Вам справиться с предстоящим 47-дневным жизненным циклом без проблем с ручным продлением.
Переходите с устаревших протоколов? Наша специальная команда поддержки поможет Вам осуществить переход. На каждую покупку предоставляется 25-дневная гарантия возврата денег. Изучите наш портфель сертификатов сегодня и защитите свою инфраструктуру с помощью последней версии TLS.
Сэкономьте 10% на SSL-сертификатах при заказе сегодня!
Быстрая выдача, надежное шифрование, 99,99% доверия к браузеру, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10
