H Масштабируя TLS в черновиках

Артeм Гавриченков ( ximaera )

Ведущий: Я хочу представить следующего докладчика, это Артем Гавриченков. Артем из компании Qrator Labs, которая занимается защитой от DDoS, он сейчас об этом расскажет.

Артем Гавриченков:Мы продолжаем находиться на сессии про HTTPS, TLS, SSL и все такое. То, о чем я сейчас буду говорить, это не какой-то туториал. Как говорил мой преподаватель в университете по базам данных — я не буду вас учить настраивать Microsoft SQL Server, пусть это делает Microsoft, не буду учить вас настраивать Oracle, пусть это делает Oracle, я не буду вас учить настраивать MySql, делайте это сами. Мы обсудим некий общий взгляд на проблематику и на возможности для решения проблем, которые возникают при внедрении шифрования на публичных сервисах.


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



* https://forum.nginx.org/read.php?21,236132,236184
* https://daniel.haxx.se/blog/2015/03/06/tls-in-http2/

Началось все в 2010 году, на мой взгляд, с изобретения Google’ом протокола SPDY. Де-юре SPDY мог работать без шифрования, однако де-факто его реализация зависела от расширения NPN – Next Protocol Negotiation, которая была в TLS, а в стандартном протоколе транспортного уровня TCP его не было. Поэтому де-факто без шифрования SPDY не работал. Долгое время в индустрии шли споры, оживленные дискуссии на тему того, помогает ли SPDY, ускоряет ли он работу, снижает ли он нагрузку или нет. За это время много кто успел его внедрить, и де-факто таким образом многие люди оказались уже с так или иначе внедренным шифрованием.

Прошло 4 года. И сотрудники поиска Google в своем блоге объявили о том, что, начиная с сегодняшнего дня, наличие у сайта HTTPS будет бонусом при ранжировании, при поисковой выдаче. Это было прям boost’ом, потому что о безопасности пользователей думают не все, а вот о месте в поисковой выдаче думают практически все, поэтому, начиная с этого момента, HTTPS начал очень активно внедряться теми, кто раньше вообще об этом не думал и проблемы такой для себя не видел.

Спустя год, был финализирован и опубликован стандарт HTTP/2. Опять же, не было записано требования о том, что HTTP/2 должен работать только поверх TLS, однако де-факто ни один современный браузер в HTTP/2 ходить без TLS (это TLS, заметьте, не SSL) не умеет.

И, наконец, в 2016-м году ряд компании при поддержке Фонда электронных рубежей основал некоммерческий проект Let’s Encrypt, который выдает всем сертификаты автоматизировано, быстро и бесплатно.

Примерно так выглядит график числа выданных активных сертификатов Let’s Encrypt:



Шкала ординат здесь в миллионах. Внедрение идет очень активно.

Другая статистика из телеметрии Firefox:



За прошедший год, с ноября 2015 года, число веб-страниц, посещенных пользователями Firefox по HTTPS в сравнении с HTTP, выросло практически на четверть-треть. Скажем большое спасибо за это Let’s Encrypt. Кстати, у них началась краудфайндинговая компания, не проходите мимо.



* https://forum.nginx.org/read.php?21,236132,236184
* https://daniel.haxx.se/blog/2015/03/06/tls-in-http2/

Это только одна сторона истории. Говоря про нее, нельзя не упомянуть вторую нить с откровениями всем, я думаю, известного сотрудника корпорации Booz Allen Hamilton Эдварда Сноудена. Того самого, про которого недавно фильм сняли. В этот момент это послужило некоторым, условно говоря, маркетингом в сторону HTTPS, что «за нами следят, давайте защищать своих пользователей». В том числе, компания Google. После того, как были опубликованы очередные откровения о том, что, оказывается, АНБ, вроде как, перехватывало внутренние коммуникации, внутри дата-центров Google, инженеры Google написали в своем блоге матерное выражение в отношении правительства США и зашифровали все и внутренние коммуникации в том числе. Примерно через месяц был опубликован пост про то, что теперь HTTPS учитывается при ранжировании. Какие-то конспирологи могут видеть в этом какую-то связь.

