Пришло время переключаться на HTTPS

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

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

По данным, собранным браузерами Google Chrome и Mozilla Firefox, сегодня шифруется больше половины трафика WWW – передаваемого как на компьютеры, так и на мобильные устройства. Основная его часть приходится на долю крупных сайтов, но все же по сравнению с предыдущим годом прирост составил более 10%.

А судя по результатам февральского исследования миллиона самых посещаемых сайтов, 20% из них поддерживают HTTPS, тогда как в августе прошлого года таковых было лишь 14%. Таким образом, менее чем за полгода произошел впечатляющий рост на 40%.

Ускорение перехода на HTTPS происходит по ряду причин. Часть прежних помех теперь преодолеть проще, уменьшились затраты и появились дополнительные стимулы, способствующие смене протокола.

Влияние на быстродействие сайта

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

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

После того как в 2010 году в Google перевели на HTTPS сервис Gmail, в компании отметили увеличение нагрузки на серверные процессоры на 1%, увеличение расхода памяти в расчете на соединение на 10 Кбайт и повышение сетевых накладных затрат менее чем на 2%. При этом не понадобилось ни дополнительных серверов, ни специализированного оборудования.

Но малозначительное влияние на серверную часть – это еще не все: просмотр сайта со включенным HTTPS на самом деле происходит быстрее. Причина в том, что современные браузеры поддерживают HTTP/2 – обновление для протокола HTTP, которое во многом улучшает характеристики быстродействия.

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

Денежный вопрос

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

Но сегодня это уже не проблема, по крайней мере для сайтов, которым не нужны SSL-сертификаты высокой надежности (Extended Validation, EV). Появившийся в прошлом году некоммерческий удостоверяющий центр Let's Encrypt предоставляет SSL-сертификаты с проверкой домена (Domain Validation, DV) бесплатно и в рамках полностью автоматизированного процесса.

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

Бесплатные сертификаты TLS также предлагают своим клиентам некоторые операторы сетей доставки контента и провайдеры облачных сервисов, в том числе CloudFlare и Amazon. Сайты, хостинг которых осуществляется на платформе Wordpress.com, тоже по умолчанию доступны по HTTPS с бесплатными сертификатами, в том числе когда для них используются собственные домены.

Нет ничего хуже, чем плохая реализация

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

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

«Головная боль» из-за смешанного контента

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

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

Веб-мастера могут найти незащищенные ресурсы на своих сайтах с помощью заголовка Content Security Policy, CSP. Обращения к таким ресурсам можно либо блокировать, либо переадресовывать на HTTPS на лету. Чтобы избежать проблем со смешанным контентом, можно также воспользоваться протоколом HTTP Strict Transport Security, HSTS.

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

HTTPS улучшает защищенность и укрепляет доверие

Одно из главных преимуществ HTTPS в том, что он защищает пользователей от атак «человек посередине» (man-in-the-middle, MitM), которые можно устраивать в скомпрометированных и незащищенных сетях. Взломщики пользуются методами MitM для хищения конфиденциальной информации и внедрения вредоносного контента в трафик WWW.

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

«Бойкот» в Google из-за отсутствия HTTPS

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

Активно подталкивают к переключению на HTTPS и разработчики браузеров. Свежие версии Chrome и Firefox отображают предупреждения, когда пользователи пытаются вводить пароли или данные по кредитным картам на страницах, открытых по незащищенным соединениям.

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

Перспективы

«Мы уже проделали довольно большую работу, разъясняя, почему всем следует пользоваться HTTPS, – говорит Иван Ристич, бывший руководитель Qualys SSL Labs, автор книги «Пуленепробиваемые SSL и TLS». – Главное, что браузеры постоянно подталкивают владельцев сайтов переключаться благодаря предупреждениям и другим новшествам».

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

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

Но имейте в виду: из-за того что HTTPS теперь прост во внедрении, им легче злоупотреблять, поэтому важно разъяснять пользователям, какие именно возможности технология обеспечивает, а какие – нет.

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

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

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

– Lucian Constantin. It's time to turn on HTTPS: the benefits are well worth the effort IDG News Service. March 14, 2017

— Александр Лямин, генеральный директор Qrator Labs

Третий лишний?!

Само по себе наличие шифрования не дает гарантии конфиденциальности. Исключительно важны еще и практики его применения, аутентификации сторон и способов обмена ключами и сертификатами. По незнанию это часто превращается в «Театр безопасности» (когда целью проводимых мероприятий заявляется повышение безопасности, но по факту не делается ничего для ее достижения — Прим. ред.).

И в качестве примера можно привести Keyless SSL Cloudflare с последующей массивной утечкой п ользовательских критичных данных: Cloudflare изобретал новый способ сделать SSL «безопасней» — Keyless SSL, но в итоге огромный массив пользовательских данных утек в сеть, потому что шифрование и безопасность могут быть только сквозными. В противном случае возникают риски, которые в данном случае и реализовались.

— Алексей Лукацкий, бизнес-консультант по безопасности, Cisco

Может ли переход к HTTPS обусловить возникновение новых (сопутствующих) рисков ИБ для предприятий и организаций? Какие это риски?

Рекомендация перейти на HTTPS (и обязательно на старшие версии TLS, а не на уязвимый SSL) полезна, но у шифрования есть и другая сторона.

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

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

— Андрей Янкин, руководитель отдела консалтинга центра информационной безопасности компании «Инфосистемы Джет»

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

То, что данные в Интернете все еще передаются в открытом виде — архаизм родом из 1980-х годов. Затянувшийся переход на IPv6 не позволил решить этот вопрос на уровне глобальной архитектуры Сети. Поэтому инициативы крупных игроков, таких как Google, по распространению HTTPS — очень важны. Миллионы владельцев сайтов, обрабатывающих персональные данные, финансовые транзакции и другую конфиденциальную информацию, настолько далеки от мира информационной безопасности, что «инициативы снизу» тут ожидать не приходится.

Однако, как и любая технология, шифрование порой из спасителя превращается в убийцу. Несмотря на существующее мнение, что серьезные затраты на получение и возобновление цифровых сертификатов, необходимых для поддержки HTTPS ушли в прошлое, шифрование остается ресурсоемкой операцией, которая для обычного веб-ресурса, не связанного с колоссальными объемами вычислений, характерных для Google, на порядок превосходит заявленный 1% дополнительных процессорных мощностей. В нашей практике был случай многоступенчатой DDoS-атаки на сайт финансового учреждения (мы проводили работы в банке и оперативно подключились к отражению нападения). Несколько волн атак были отбиты, но в итоге злоумышленники направили на сайт вал запросов от устройств Интернета вещей, которые настолько перегрузили сервера терминации SSL, что сайт перестал отвечать легитимным пользователям. В итоге удалось «закидать шапками» DDoS. То есть перевести значительные виртуальные мощности других боевых информационных систем на обслуживание шифрования HTTPS. Риски такого характера стоит учитывать еще на уровне проектирования систем.

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

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