Хабр, это доклад с одного из «не главных» залов Highload++ 2016. Артём ximaera Гавриченков, технический директор Qrator Labs, рассказывает про прикладное шифрование, в том числе, в высоконагруженных проектах. Видео и презентация в конце поста — спасибо Олегу Бунину.
Приветствую! Мы продолжаем находиться на сессии про HTTPS, TLS, SSL и всё такое.
То, о чём я сейчас буду говорить — не какой-то туториал. Как говорил мой преподаватель в университете по базам данных, Сергей Дмитриевич Кузнецов: «Я не буду учить вас настраивать Microsoft SQL сервер — пусть это делает Microsoft; не буду учить вас настраивать Oracle — пусть это делает Oracle; не буду учить вас настраивать MySQL — делайте это сами».
Точно так же и я не буду учить вас настраивать NGINX — это всё есть на сайте у Игоря Сысоева. Что мы обсудим, так это некий общий взгляд на проблематику и на возможности для решения проблем, которые возникают при внедрении шифрования на публичных сервисах.
Небольшой экскурс в совсем новейшую историю: как известно, в последнее время тема шифрования публичных сервисов поднялась на какой-то новый уровень — она на слуху и слайд выше отображает, как примерно это происходило.
Началось всё в 2010 году, на мой взгляд, с изобретением протокола SPDY Гуглом, де-юре «Спиди» мог работать без шифрования, однако де-факто его реализация зависела от расширения NPN (Next Protocol Negotiation), которое было в TLS’е — а в стандартном протоколе транспортного уровня TCP его не было. Поэтому де-факто без шифрования SPDY не работал.
Долгое время в индустрии шли споры и оживлённые дискуссии на темы: «Помогает ли Спиди?»; «Ускоряет ли он работу?»; «Снижает ли он нагрузку или нет?» За это время многие успели его внедрить и многие люди оказались с, так или иначе, внедрённым шифрованием.
Прошло 4 года и сотрудники поиска Google в своём блоге объявили, что с нынешних (2014 год) пор наличие у сайта HTTPS будет улучшать ранжирование сайта при выдаче в поиске. Это стало серьёзным ускорением — о безопасности пользователей думают не все, а вот о месте в поисковой выдаче думают практически все.
Поэтому, начиная с этого момента HTTPS начал использоваться теми, кто раньше про него и не думал, и не видел для себя такой проблемы.
Спустя год был финализирован и опубликован стандарт HTTP/2, в котором опять же не было записано требование о том, что он должен работать только поверх TLS. Однако, де-факто, каждый современный браузер в HTTP/2 без TLS не умеет. И, наконец, в 2016-м году ряд компаний при поддержке «Фонда электронных рубежей» основал некоммерческий проект Let’s Encrypt который выдаёт всем сертификаты автоматизированно, быстро и бесплатно.
Примерно так выглядит график числа выданных активных сертификатов Let’s Encrypt, шкала в миллионах. Внедрение идёт очень активно, ниже другая статистика — из телеметрии Firefox.
За год с ноября 2015 года по ноябрь 2016 г., число веб-страниц посещённое пользователями Firefox на HTTPS, в сравнении с HTTP, выросло на четверть-треть. Скажем большое спасибо за это Let’s Encrypt и, кстати, у них началась (и уже закончилась) краудфандинговая кампания, так что не проходите мимо.
Это только одна сторона истории — говоря про неё, нельзя не упомянуть и вторую нить.
Она касается откровений всем известого сотрудника корпорации Booz Allen Hamilton. Кто знает о ком я говорю? Эдварде Сноудене, да.
На тот момент это послужило некоторым маркетингом в сторону HTTPS: «За нами следят, давайте защищать своих пользователей». В том числе компания Google после того как были опубликованы очередные откровения по-поводу того, что АНБ «вроде как» перехватывала внутренние коммуникации в датацентре Google. Инженеры компании написали в своём блоге матерные слова в отношении правительства США и зашифровали и все внутренние коммуникации в том числе.
Соответственно, примерно через месяц был опубликован пост про учёт HTTPS при ранжировании — какие-то конспирологи могут видеть в данном событии какую-то связь.
С тех времён, то есть 2013-2014 года, у нас появилось целых два фактора для продвижения TLS и он реально стал популярен. Он стал популярен настолько, что как выяснилось — инфраструктура и библиотеки шифрования были не готовы к такой популярности.
В 2014 году было обнаружено целых две критических уязвимости в самой популярной, на тот момент, библиотеке SSL. Кто-то даже попытался перейти по этому поводу на другую популярную альтернативу — TLS, которая оказалась даже ещё хуже. IETF в феврале 2015 года даже выпустил отдельный RFC, в котором описывал известные атаки на TLS и датаграммный TLS (поверх UDP). Это документальные свидетельства высокого оптимизма рабочей группы IETF, потому что в феврале 2015 года они объявили о том, что «сейчас подведут итог всем атакам», а с тех пор их произошло ещё три.
Причём самая первая из них была найдена спустя 20 дней после опубликования RFC. На самом деле эта история вот про что — в дисциплине управления проектами можно встретить упоминание такого термина, как «технологическая задолженность».
Условно говоря, если вы решаете какую-то задачу и вы понимаете, что её решение займёт 6 месяцев, но нужно за 3, а если вот тут поставить костыль, то в принципе можно сделать и за три месяца — фактически, в этот момент вы берёте у вселенной время в долг. Потому что тот костыль, который будет подставлен, рано или поздно развалится — вам придётся его исправлять. Если таких костылей наберётся очень много, то произойдёт «технологический дефолт» и вы просто не сможете делать ничего нового пока не разберёте всё старое.
Шифрование в том виде, в каком оно было в конце 2000-х годов, сделали энтузиасты. Но когда народ реально начал этим пользоваться, выяснилось что косяков очень много и их нужно как-то исправлять. И самый главный косяк — это информированность целевой аудитории, то есть вас, о том, как это всё работает и как это настраивать.
Давайте пройдёмся и разберём основные моменты с прицелом, как раз, на крупный сетап.
Начнём с банальностей. Чтобы поднять сервис — нужно его настроить, чтобы его настроить — нужен сертификат, чтобы сертификат иметь его необходимо купить. У кого?
Протоколы SSL и TLS включают в себя, естественно, инфраструктуру публичных ключей. Есть набор центров сертификации, соответственно, если у вас есть сервис — у него должен быть сертификат, который может быть подписан либо центром сертификации либо кем-то, кого оный центр сертификации подписал. То есть должна быть выстроена непрерывная цепочка от вас до кого-то, кому браузер и пользовательское устройство доверяют. До кого? Для примера:
Я скачал ванильный Firefox и там сертификатов порядка 100 штук — доверенных центров сертификации. То есть выбор у вас большой, в смысле покупки сертификата.
Что это за сотня компаний
Согласно идеологии этим компаниям можно доверять потому что подписывание сертификатов, слежение за безопасностью — основной их бизнес. Манкировать этим сложно, иначе компания просто обанкротится — простая экономическая модель. Это должны были быть относительно небольшие компании, которые не зависят от крупных корпораций, которые не зависят от правительств. Ну, не считая того, что некоторые из них и есть правительство, в частности японское, тайваньское и валенсийское.
А другие были куплены крупными корпорациями за обалденные суммы.
Таким образом, на сегодняшний день, мы не можем с уверенностью утверждать как ведут себя те или иные центры сертификации. Они должны были и должны до сих пор защищать свои интересы как игрока на рынке, как центра сертификации. Но, опять же, если вы являетесь государственным сотрудником или принадлежите крупной организации, то если к ней придёт крупный клиент который за большие деньги хочет что-то сделать — то вам приказывают это делать. Вопрос в том, что вы сможете с этим сделать.
Как же так вышло, что изначальная модель сейчас так странно работает? Почему эти компании, принадлежащие, например, министерству связи и коммуникаций КНР (которому ваш браузер доверяет) до сих пор остаются центрами сертификации?
Дело тут в том, что перестать быть центром сертификации достаточно сложно.
Наглядная история — центр сертификации под названием WoSign. Если я не ошибаюсь, с 2009 года он является доверенным центром сертификации во всех популярных браузерах и операционных системах. Он стал центром по достаточно правильной траектории пройдя аудит Ernst&Young (сейчас E&Y), организовал агрессивную маркетинговую компанию и раздавал сертификаты всем направо, и налево, и всё было хорошо.
В 2016 году сотрудники фонда Mozilla написали целую страницу в своей Wiki со списком тех или иных нарушений которые в разные моменты времени допускала WoSign. В основном эти нарушения датированы 2015-2016 годами.
В чём они заключались? Как известно, вы не можете получить сертификат для «левого» домена. Вы должны как-то доказать, что вы являетесь владельцем данного домена — как правило вы должны либо получить что-то по физической почте, либо разместить определённый токен на сайте по строго определённому адресу. WoSign по-крайней мере один раз выпустил сертификат для AliCDN, который не запрашивался самим AliExpress’ом (они пользуются услугами Symantec) — тем не менее сертификат был выпущен и опубликован.
WoSign позволял использовать непривилигированные порты для верификации — то есть любой пользователь (не только администратор) данного сервера мог получить сертификат для любого домена на этом сервере размещённого. WoSign позволял использовать домены 3, 4 и следующих уровней для верификации домена второго уровня. Таким образом исследователи, в рамках проверки WoSign на стойкость, сумели получить валидный сертификат для GitHub.
WoSign позволял использовать любые файлы, то есть указывать произвольный путь на сайте по которому будет размещён токен — таким образом исследователям удалось получить подписанные сертификаты для Google и Facebook.
Ну, и в принципе это всё ерунда, потому что при определённых условиях WoSign позволял выписывать любой сертификат для любого домена вообще без проверки (смех в зале).
После такого все мелочи отходят на задний план, но всего было Mozilla привела около 13 претензий. WoSign выпускал сертификаты задним числом, используя на сервере валидации софт который не имел патчей, в том числе обновления частей отвечающих за безопасность, долгие годы.
WoSign купила StartCom и отказалась публиковать какую бы то ни было информацию, что нарушает политику фонда Mozilla, но по-сравнению со всем остальным уже не так больно.
Каков итог?
В сентябре этого года WoSign был забанен в Chrome и Firefox на год, но ему до сих пор продолжает доверять Microsoft и операционная система Windows.
Нельзя просто так перестать быть центром сертификации.
И это мы говорим, на самом-то деле, про мелочь. Если вести разговор о том же Verisign (Symantec), то нужно понимать что нельзя просто так взять и отозвать корневой сертификат Symantec, потому что им подписан тот же AliExpress, им подписан Google, им подписан очень много кто и у пользователей начнутся проблемы с доступом к ресурсам. Поэтому так или иначе по щелчку пальцев, как это когда-то предполагалось, отозвать сертификат невозможно.
Большие центры сертификации, есть такое выражение, они "Too big to fail" — слишком большие, чтобы перестать существовать.
Альтернатива TLS’ному PKI (Public Key Infrastructure) есть, она называется DANE, построена вокруг DNSSEC’а, но у неё столько инфраструктурных проблем — в том числе с задержками и деплоем, что говорить о ней сейчас бессмысленно, нужно как-то с этим жить.
Как же с этим жить?
Я обещал дать совет по тому, как выбирать Certificate Authority. Исходя из всего сказанного мой совет следующий:
Берите бесплатно — большой разницы не будет.
Если есть API позволяющий автоматизировать выписывание и деплой сертификатов — замечательно.
Второй полезный совет на сегодняшний день (то есть мы говорим про распределённую структуру со множеством балансировщиков) — получите не один сертификат, а два или три сертификата. Купите один у Verisign, второй у польской Unizeto, а третий получите бесплатно у Let’s Encrypt. Это не сильно увеличит OPEX (операционные затраты), но серьёзно поможет вам в случае непредвиденных ситуаций, о которых мы ещё поговорим.
Вопрос сходу: «Вот, Let’s Encrypt не выписывает сертификаты extended validity (увеличенный срок действия и красивый зелёный значок в браузере), что с этим делать?» На самом деле это театр безопасности, потому что мало того, что на эти зелёные значки мало кто смотрит, так мобильный браузер в Windows Phone даже не умеет этот значок отображать. Пользователь не смотрит на присутствие значка в принципе, не говоря уже о его цвете.
Поэтому если вы не банк и ваш аудит безопасности не заставляет вас покупать extended validity — реальной пользы от него не будет.
Лучше покупайте сертификаты с кратким сроком действия, потому что если что-то произойдёт с Certificate Authority — у вас будет пространство для манёвра. Диверсифицируйтесь.
Давайте поговорим подробнее про время жизни сертификатов. У долгоживущих сертификатов (год — два — три) есть ряд плюсов. Например, пятая точка не болит, когда не нужно обновлять сертификат каждые 2-3 месяца — вы его один раз поставили и на три года забыли. Кроме того, центры сертификации обычно предоставляют значительные скидки тем, кто покупает сертификаты на год, три и пять лет.
На этом плюсы заканчиваются и начинаются минусы
Если что-то по сертификатам произошло не так, например вы потеряли приватный ключ и он достался кому-то ещё — в TLS есть механизм который позволяет отозвать сертификат назад. Называется CRL и OCSP, их целых две штуки. Проблема в том, что на текущий момент они оба работают в режиме soft fail, то есть если браузер не сумел подключиться к CRL-серверу и проверить статус сертификата то «и чёрт с ним» — сертификат якобы нормальный.
Адам Ленгли из Google сравнил soft fail CRL и OCSP с ремнём безопасности в автомобиле, который всё время натягивается, а когда вы попадаете в аварию — рвётся. Смысла в этом нет, потому что тот же злоумышленник, который может сделать man in the middle и подставить украденный ключ — он же может закрыть доступ к CRL и OCSP, так что работать данные механизмы просто не будут.
Hard fail CRL и OCSP, то есть те, которые будут отображать ошибку в случае недоступности CRL-сервера, сейчас не используются практически никем.
И снова про боль в пятой точке — да, она неизбежна. Но, честно говоря, вы всё-равно должны автоматизировать деплой сертификата. Деплоймент это просто то, что нужно сделать, потому что замена сертификата руками — это та же самая техническая задолженность.
Она не укусит вас моментально, но рано или поздно проблемы могут начаться.
Что позволяет автоматизированное управление сертификатами? Вы можете добавлять их, удалять и изменять одним движением пальца. Вы можете выпускать их с кратким сроком действия, вы можете использовать множество ключей, вы можете настроить авторизацию клиентов по сертификатам. Сможете очень легко и очень быстро обрабатывать ситуации из серии: «Опс, у нашего центра сертификации отозвали промежуточный сертификат». Это не теоретическая история — это случилось в октябре 2016 года.
Один из крупнейших CA — GlobalSign, с большой историей и очень надёжный, в октябре 2016 проводил технические работы по переклассировке корневых и промежуточных сертификатов… и случайно отозвал все свои промежуточные сертификаты. Инженеры достаточно быстро нашли проблему, но нужно понимать, что в CRL и OCSP входят все браузеры всех пользователей — это достаточно нагруженный сервис. GlobalSign как и все использует для этих целей CDN, которым был Cloudflare в случае GlobalSign и, по каким-то причинам, Cloudflare оказался не в состоянии оперативно обнулить кэш — неверные списки отозванных сертификатов продолжали расползаться по интернету в течение нескольких часов.
И кэшироваться в браузерах. Причём, кэш CRL и OCSP в браузере и операционной системе работают порядка четырёх дней. То есть четыре дня выводилось сообщение об ошибке при попытке захода на Wikipedia, Dropbox, Spotify и Financial Times — все эти компании пострадали. Конечно же, есть варианты более оперативного решения этой проблемы и они, как правило, заключаются в том, чтобы сменить центр сертификации и поменять сертификат — тогда всё будет хорошо. Но до этого ещё нужно дойти.
Заметьте, что в ситуации, когда всё зависит от CDN, всё зависит от посещаемости — то есть от того, успел ли на данной ноде CDN’а закэшироваться неверный ответ, сайты с высокой посещаемостью страдают больше, потому что вероятность намного выше.
Мы говорили о том, что «решить ситуацию просто — необходимо заменить сертификат», но сначала для этого надо понять, что происходит. Как выглядит ситуация с отозванными корневыми сертификатами с точки зрения администратора ресурса?
Прайм-тайм, всё хорошо, нагрузка ниже среднего — нет никаких проблем, в мониторинге ничего не вылезает… и при этом трафик упал на 30%. Проблема имеет распределённый характер и ловить её очень сложно — нужно понимать, что здесь вы зависите от вендора, не контролируя ни CRL, ни OCSP, поэтому происходит неведомая проклятая ерунда и вы не знаете, что делать.
Что помогает находить такие проблемы
Во-первых, если у вас много балансеров и на них сертификаты от разных вендоров (о чём мы говорили) — вы увидите корреляцию. Там где был сертификат от GlobalSign — там начались проблемы, на остальных балансировщиках всё хорошо — вот и связь.
Нужно понимать, что распределённых сервисов для проверки CRL и OCSP по состоянию на ноябрь 2016 не было. То есть не было сервиса одновременно достаточно распределённого чтобы мониторить Cloudflare и одновременно умеющего ходить в CRL и OCSP для произвольного домена.
Но у нас ещё есть инструмент под названием tcpdump, в котором также прекрасно видно, в чём проблема — сессии обрываются примерно на моменте “TLS server hello”, то есть очевидно что проблемы где-то в TLS’е, а это значит, что хотя бы примерно понятно куда смотреть.
Дополнительным плюсом того, что у вас на разных машинах находятся разные ключи, является то, что если один из них утёк — то вы хотя бы узнаете откуда. То есть сможете написать root cause analysis.
Некоторая идеология деплоймента говорит, что закрытый ключ вообще никогда не должен покидать машину, на которой он сгенерирован. Это некоторый «технологический нигилизм», но такая ситуация существует.
Возвращаясь к истории с GlobalSign’ом мы видим, что TLS до сих пор находится в авангарде технологий. Однако у нас всё ещё недостаточный инструментарий и всё ещё недостаточное понимание, отчего и будут возникать подобные проблемы.
И на поиск источника проблем могут быть потрачены часы, а когда она обнаружена — решать её нужно уже очень быстро. Поэтому — автоматизация менеджмента сертификатов.
Для этого требуется либо центр сертификации предоставляющий API — например Let’s Encrypt, который является хорошим выбором если вам не нужен wildcard-сертификат. В 80% случаев вам не нужен wildcard, так как он является в первую очередь способом экономии — купить не 20 сертификатов, а один. Но так как Let’s Encrypt выдаёт их бесплатно, возможно вам и не нужен wildcard.
Далее, есть также инструментарий для автоматизации менеджмента сертификатов и с другими центрами сертификации, например SSLmate и подобные вещи. Ну и, в конце-концов, если вам ничего из этого не подходит, то придётся писать свой собственный плагин для Ansible.
Итак, прошло 25 минут доклада, перед нами 50-й слайд и мы наконец-то смогли купить сертификат (смех в зале).
Как его настраивать? На каких моментах следует остановится?
Первое — в HTTP описан заголовок под названием Strict Transport Security, который указывает на то, что: тем клиентам, которые единожды пришли на него по HTTPS, что в дальнейшем стоит ходить на него по HTTPS, а по HTTP не ходить никогда. Этот заголовок должен быть на любом сервере который поддерживает HTTPS просто по той причине, что добровольное шифрование из серии «если получилось зашифровать — работаем, а нет — так нет» просто не работает. Инструментарий наподобие SSLstrip уже слишком популярен. Пользователи не будут смотреть «есть там замочек или нет» — они будут просто работать со страницей, поэтому их браузер должен запоминать и заранее знать, что ходить нужно по HTTPS. HTTPS имеет смысл только тогда, когда его насаждают принудительно.
Другой полезный заголовок — это Public Key Pinning, то есть при привязывании публичного ключа, а мы ранее говорили о том, что нам сложно доверять центрам сертификации, поэтому при заходе пользователя на сайт мы можем выдавать ему список хэшей публичных ключей, которые могут использоваться для идентификации данного сайта. То есть — другие сертификаты, кроме перечисленных, этим сайтом использоваться не могут. Если браузер видит такой сертификат — это либо кража, либо какой-то фрод.
Соответственно, в Public Key Pinning также необходимо включать все ключи которые будут действовать в течение периода — то есть если вы настраиваете на срок в 30 или 60 дней, то должны выдаваться хэши всех сертификатов, что будут на этом сайте в течение 30 или 60 дней. Все будущие сертификаты, которые сейчас вы только выпустите, а использовать будете только через месяц.
Опять же — руками это очень сложно делать, это большая боль, поэтому нужна автоматизация.
К другим проблемам — шифры. В wiki Mozilla есть ссылка, по которой можно найти генератор конфига для практических всех популярных веб-серверов: NGINX, Apache, HProxy и lighttpd (если у кого-то он есть). Ходите туда периодически, ходите туда часто — возможно стоит данный процесс как-то автоматизировать. Если у вас есть штатный криптограф — тогда всё хорошо, но непонятно, что вы тут делаете. Если у вас нет штатного криптографа, то у фонда Mozilla он есть. Отсюда следует, что все необходимые изменения в шифрах — вся та работа, которую криптографы делают в попытке понять «как шифры могут быть уязвимы», она доступна на этой странице.
Есть золотое правило криптографии: «Не изобретайте свою криптографию». оно относится не только к разработке, но и к администрированию.
Есть очень много неочевидных вещей, например — вот так выглядит список тех шифров, которые Mozilla рекомендует устанавливать по-умолчанию. Обратите внимание на то, что подчёркнуто — два одинаковых шифра, полностью, которые должны поддерживаться сервером и выдаваться клиенту в списке доступных. Они отличаются лишь тем, что один из них — это шифр AES с длиной ключа 256, а другой — длиной 128.
Если шифр длиной 128 достаточно надёжный, зачем нам 256? Если есть 256, зачем нам 128? Кто знает, почему так?
Расскажу вам историю про Рэнделл (Rijndael) — название звучит так, как будто это уже Толкиен какой-то.
Стандарт шифрования AES был заказан федеральным правительством США в 1998 году: был организован конкурс и тендер, который выиграл французский шифр Rijndael (слово такое странное потому что составлено из фамилий двух его изобретателей — и оба французы). В 2001 году шифр был окончательно одобрен АНБ и начал применяться, в том числе, в министерстве обороны и американской армии. И тут разработчики шифра натолкнулись на требования американской армии, которые, мягко говоря, несовременны.
В чём они заключались?
Военные потребовали, чтобы у предоставляемого шифра было 3 уровня безопасности. Три различных уровня безопасности. Причём — самый слабый из них используется для наименее важных данных, а самый стойкий — для наиболее важных данных (прямо Top Secret). Криптографы столкнувшись с этой ситуацией очень внимательно почитали требования к тендеру и выяснили, что нет требования чтобы самый слабый шифр был не стойким — поэтому они выдали шифры с тремя уровнями ключей, где даже самый слабый (128-битный) всё ещё не может быть взломан/расшифрован в обозримом будущем.
Соответственно, AES-256 это абсолютно избыточная вещь, которая была нужна потому что так хотелось военным. AES-128 вполне достаточен сегодня, но это имеет уже очень мало значения, потому что AES поддерживает в большинстве современных процессоров — из коробки и на уровне железа, поэтому мы не заморачиваемся на эту тему. Я рассказываю это как иллюстрацию того, что в том списке шифров, который опубликован фондом Mozilla будут вещи которые вам, возможно, не очевидны.
Или вот вам другой пример
Того, насколько современное шифрование может быть неочевидным для обывателя. Есть такое свойство сессионных алгоритмов шифрования под названием Perfect Forward Secrecy — нормального перевода на русский язык у него нет, поэтому все используют англоязычный термин. Данным свойством Perfect Forward Secrecy обладает множество шифров, в том числе и эфемерные разновидности шифра Diffie-Hellman’а, очень распространённого.
Это свойство подразумевает, что как только сессионный ключ сгенерирован — его невозможно восстановить или взломать с использованием изначального приватного ключа, того, который соответствует публичному и записан в сертификате.
Свойство Perfect Forward Secrecy делает невозможным пассивный анализ трафика и анализ в том, что называется out-of-path analysis — невозможен анализ сохранённой истории трафика. На этом попадаются очень многие DPI и WAF-решения, потому что порядка 70% HTTPS-запросов используют те или иные разновидности алгоритмов, поддерживающих PFS и проходят сквозь эти DPI-решения как нож сквозь масло, без какого либо анализа. Причём из этих 70% трафика около 10% — легитимный трафик, а остальное это боты и взломщики, которые знают, как пройти через DPI. Возможно в этот момент кто-то уже понял, куда я веду.
Если так получилось, что государство требует от вас раскрыть приватные ключи вашего сервиса и передать им, чтобы появилась возможность дешифровать когда-то собранный и сохранённый за три месяца до этого трафик — благодаря PFS и Diffie-Hellman’у мы можем лишь пожелать удачи на этом пути.
Краткая справка по протоколам
1. Нет сомнений что SSLv2 (версии два) уже умер. Если у кого-то он есть — прекратите его использование прямо сейчас, это очень неаккуратно написанный протокол.
2. SSLv3 и TLSv1.0 ровно так же мертвы и не должны использоваться за исключением того, что TLS вообще не поддерживается в браузере IE6, слава богу его мало кто использует в настоящий момент, однако в принципе такие люди ещё остались.
Что более существенно — целая куча телевизоров не поддерживает TLS в принципе, она поддерживает только старые версии протокола SSL. С этим связана некоторая болтанка вокруг сертификации систем для работы с платёжными картами — PCI DSS. Чуть больше года назад совет PCI DSS постановил, что начиная с июня 2016 года SSLv3 и ранние версии TLS (то есть версия 1.0) не может использоваться на сервисах, которые обрабатывают данные публичных карт.
В принципе разумные требования, за тем исключением, что куча вендоров после этого похватала ржавые сельскохозяйственные орудия умерщвления и пошла в совет PCI DSS со словами: «Мы в этом случае не можем работать ни с телевизорами, ни со старыми смартфонами — это огромные объёмы трафика и сделать мы ничего сами не можем».
В феврале 2016 года совет PCI DSS отложил выполнение этого требования то ли до 2018, то ли 2019 года. Мы же здесь останавливаемся и вздыхаем, потому что SSL любой версии уязвим, а TLS любой версии не поддерживается кучей телевизоров, в частности корейских. Обидно.
Тем не менее протокол TLS продолжает жить и развиваться (за исключением версии 1.0).
Современная версия — 1.1.2 и находящаяся сейчас в разработке 1.1.3. И возможно, что TLS растёт даже слишком быстро, потому что в версии TLS 1.1.2 появилась возможность для реализации достаточно интересного механизма: заставить сервер подписать строго определённый токен, отгруженный ему клиентом и, соответственно, получить эту подпись, при определённых условиях. То есть мы можем утверждать, что: «Мы ходили по шифрованному соединению вот на этот сервер, вот столько раз, в течение вот такого определённого промежутка времени». Что являет собой необходимый прототип для организации блокчейна — пожалуйста, криптовалюта DDoSCoin как концепция, а на GitHub’е лежит достаточно подробный документ и можно посмотреть на код.
Ну и буквально по верхам
OCSP stapling — очень полезная вещь. Мы уже говорили, что OCSP отзыв сертификатов — это soft fail. С другой стороны есть возможность реализовать OCSP stapling — когда сам сервер будет ходить на сервер валидации и получать оттуда необходимую подпись, которую он дальше сам отдаёт клиенту.
Для большинства высоконагруженных сайтов центры сертификации даже могут потребовать такую вещь, так как им невыгодно держать на себе подобную нагрузку. Держите её сами.
Проблема в том, что в ряде случаев OCSP stapling выливается в самый настоящий hard fail и, например, если сервер OCSP у центра сертификации не доступен определённое время и вы не успели получить от него валидную для данного момента подпись — у вас случается downtime и вам обидно. Поэтому, перед тем как включить stapling, необходимо получить данные и понять, кто на данный момент ваш центр сертификации и какая у него структура.
Далее, при внедрении TLS нужно понимать, что TLS’ный handshake это дорого и долго. То есть возрастает packet-rate, нагрузка, страницы медленно открываются — поэтому, даже если вы в HTTPS не использовали по каким-то причинам keep-alive соединение с определённым сроком жизни, то в TLS сам Адам Лэнгли велел.
Ещё одна важная вещь, на которой я не буду детально останавливаться, заключается в том, что если у вас есть какой-то нешифрованный контент — вам нужно с этим что-то делать. Если вы крупная компания с большой инфраструктурой, то вы можете прийти к своей баннерной сети и сказать: «Выдавай мне вот это в шифрованном виде». Потому что, если вы маленький сервис — то в ответ вы не услышите ничего хорошего.
Три финальных пункта, которые должны отложиться в памяти
- Используйте короткоживущие сертификаты
- Автоматизируйте всё
- Верьте фонду Mozilla — он плохого не скажет
Автор: Shapelez