Примерно с тех времен – с 2013-14 г. – у нас появилось целых 2 фактора для продвижения TLS. И он реально стал популярен. Он стал популярен настолько, что, как выяснилось, инфраструктура и библиотеки шифрования были просто не готовы к такой популярности.

В 2014 г. было обнаружено целых две критических уязвимости в самой популярной библиотеке OpenSSL. Кто-то даже попытался перейти по этому поводу на вторую открытую альтернативу – GnuTLS, который оказался еще хуже.



Internet Engineering Task Force в феврале 2015 г. даже выпустил на эту тему отдельный RFC, в котором описывал известные атаки на TLS и датаграммный TLS – тот же TLS, но поверх UDP. Это документальное свидетельство высокого оптимизма рабочей группы IETF, потому что они в феврале 2015 г. объявили о том, что они сейчас подведут итог всем атакам.



А с тех пор атак и уязвимостей было найдено еще 3. Причем, самая первая из них была найдена спустя 20 дней после опубликования RFC.

На самом деле, эта история вот про что. В дисциплине управления проектами можно увидеть упоминание такого термина, как технологическая задолженность. Условно говоря, если вы пишете, решаете какую-то задачу, и вы понимаете, что ее решение займет 6 месяцев, но нужно за 3 и, если вот тут вот поставить костыль аккуратненько, то в принципе за 3 сделать можно. Фактически в этот момент вы берете у Вселенной время в долг, потому что тот костыль, который будет подставлен, он рано или поздно покривеет, развалится, вам придется его исправлять. Если таких костылей наберется очень много, произойдет технологический дефолт, вы просто не сможете делать ничего нового, пока вы не разберете все старое. Шифрование в том виде, в котором оно было в конце 2000-х гг., сделали, потому что этим занимались энтузиасты. Но, когда народ начал реально этим пользоваться, выяснилось, что в этом есть очень много косяков, которые нужно как-то исправлять. И главный косяк – это информированность целевой аудитории, т.е. вас, о том, как это все работает и как это настраивать.

Давайте пройдемся и разберем основные моменты с небольшим акцентом на крупный сетап. Начнем с банальности. Чтобы поднять сервис, нужно его настроить. Чтобы настроить, нужен сертификат. Сертификат нужно купить. У кого?



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

До кого-то. Для понимания я скачал ванильный Firefox и там порядка 100 штук доверенных центров сертификации, т.е. выбор у вас большой, у кого этот сертификат можно купить. Что это за сотня компаний?



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



Не считая того, что некоторые из них и есть правительство. В частности, японское, тайваньское и правительство Валенсии.



А другие были куплены крупными корпорациями за достаточно обалденную сумму.



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

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



Наглядная история. Центр сертификации под названием WoSign. Если я не ошибаюсь, он является доверенным центром сертификации во всех популярных браузерах ОС с 2009 г. Он стал центром по достаточно правильной траектории, т.е. он прошел аудит Ernst&Young, он организовал достаточно агрессивную маркетинговую компанию, он выдавал бесплатные сертификаты всем направо, налево, все было хорошо.



* https://wiki.mozilla.org/CA:WoSign_Issues

В этом году сотрудники фонда Mozilla написали целую страницу на своем Wiki со списком тех нарушений, которые рано или поздно допускал WoSign. В основном эти нарушения датированы 2015-2016 годами. В чем они заключались? Как известно, вы не можете просто так получить сертификат для левого домена. Вы должны как-то доказать, что вы являетесь владельцем этого домена. Как правило, это заключается в том, что вам нужно либо подтвердить что-то по почте, либо разместить на вашем сайте какой-то определенный токен по строго определенному адресу.

