Рассказываем о продвижении HTTPS-проекта Youzan - Engineering

внешний интерфейс HTTPS HTTP модульный тест

HTTPS добавляет шифрование SSL/TLS к HTTP, чтобы обеспечить более безопасный протокол передачи. Кажется, он принадлежал к стандарту крупных веб-сайтов. Как платформа SaaS, Youzan включает в себя ключевые процессы, такие как товары пользователей, транзакции и платежи. Наша основная гарантия — поддержка полнофункционального HTTPS и повышение безопасности веб-сайта. В этой статье основное внимание уделяется следующим вещам: понимание основных принципов HTTPS, что необходимо переключить для переключения HTTPS, как его контролировать и использовать, а также некоторые возникающие трудности.

1. Основные принципы

На основе оригинального рукопожатия HTTPS добавляется проверка сертификата и шифруется, чтобы мы могли гарантировать безопасность передачи данных. Решаемые проблемы включают运营商劫持,中间人攻击,钓鱼网站,提升SEOЖдать. Конкретный процесс выглядит следующим образом:

  1. Клиент отправляет сообщение «ClientHello», содержащее версию SSL, набор шифров и алгоритм сжатия данных, поддерживаемые клиентом, и случайное число 1.
  2. Сервер отвечает сообщением «ServerHello», содержащим выбранный набор шифров, выбранный метод сжатия данных, идентификатор сеанса, цифровой сертификат и другое случайное число 2.
  3. Клиент (веб-браузер) проверяет действительность цифрового сертификата SSL сервера, и в случае сбоя будет выведено предупреждение.
  4. Клиент отправляет сообщение об обмене ключами клиента. Это сообщение содержит предварительный главный секрет (случайное число 3, используемое для генерации ключа симметричного шифрования).
  5. Клиент использует серию криптографических операций для преобразования [одноразового номера 1 одноразового номера 2 одноразового номера 3] в главный секрет, из которого получаются все ключи, используемые для шифрования и аутентификации сообщений.
  6. Сервер использует ряд криптографических операций для преобразования [одноразового номера 1 одноразового номера 2 одноразового номера 3] в главный секрет, из которого выводятся все ключи, используемые для шифрования и аутентификации сообщений.
  7. Клиент отправляет «спецификацию смены пароля», чтобы уведомить сервер о необходимости использования согласованного алгоритма симметричного шифрования и ключа для связи.
  8. Сервер отправляет «спецификацию смены пароля», чтобы уведомить клиента о необходимости использования согласованного алгоритма симметричного шифрования и ключа для связи.
  9. Квитирование SSL завершается, и связь шифруется с использованием алгоритма симметричного шифрования.

2. Ресурсы и службы, задействованные в передаче

Когда вы начинаете работать над переходом на HTTPS, для начала нужно четко понимать, с чем вы имеете дело, вообще говоря, нужно разобраться в следующем:

  1. Статические ресурсы, развернутые в CDN, js, css
  2. Ресурсы изображений
  3. Количество первичных доменов и их вторичных доменов
  4. Есть ли сторонние ресурсы, такие как реклама, видео и т. д.
  5. Вызов API, следует ли динамически возвращать HTTP-сервисы
  6. Предоставляемые внешние услуги

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

Динамический импорт статических ресурсов

<link rel="stylesheet" href="${loadStaticContent(www/css/main.min.css)}"><script type="text/javascript"  src="${loadStaticContent(www/js/main.min.js)}"></script>

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

О пункте 2, Источники изображений обычно делятся на два типа: изображения на сайте и изображения за пределами сайта. Изображения на сайте в основном будут использовать сторонние сервисы CDN. HTTPS можно включить единообразно. Общие источники изображений за пределами сайта могут включать: разработку и написание, стыковку со сторонними сервисами (аналогично руководству по покупкам Taobao) и загрузку изображений в виде ссылок, которые не хранятся в их собственных сервисах.

css динамически импортировать изображения

.loading {    background-image: image-cdn('/logo_loading.png');}

Предполагая, что используются такие инструменты, как sass, метод загрузки доменного имени CDN можно внедрить в css для изображений на сайте. Единая замена.

проблема со старой картинкой

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

О пункте 3, основной домен и его вторичное доменное имя, вы можете подсчитать HTTP-трафик (журнал awk) в журнале nginx. Получите таблицу доступа pv для существующего HTTP-трафика сайта. Получите количество доменов, для которых требуется HTTPS. Подтвердите порядок и продолжительность переключения HTTPS, учитывая следующие факторы:请求量的大小,业务的轻重缓急,业务切换 HTTPS 难度,各域名功能и т.п. После определения основного положения сайта необходимо сообщить о вышеуказанных вопросах различным деловым сторонам. Получите узел времени каждого переключения доменного имени.

