Эта страница переведена с помощью Cloud Translation API.

Сбивайте с толку злонамеренных посредников с помощью HTTPS и строгой транспортной безопасности HTTP.

Mike West

Учитывая объем персональных данных, проходящих через огромную сеть каналов, которыми является Интернет, шифрование — это не то, что мы можем или должны легко игнорировать. Современные браузеры предлагают несколько механизмов, которые вы можете использовать для обеспечения безопасности данных ваших пользователей во время передачи: безопасные файлы cookie и строгая транспортная безопасность являются двумя наиболее важными. Они позволяют вам беспрепятственно защищать ваших пользователей, переводя их соединения на HTTPS и обеспечивая гарантию того, что пользовательские данные никогда не передаются в открытом виде.

Почему вас это должно волновать? Учти это:

Доставка веб-страницы через незашифрованное HTTP-соединение примерно то же самое, что передача незапечатанного конверта первому человеку, которого вы видите на улице, который выглядит так, будто идет в направлении почтового отделения. Если вам повезет, она может донести его сама до конца или передать его следующему человеку, который увидит, идущему в правильном направлении. Этот человек может сделать то же самое и так далее.

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

Посредники

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

Вы можете увидеть эти переходы в действии с помощью трассировки. Путь от моего компьютера к HTML5Rocks выглядит примерно так:

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

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

Хуже того, такого рода перехват практически необнаружим. Злонамеренно измененный HTTP-ответ выглядит точно так же, как действительный ответ, поскольку не существует механизма, который позволил бы вам гарантировать, что полученные данные являются _точно _отправленными данными. Если кто-то решит ради смеха перевернуть мой Интернет , то мне более-менее не повезло.

Это защищенная линия?

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

Омнибокс Chrome предоставляет довольно подробную информацию о состоянии соединения.

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

Таким образом, HTTPS дает вам некоторую уверенность в том, что вы разговариваете с сервером, с которым, по вашему мнению, разговариваете, и что никто другой не подслушивает и не передает биты по сети. Этот вид шифрования является абсолютным условием безопасности в Интернете; если ваше приложение в настоящее время не доставляется по HTTPS, оно уязвимо для атак. Почини это. В Ars Technica есть отличное руководство по получению и установке сертификата (бесплатно) , с которым я бы рекомендовал ознакомиться для получения технических подробностей. Конфигурация будет отличаться от провайдера к провайдеру и от сервера к серверу, но процесс запроса сертификата везде одинаков.

Безопасно по умолчанию

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

Сюда, пожалуйста

Когда пользователь посещает http://example.com/ , перенаправьте его на https://example.com/ , отправив ответ 301 Moved Permanently с соответствующим заголовком Location :

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

Вы можете легко настроить такое перенаправление на таких серверах, как Apache или Nginx. Например, конфигурация Nginx, которая перенаправляет с http://example.com/ на https://example.com/ , выглядит следующим образом:

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

Заприте банку с печеньем

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

Установка файла cookie обычно включает HTTP-заголовок, который выглядит примерно так:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

Вы можете указать браузеру ограничить использование файлов cookie для защиты сеансов, добавив одно ключевое слово:

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

Файлы cookie, установленные с ключевым словом secure , никогда не будут отправляться по HTTP.

Закрытие открытого окна

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

Вы можете снизить риск атак этого класса, попросив браузер включить строгую транспортную безопасность HTTP (HSTS) . Отправка HTTP-заголовка Strict-Transport-Security дает браузеру указание выполнить перенаправление HTTP на HTTPS на стороне клиента , даже не затрагивая сеть (это также полезно для производительности; лучший запрос — это тот, который вам не нужно делать). делать):

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Браузеры, поддерживающие этот заголовок (в настоящее время Firefox, Chrome и Opera: caniuse содержит подробную информацию ), отмечают, что этот конкретный сайт запрашивает доступ только по протоколу HTTPS. Это означает, что независимо от того, как пользователь заходит на сайт, он будет его посещать. через HTTPS. Даже если она введет http://example.com/ в браузер, она перейдет на HTTPS, даже не установив HTTP-соединение. Еще лучше, если браузер обнаружит недействительный сертификат (возможно, пытающийся подделать личность вашего сервера), пользователям не будет разрешено продолжить работу через HTTP; все или ничего, и это отлично.

Браузер истечет статус HSTS сервера через max-age секундах (в этом примере около месяца); установите это значение на достаточно высокое значение.

Вы также можете гарантировать, что все субдомены источника защищены, добавив в заголовок директиву includeSubDomains :

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Иди вперед, безопасно

HTTPS — единственный способ быть хотя бы отдаленно уверенным, что отправляемые вами данные дойдут до предполагаемого получателя в целости и сохранности. Вам следует настроить безопасные соединения для ваших сайтов и приложений уже сегодня. Это довольно простой процесс, который поможет обеспечить безопасность данных ваших клиентов. После того, как вы установили зашифрованный канал, вам следует прозрачно перенаправлять пользователей на это безопасное соединение независимо от того, как они приходят на ваш сайт, отправляя HTTP-ответ 301. Затем убедитесь, что вся конфиденциальная информация о сеансах ваших пользователей использует только это безопасное соединение, добавив ключевое слово secure при настройке файлов cookie. После того, как вы все это сделаете, убедитесь, что ваши пользователи никогда случайно не выпадут из шины: защитите их, гарантируя, что их браузер делает правильные действия, отправляя заголовок Strict-Transport-Security .

Настройка HTTPS не требует особых усилий и дает огромные преимущества для вашего сайта и его пользователей. Это того стоит.

Ресурсы

StartSSL предлагает бесплатные сертификаты, проверенные доменом. Вы не можете победить бесплатно. Переход на более высокие уровни верификации, конечно, возможен и стоит разумных денег.
Тест SSL-сервера . После того как вы настроили HTTPS для своих серверов, убедитесь, что вы все сделали правильно, запустив серверный тест SSL Labs. Вы получите подробный отчет , который покажет, действительно ли вы в рабочем состоянии.
Недавнюю статью Ars Technica «Защита вашего веб-сервера с помощью SSL/TLS» стоит прочитать, чтобы получить немного больше подробностей об основах настройки сервера.
Спецификацию HTTP Strict Transport Security (RFC6797) стоит просмотреть, чтобы получить всю техническую информацию о заголовке Strict-Transport-Security вам может понадобиться.
Как только вы действительно поймете, что делаете, одним из возможных следующих шагов может стать объявление о том, что ваш сайт должен быть доступен только через определенный набор сертификатов. В IETF ведется работа, которая позволит вам сделать это через заголовок Public-Key-Pins ; еще рано, но интересно, и за ним стоит следить.