WoSign по крайней мере один раз выпустил сертификат для alicdn.com, который не запрашивался самим AliExpress. AliExpress пользуется услугами Symantec. Тем не менее, сертификат был выпущен и опубликован. WoSign позволял использовать непривилегированные порты для верификации, т.е. любой пользователь, не только администратор, но любой пользователь данного сервера мог получить сертификаты любого домена на нем размещенного. WoSign позволял использовать домены 3-го, 4-го и т.д. уровней для верификации домена 2-го уровня, т.о. исследователи в рамках проверки WoSign на стойкость сумели получить валидный сертификат для GitHub.

WoSign позволял использовать любые файлы, т.е. указывать путь, по которому будет размещен токен, произвольный путь на сайте, т.о. исследователям удалось получить подписанные сертификаты для Google и Facebook. И, в принципе, это все ерунда, потому что на самом деле при определенных условиях WoSign позволял выписывать любые сертификаты для любого домена без проверки вообще. После этого все прочие мелочи отходят на задний план. Там всего порядка 13-и проблем, которые были. WoSign выпускал сертификаты задним числом, он использовал на сервере валидации софт, который не имел патчей, в том числе обновлений безопасности долгие годы. Они купили StartCom, StartSSL и отказались опубликовывать какую-то информацию об этом, что нарушает политики фонда Mozilla, но по сравнению со всем остальным это уже не так больно.



Каков итог? В сентябре этого года WoSign был забанен в Chrome и забанен в Firefox на год, но ему до сих пор продолжают доверять Microsoft и ОС Windows. Нельзя просто так перестать быть центром сертификации. И это мы говорим про мелочь, между прочим. Если мы будем говорить про какой-нибудь Verisign, тот же самый Symantec, то нужно понимать, что нельзя просто так взять и отозвать корневой сертификат Symantec, потому что им подписан тот же самый AliExpress, им подписан Google, им подписан очень много кто, и у пользователей будут проблемы с доступом к ресурсу. Поэтому, так или иначе, это нельзя просто так взять и сделать, как это когда-то предполагалось, по щелчку пальцев.

Большие центры сертификации. Знаете, есть такое выражение «toо big to fail» – они слишком большие, чтобы взять и перестать существовать. Альтернатива TLS’ному PKI есть, она называется DANE, построена вокруг DNSSEC, но у нее столько инфраструктурных проблем, в том числе с задержками и деплойментом, что говорить о ней сейчас бессмысленно, нужно как-то с этим жить.

Как же с этим жить? Я обещал дать гайд по тому, как выбирать Certificate Authority.



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

И второй полезный совет на сегодняшний день, т.к. мы находимся здесь, мы говорим про распределенные инфраструктуры со множеством балансеров – купите не один, а два, три сертификата. Купите один у Verisign, а второй у польской Unizeto, третий возьмите у Let’s Encrypt бесплатно. Это не сильно увеличит OPEX, но это серьезно поможет в случае непредвиденных ситуаций, о которых мы еще поговорим.



Вопрос сходу. Например, Let’s Encrypt не выписывает сертификаты Extended validity, что нам с этим делать? Т.е. у нас не будет такого красивого зеленого значка? На самом деле, это театр безопасности, потому что все равно на эти зеленые значки никто не смотрит, а мобильный браузер, например, в Windows phone даже не умеет этот значок отображать.



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

И лучше покупайте сертификаты с кратким сроком действия, чтобы если что-то произойдет с Certificate Authority, у вас было пространство для маневра. Деверсифицируйтесь.

Давайте немного подробней про время жизни сертификатов.



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

На этом плюсы заканчиваются и начинаются минусы.



Если что-то с сертификатом пошло не так, если вы потеряли приватный ключ, он достался кому-то еще, в TLS есть механизм, который позволяет вам отозвать сертификат, называется CRL и OCSP. Их целых 2 штуки. Проблема в том, что на текущий момент они работают в режиме soft-fail, т.е. если браузер не сумел подключиться к CRL-серверу и проверить статус сертификата, то ну и черт с ним, значит сертификат нормальный. Адам Ленгли из Google сравнил soft-fail CRL и OCSP с ремнем безопасности в машине, который работает все время, пока вы не попадете в аварию, а когда вы попадаете в аварию, он рвется. Смысла в таком нет, потому что тот же злоумышленник, который может сделать man in the middle и подставить украденный ключ, он же может просто закрыть доступ к SRL и OCSP и работать эти механизмы не будут.

