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

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

Mike West

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

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

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

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

Посредники

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

Вы можете увидеть эти переходы в действии с помощью traceroute. Маршрут от моего компьютера до 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, то каждый из этих промежуточных маршрутизаторов имеет полный доступ к моим запросам и ответам серверов. Все данные передаются как незашифрованный открытый текст, и любой из этих посредников может действовать как Man in the Middle , читая мои данные или даже манипулируя ими при передаче.

Хуже того, такой перехват практически невозможно обнаружить. Вредоносно измененный 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 Strict Transport Security (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 ; пока рано говорить, но интересно и стоит следить.