О пункте 4, внедрение сторонних ресурсов.

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

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

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

О пункте 6, например, у вас есть внешние сервисы, такие как API. Жаль, что открытие HTTP-звонков было открыто в первые дни. Что мы можем сделать, так это сообщить третьей стороне через объявления, электронные письма и т. д., что мы больше не будем поддерживать службы HTTP через определенное время, и надеемся, что третья сторона будет поддерживать вызовы HTTPS. Или, если безопасность не важна, поддерживайте оба вызова HTTP/HTTPS. Объявление Apple о HTTPS, App Transport Security, является хорошим примером, но на самом деле он остается внутри приложения. Настройки HTTP-запросов.

Вышесказанное — это большая часть того, с чем нам нужно иметь дело. Прежде чем приступить к решению проблемы с HTTPS для всего сайта, подготовьтесь к этому шагу. включены调研,确认切换范围,了解业务切换难易程度,确定工作的时间安排和参与人员. Примечание. Установление сроков для каждой части работы очень поможет вам.

3. На что следует обратить внимание при переходе на HTTPS

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

Относительное соглашение

Уровень кода изменяет очевидно жестко закодированный протокол HTTP. изменился на相对协议хороший выбор

<img src="//domain.com/img/logo.png"><script src="//www/js/libs/jquery/1.4.2/jquery.js"></script>

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

Разница между 301 и 302

Когда все ресурсы на странице переведены на HTTPS, после регрессионного тестирования. При рассмотрении HTTP-доступа к веб-сайту nginx302Перенаправление на HTTPS. Принудительный переключатель. После выхода в интернет его можно наблюдать от нескольких дней до недели. (Большой трафик и сложные сервисы занимают больше времени) Сервис работает стабильно, никаких отклонений от нормы или обратной связи с пользователем нет. можно заставить301выключатель.

Разница между 302 и 301 заключается в том, что перенаправление 302 является временным, при следующем доступе браузера также осуществляется доступ к исходной ссылке. Редирект 301 работает постоянно. Следующий браузер будет напрямую обращаться к новой ссылке. Таким образом, HTTPS был реализован под определенными доменными именами, и можно использовать перенаправление 301.

Content-Security-Policy

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

img

block-all-mixed-content, принудительно блокировать внутристраничную HTTP-загрузку

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">

Но на самом деле предотвращение загрузки HTTP не является нашей целью.Поведение внедрения HTTP в более поздних разработках может быть вызвано упущением.Мы можем понять, что на самом деле ресурсы уже могут поддерживать HTTPS. Таким образом, можно использовать другую стратегию CSP:upgrade-insecure-requests

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Эта стратегия будет производить следующие два эффекта

  • Все HTTP-запросы внутри сайта инициируются в HTTPS.
  • Все переходы соединения будут открываться в HTTPS.

Эта стратегия явно дружелюбнее. Этот метод можно добавить, когда веб-сайт подтвердил принудительное использование HTTPS.

Проверьте, включен ли HTTPS в среде

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

В-четвертых, трудности, с которыми столкнулись

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

  1. Слишком много вызывающих абонентов базового интерфейса, и бывают случаи, когда внешний интерфейс вызывает напрямую или вызывает внутренний бизнес-уровень, поэтому поставщику интерфейса необходимо определить фактическое местоположение вызывающего интерфейса.
  2. Некоторые интерфейсные вызовы неreferer, referer может оказать большую помощь в поиске источников трафика. Однако некоторые страницы не имеют реферера в HTTP-доступе, что может быть вызвано сохранением пользователем ссылки на страницу или потерей страницы при входе на сайт из других источников. Предполагая, что страница прошла тест HTTPS, проблему можно решить, принудительно переключившись на HTTPS.
  3. Если старая версия клиентского интерфейса запрашивает HTTP, в зависимости от количества пользователей решается, следует ли отказаться от старой версии вызова. В противном случае нет никакого способа искоренить HTTP для этого трафика.
  4. Третья сторона запрашивает услугу HTTP, предоставляемую компанией, и информирует третью сторону о необходимости обновления в течение указанного времени.

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

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

欢迎关注公众号,获取更多内容,保持联系
Добро пожаловать в официальный аккаунт, получайте больше контента, оставайтесь на связи