Hard-fail CRL и OCSP, т.е. те, которые будут отображать ошибку, если CRL-сервер недоступен, сейчас не используются практически нигде.

И про боль в пятой точке. Да, она неизбежна, но честно говоря, вы все равно должны автоматизировать деплоймент сертификата. Если особенно у вас не один сервер, а их несколько, то деплоймент – это просто то, что нужно сделать, потому что долго живущий сертификат.



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

Что позволяет менеджмент автоматизированного управления сертификатами?



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

Кстати, мы выложили в открытый доступ видеозаписи последних пяти лет конференции разработчиков высоконагруженных систем HighLoad++. Смотрите, изучайте, делитесь и подписывайтесь на канал YouTube.

Это, между прочим, не теоретическая история. Это история октября этого года.



Один из крупнейших центров сертификации GlobalSign, с большой историей, очень надежный, в октябре проводил технические работы по перекроссировке корневых и промежуточных сертификатов и случайно отозвал все свои промежуточные сертификаты. Инженеры достаточно быстро нашли проблему, но нужно понимать, что CRL и OCSP, куда входят все браузеры всех пользователей, это достаточно нагруженный сервис. Все используют для этой цели CDN, GlobalSign использовал Cloudflare. И по каким-то причинам Cloudflare оказался не в состоянии оперативно обнулить кэш, и неверные списки отозванных сертификатов продолжали расползаться по Интернету в течение нескольких часов и кэшироваться в браузерах. Причем, кэш CRL и OCSP в браузере и ОС работает порядка 4-х дней. Т.е. 4 дня сообщение об ошибке при попытке захода на Wikipedia, Dropbox, Spotify и Financial times… Все они пострадали.

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

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



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

Как выглядит ситуация с отозванными коневыми сертификатами с точки зрения администратора ресурса? В prime time все хорошо, нагрузка ниже среднего, никаких проблем нет, т.е. нигде в мониторинге ничего не вылезает, и при этом трафик упал на 30%. Проблема имеет распределенный характер, ловить ее очень сложно. Нужно понимать, что вы здесь зависите от вендора, вы не контролируете ни CRL, ни OCSP, поэтому происходит неведомая проклятая ерунда, вы не знаете, что делать.

Что помогает находить такие проблемы? Во-первых, если у вас много балансеров, если на них сертификаты от разных вендоров, о чем мы говорили, то вы видите корреляцию. Там, где был сертификат от GlobalSign, там начались проблемы. На остальных балансерах все хорошо, есть связь.

Нужно понимать, что распределенных сервисов для проверки CRL и OCSP, по крайней мере, по состоянию «на вчера» не было, т.е. не было сервиса одновременно достаточно распределенного, чтобы мониторить Cloudflare, и умеющего ходить в CRL и OCSP для произвольного домена. Но у нас есть еще есть инструмент под названием TCPdump, в котором тоже прекрасно видно, в чем проблема. Т.е. если сессия обрывается на моменте «TLS сервер hello», очевидно, что проблема где-то в TLS, хотя бы понятно, куда смотреть.

Дополнительным плюсом того, что если у вас на разных машинах находятся разные ключи, является то, что если один из них утек, то вы хотя бы знаете, откуда. Т.е. сможете написать root cause analysis. Вообще, некоторая идеология деплоймента постулирует, что закрытый ключ не должен покидать никогда машину, на которой он сгенерирован. Это некоторый технологический фашизм, но такая позиция тоже есть.



Возвращаясь к ситуации с GlobalSign. Что мы видим? Мы видим, что TLS до сих пор находится на переднем краю технологий. У нас все еще недостаточно инструментариев, у нас все еще недостаточно понимания, отчего и будут возникать такие проблемы. И просто на поиск источника проблемы могут быть потрачены часы, и когда проблема обнаружена, решать ее уже нужно очень быстро, поэтому – автоматизация и менеджмент сертификатов.



Для этого требуется либо центр сертификации, который предоставляет API. Например, Let's Encrypt – хороший выбор, если вам не нужен wildcard.



Но на самом деле, в 80% случаев вам не нужен wildcard. Wildcard – это способ сэкономить, купить не 20 сертификатов, а один. На самом деле, т.к. Let's Encrypt выдает их бесплатно, то, может, вам и не нужен wildcard.

Далее, есть также инструментарий для автоматизации менеджмента сертификатов и с другими центрами сертификации, например, SSLMate и другие вещи. И, в конце концов, если вам ничего из этого не подходит, то придется писать собственный плагин для Ansible.



Итак, у нас 50-ый слайд, и мы, наконец, смогли купить сертификат J.

Как его настраивать? На каких моментах следует остановиться?

Первое. В HTTP описан заголовок под названием «Strict Transport Security», который указывает на продолжительное время, что всем клиентам, которые единожды пришли на него по HTTP, в дальнейшем следует всегда ходить на него по HTTPS, по HTTP не ходить никогда.

Этот заголовок должен быть на любом сервере, который поддерживает HTTPS, просто по той причине, что добровольное шифрование из серии «если получилось зашифровать, то работаем, а нет – так нет» просто не работает.

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

Другой полезный заголовок – это Public Key Pinning, т.е. привязывание публичного ключа. Мы говорили о том, что нам сложно доверять центрам сертификации, поэтому при заходе пользователя на сайт, можем выдавать ему список хэшей публичных ключей, которые могут использоваться для идентификации данного сайта. Т.е. другие сертификаты, кроме перечисленных, сайтом использоваться не могут. Если браузер видит такой сертификат, то это, скорее всего, кража либо какой-то фрод. Соответственно, в Public Key Pinning также необходимо включать все ключи, которые будут действовать в течение периода. Если вы настроите его там на 30 или 60 дней, то должны выдаваться хэши всех сертификатов, которые будут на этом сайте в течение 30 или 60 дней, т.е. все будущие, которые вы сейчас только выпустили и будете использовать через месяц. Опять же, руками это очень сложно делать, это большая боль в пятой точке, поэтому вам нужна автоматизация.



К другим проблемам. Шифры. На Wiki Mozilla есть ссылка, которая рассказывает о том, как настраивать шифры. Правда, вот эта конкретно не действует, они ее перестали поддерживать, у них теперь есть генератор конфига для популярных веб-серверов, практически всех – Nginx, Apache, для HAProxy, lighttpd, если у кого-то он есть. Ходите туда периодически, ходите туда часто, возможно, стоит как-то автоматизировать это. Если у вас есть штатный криптограф, тогда все хорошо, тогда не понятно, что вы тут делаете. Если у вас нет штатного крпитографа, то у фонда Mozilla он есть, поэтому все необходимые изменения в шифрах, вся та работа, которую криптографы делают в попытке понять, как шифры могут быть уязвимыми, она будет отражаться на этой странице.

Есть золотое правило криптографии – «Don't invent your own crypto» – не изобретайте свою криптографию. Оно относится не только к разработке, оно относится в этом смысле к администрированию. Там есть очень много неочевидных вещей, например, так (на слайде выше) выглядит список тех шифров, которые Mozilla рекомендует устанавливать по умолчанию. Обратите внимание на то, что подчеркнуто. Там два одинаковых шифра, полностью одинаковые, и оба должны поддерживаться сервером и выдаваться клиентам в списке доступных. Они отличаются только тем, что один из них – это шифр с ключом 256, а второй – с длиной 128. Казалось бы, если шифр длиной 128 достаточно надежный, зачем нам 256? Если у нас есть 256, зачем нам 128? Это список, который выдается каждому браузеру, браузер имеет возможность выбрать любой из них.

Дело вот в чем, расскажу вам историю про Rijndael.



Это звучит просто как Толкиен какой-то.



Давайте так – расскажу вам историю про AES. Стандарт шифрования AES был заказан федеральным правительством США в 98-м году, был организован конкурс, тендер. Его выиграл французский шифр Rijndael. Такое странное слово, потому что по фамилии 2-х его изобретателей, оба французы. В 2001 году шифр был окончательно одобрен АНБ и начал применяться, в том числе в министерстве обороны и в американской армии.

И тут, разработчики шифра натолкнулись на требования американской армии, которая, мягко говоря, несовременная. В чем они заключались? Военные потребовали, чтобы у предоставляемых шифров было 3 уровня безопасности. 3 различных уровня безопасности, причем самый слабый из них используется для наименее важных данных, самый стойкий – для наиболее важных данных, прямо Top Secret.



Криптографы, столкнувшись с этой ситуацией, очень внимательно прочитали требования к тендеру и выяснили, что нет требования, чтобы самый слабый шифр был, тем не менее, нестойким, поэтому они выдали 3 шифра с 3-мя уровнями ключей, где даже самый слабый – 128 битный – все еще не может быть расшифрован и взломан в ближайшем будущем. Соответственно, AES 256 – это абсолютно избыточная вещь, которая была нужна, т.к. этого хотелось военным. AES 128 – это вполне достаточно на сегодняшний день, но на самом деле, это имеет очень мало значения, потому что AES поддерживается в большинстве современных процессоров из коробки на уровне железа, поэтому не так, чтобы мы сильно заморачивались на эту тему. Это просто иллюстрация того, что в том списке шифров, который будет опубликован фондом Mozilla, будут вещи, которые вам, возможно, неочевидны.



Другой пример того, насколько современное шифрование может быть неочевидным для обывателя. Есть такое свойство сессионных алгоритмов шифрования под названием Prefect Forward Secrecy. Нормального перевода на русский нет. Используйте английский термин, перевод на русский – это, как правило, какой-то «надмозг». Свойством Prefect Forward Secrecy обладает множество шифров, в том числе эфемерные разновидности шифра Diffie-Hellman, очень распространенного. Это свойство подразумевает, что как только сессионный ключ сгенерирован, его нельзя восстановить или взломать с использованием изначального приватного ключа, т.е. приватного ключа, соответствующий которому публичный записан в сертификате.

Свойство Prefect Forward Secrecy делает невозможным пассивный анализ трафика и анализ трафика в том, что называется span port, mirror port, out-of-path, т.е. делает невозможным анализ сохраненной истории трафика. На этом попадаются очень многие DPI и web application firewall-решения, потому что порядка 70% HTTPS-запросов используют те или иные разновидности алгоритмов, поддерживающих PFS, и проходят сквозь эти DPI-решения просто как нож сквозь масло, без анализа.



Причем, из этих 70-ти процентов, 60% легитимно, а 90% – это действительно боты и взломщики, потому что они знают, что есть шанс пройти, по крайней мере, через этот DPI.

Возможно, кто-то уже понял, к чему я это подвожу. Если так получилось, что государство требует у вас раскрыть приватные ключи вашего сервиса, передать им, чтобы они смогли дешифровывать когда-то собранный, сохраненный ими за 3 месяца трафик, благодаря PFS и Diffie-Hellman, то удачи!

Краткая справка по протоколам.



Нет сомнений, что TLS версии 2 уже умер, т.е. пожалуйста, если у кого-то он есть, то прекратите его использовать прямо сейчас. Это очень неаккуратно написанный протокол. На сегодняшний момент, по крайней мере, это видно.

SSL версии 3 и TLS версии 1.0 ровно так же мертвы и не должны использоваться, за исключением того, что, во-первых, TLS, в принципе, не поддерживается в браузере Internet Explorer 6 (слава Богу, его мало кто использует на сегодняшний момент, но такие люди еще остались). Что более существенно – целая куча телевизоров не поддерживает TLS в принципе, она поддерживает только старые версии протокола SSL. C этим связана некоторая болтанка вокруг сертификации систем для работы с платежными картами PСI и DSS. Совет PСI и DSS чуть больше года назад постановил, что, начиная с июня 2016 года SSLv3 и ранние версии TLS, т.е. версия 1.0 использоваться не может на сервисах, которые обрабатывают данные публичных карт.

В принципе, разумные требования, за исключением того, что куча вендоров после этого похватало страшного вида ржавое орудие умерщвления и пошла в совет PСI и DSS со словами «мы не можем тогда работать нормально ни с телевизорами, ни со старыми смартфонами, это вот такие объемы трафика, мы ничего не можем сделать». Теперь в феврале 2016 года PСI и DSS отменил это требование, отложил его до 2018 то ли до 2019 года.

А мы останавливаемся и вздыхаем, потому что SSL любой версии уязвим, а TLS любой версии не поддерживается в куче телевизоров, в частности, в корейских. Обидно.

Тем не менее, протокол TLS продолжает жить и развиваться, за исключением версии 1.0. Современная версия 1.1, 1.2 и находящаяся сейчас в финальной стадии разработки 1.3. И, возможно, TLS растет даже слишком быстро, потому что, например, в версии 1.2 появилась возможность для достаточно интересного механизма. В TLS версии 1.2 есть возможность заставить сервер подписать строго определенный токен, отгруженный ему клиентом, и получить эту подпись при определенных условиях. Т.е. мы можем доказать, что мы ходили по шифрованному соединению вот на этот сервер, вот столько раз на протяжении вот такого промежутка времени, что являет собой необходимый proof of work для организации блокчейна.

Пожалуйста – крипто-валюта DDoSCoin, пока что как концепция, т.е. в ней пока не крутятся какие-то реальные финансы, но на GitHub лежит достаточно подробный white paper и proof of work, т.е. можно посмотреть, как это работает.

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

Ну и, уже по верхам буквально.



OCSP stapling – очень полезная вещь. Мы говорили про то, что OCSP отзыв сертификатов – это soft fail. Каждый браузер ходит на OCSP-сервер и, если ему не удается туда сходить, то и черт с ним. С другой стороны, есть возможность реализовать OCSP stapling, т.е. ситуацию, когда сам сервер будет ходить на сервер валидаций и получать оттуда необходимую подпись, которую сам будет отдавать клиенту. Для большинства высоконагруженных сайтов центры сертификации даже могут потребовать такую вещь, потому что они не хотят держать на себе такую нагрузку, держите ее сами. Проблема в том, что в ряде случаев OCSP stapling выливается в самый настоящий hard fail и, если, например, сервер OCSP у центра сертификации недоступен определенное время, и вы не успели получить у него валидную для данного момента подпись, то у вас случается down time, и вам обидно. Поэтому перед тем, как включить stapling, нужно взвесить различные варианты и понять, кто на данный момент ваш центр сертификации, и какая у него инфраструктура.

Далее, при внедрении TLS нужно понимать, что TLS handshake – это дорого, долго, т.е. возрастает packet-rate, нагрузка, страницы открываются медленнее, поэтому, если даже вы HTTP не использовали по каким-то причинам, а keep alive-соединения с определенным сроком жизни, то в TLS вам уже сам Адам Ленгли велел.

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



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

1. используйте коротко живущие сертификаты,
2. автоматизируйте все,
3. верьте фонду Mozilla, он плохого не скажет.

Контакты

» ximaera
» ximaera@qrator.net
» Блог компании Qrator

Этот доклад — расшифровка одного из лучших выступлений на профессиональной конференции разработчиков высоконагруженных систем HighLoad++.

Сейчас мы уже вовсю готовим конференцию 2017-года — самый большой HighLoad++
в истории. До завершения приёма докладов осталось менее двух недель, не хотите попробовать выступить у нас?