Аннотация
Описан опыт развертывания подписанных обменов HTTP для использования AMP в качестве издателя. Его системный дизайн и результаты показаны с несколькими отзывами. Были обсуждены вопросы о том, может ли SXG стать новой платформой для распространения доверенного содержимого в Интернете с новой политикой выдачи сертификатов SXG и проверки.
Вступление
Yahoo! Travel [1] начал запускать сервис AMP [2] в июле 2018 года. Анализ показал, что он получил + 60% трафика, -5% отказов и + 0,5% CVR к услуге [3]. На рис.1 показан скриншот Android Google Chrome 74, на котором показана страница AMP в Yahoo! Travel.
Перемещение по этой странице осуществлялось со страниц результатов поиска по адресу https://www.google.com/.
Омнибокс в верхней части браузера указывает, что страница обслуживается с https://www.google.com/. Имя издателя, travel.yahoo.co.jp, отображается в центре дополнительной панели под омнибоксом. На первом экране омнибокс скрывается, поэтому пользователи не могут найти исходный URL, если не коснутся и не прокрутят браузер. URL-адрес издателя можно найти во всплывающем окне, щелкнув значок информации, как показано на рис. 2.
Обсуждается, что не все издатели получают преимущества страниц AMP [4], но анализ Yahoo! Travel указывает на его положительную статику благодаря AMP. Чтобы максимально использовать AMP, в Yahoo! Travel была развернута новая технология подписанных обменов HTTP (SXG) [5] в феврале 2019 года со следующими двумя целями.
- Отображение URL-адреса издателя в браузере в качестве источника
- Обслуживание персонализированной страницы AMP для пользователя без перекрестного доступа
На момент написания этой статьи в июне 2019 года вторая цель находилась в стадии разработки. В этом позиционном документе описан опыт развертывания SXG, и его обсуждение сосредоточено на первом.
SXG/AMP Системный дизайн
Система SXG / AMP была построена на выходе из Yahoo! Travel сервиса около 3 недель. До постройки потребовалось около месяца на исследование, оценку и проектирование.
Чтобы передать SXG агенту пользователя, необходимо наладить сотрудничество между издателем и распространителем. В системе SXG / AMP издателем является система SXG / AMP Yahoo! Travel и дистрибьютором является система AMP Cache, поддерживаемая AMP Project. Поисковый бот играет роль в сотрудничестве между системой SXG / AMP и AMP Cache с помощью сканирования. Рисунок 3 представляет собой диаграмму последовательности для предоставления SXG пользовательскому агенту.
Следующие 7 шагов выполняются до тех пор, пока SXG не будет предоставлен пользователю.
1. При первом сканировании поискового бота система SXG / AMP возвращает заголовок «Vary: AMP-Cache-Transform», чтобы уведомить бота о поддержке SXG.
2. Поисковый бот запрашивает заголовки «Принять: приложение / подписанный обмен; v = b3» и «AMP-Cache-Transform: google; v =» 1 »и получить SXG-файлы от издателя.
Обратите внимание, что «v =» является номером версии и подлежит изменению в будущем.
3. Поисковый бот анализирует файл SXG и получает cert-url, затем получает файл, который включает в себя цепочку сертификатов, сертификат SXG и промежуточные сертификаты, а также данные OCSP (Online Status Status Certificate Protocol). После этого AMP Cache переписывает свой cert-url в свой url-адрес кэша, так как он не подписан. Служба поиска производит индексацию содержимого AMP.
4. Пользовательский агент отправляет ключевое слово в службу поиска, и возвращается SERP (страница результатов поисковой системы).
5. При попадании страницы AMP с поддержкой SXG в результаты поиска в тег SERP включается тег предварительной выборки. Пользовательский агент получает файл SXG из кэша AMP и сохраняет его в локальном кэше во время показа результатов поиска.
6. Пользовательский агент также получает файл цепочки сертификатов и данные OCSP из AMP Cache и проверяет подпись в SXG и целостность его содержимого.
7. Когда пользовательский агент перемещается по сайту SXG через результаты поиска, содержимое загружается из его локального кэша, а его источник заменяется URL-адресом издателя.
Обзор системы SXG / AMP в Yahoo! Ход показан на рисунке 4.
На границе Интернета прокси-сервер HTTPS завершает соединения TLS и перенаправляет различные запросы на обслуживание во внутренние системы. Все запросы на страницы AMP в Yahoo! Путешествия отправляются на SXG-роутер.
Маршрутизатор SXG исследует запросы и перенаправляет запросы SXG в amppkg с параметрами запроса для подписи и извлечения. Он всегда возвращает «Vary: AMP-Cache-Transform», чтобы уведомить сканеры ботов о принятии запросов SXG.
Amppkg — это OSS amppackager, предоставленный проектом AMP [6]. Это основная программа, используемая для подписи страниц AMP и обслуживания файлов SXG с использованием сертификата SXG и его закрытого ключа. Сертификат SXG — это сертификат ECC, который имеет расширение для ограниченного использования только для SXG. В настоящее время только DigiCert выдает сертификаты SXG [7], и срок его действия ограничен 90 днями в соответствии с требованиями безопасности спецификации SXG. Сертификат SXG и промежуточные сертификаты предоставляются сканерам ботов вместе с данными OCSP, кэшированными с сервера OCSP.
Перед подписанием amppkg оптимизирует содержимое AMP с помощью программы-трансформера, где файлы времени выполнения AMP периодически получают из AMP CDN. Это необходимо, потому что данные контента не могут быть изменены после подписания.
Сервер AMP обслуживает содержимое AMP для запросов SXG и не-SXG. Спецификация SXG требует, чтобы содержимое AMP было кешируемым, поэтому мы должны удалить заголовки с состоянием, такие как `Cache-Control: private` или` Set-Cookie` для запросов ботов.
Результаты
В настоящее время более 10 тысяч страниц AMP в Yahoo! Путешествия были поданы с SXG. Amppkg очень стабильный и работает без проблем.
Снимок экрана SXG с Android Chrome 74 показан на рисунке 5. Эта страница перемещается с помощью тех же процедур, что и на рис. 1.
URL-адрес издателя https://travel.yahoo.co.jp отображается в омнибоксе, даже если это содержимое не было передано от издателя.
Чтобы увидеть это более четко, на рисунке 6 показана сетевая панель devtool в Desktop Chrome 74 с имитацией мобильного пользовательского агента. Красные линии показывают запросы на предварительную выборку файлов SXG и цепочки сертификатов из кэша AMP по адресу https://travel-yahoo-co-jp.cdn.ampproject.org/. Это означает, что даже если запросы на предварительную выборку были сделаны в SERP, их конфиденциальность была сохранена без доступа к источнику. Когда пользовательский агент был перемещен на сайт SXG, содержимое загружается из локального кэша, и это дает огромный прирост производительности.
Уроки и извлечение из развертывания SXG
Вот список отзывов от развертываний SXG.
- Воздействие на инфраструктуру было ограничено из-за работы по пути URL AMP.
- Влияние пользователя было ограничено только заботой о сканировании ботов.
- Тестирование не было завершено перед выпуском. Сканирование ботов и тестирование AMP-кеша могут быть выполнены после того, как система станет общедоступной в Интернете.
- Необходимо знать, действительно ли содержимое AMP кэшируется.
- Заголовки с отслеживанием состояния, такие как «Cache-control: private» или «Set-Cookie», НЕ включены. Amppkg может проверять эти заголовки, но перед развертыванием необходимо позаботиться о них.
- Конфиденциальные данные НЕ включены в содержимое или заголовки.
- Проверьте, хорошо ли работает содержимое в обоих источниках, поскольку еще не все браузеры поддерживают SXG.
Эти проблемы будут решены, когда у нас будет несколько лучших практик и хороших инструментов развертывания.
Обсуждение
SXG с AMP предоставляет сервису преимущества, связанные с происхождением и повышением производительности издателя, а также сохранением конфиденциальности. Это также позволяет нам распространять контент с любого CDN, не беспокоясь об их происхождении, поскольку он аутентифицирован и проверен.
Как видно из рисунка 1, уверен, что текущий AMP вводит пользователей в заблуждение, показывая другое происхождение, чем у издателя. Будет хуже, если они будут игнорировать, чтобы подтвердить происхождение, потому что они не будут осторожны с фишинговыми сайтами.
Сравнение двух снимков экрана с отображением одной и той же страницы на рисунке 7. Один — SXG, а другой — HTTPS. Разницы между ними нет, если только в сертификате не найден выданный ЦС (рис. 8).
Функции, сравниваемые между HTTPS и SXG, перечислены в таблице 1.
HTTPS защищает свое соединение, в то время как SXG защищает его содержимое. SXG имеет функции безопасности, отличные от HTTPS, так что требования безопасности SXG намного строже, чем требования HTTPS, так что сертификат SXG ограничивается проверенным периодом в течение 90 дней.
В ноябре 2014 года IAB опубликовал «Заявление IAB о конфиденциальности в Интернете» [8]. Телеметрия Firefox показывает 78% веб-страниц, загруженных с использованием HTTPS в апреле 2019 года [9].
С другой стороны, 58% фишинговых веб-сайтов используют SSL / TLS и HTTPS в первом квартале 2019 года с быстрым ростом в эти годы [10]. Согласно статистике phishbank.org, более 90% фишинговых сайтов имеют сертификаты DV. Но было доказано, что даже сертификаты EV могут быть слабыми для фишинга, если его стоимость игнорируется [12]. В 2018 году название компании было удалено в пользовательском интерфейсе Safari при использовании сертификата EV [13].
Чтобы принять меры против фишинга HTTPS, CASC (Совет по безопасности центра сертификации) начал разработку Лондонского протокола [14] в 2018 году, который еще не закончен. В 2018 году Symantec не доверял основным браузерам [15], клиентам необходимо было обновить свои сертификаты.
Очевидно, что нынешние веб-PKI и проверки сертификатов DV, OV и EV имеют проблемы, которым нельзя доверять вслепую в будущем HTTPS везде. Политика выдачи сертификатов SXG еще не определена на форуме CAB [16].
SXG аутентифицирует свое содержимое. Пользователи могут доверять его содержимому, если сертификат SXG выдан доверенным центром сертификации доверенному издателю с проверкой достоверности в отношении его публикации. Они могут распространяться от любых дистрибьюторов через защищенный канал в HTTPS.
Я считаю, что SXG может стать новой платформой для распространения доверенного содержимого, если спецификация охватывает не только формат протокола, но и процедуру проверки выдачи сертификата SXG вместе с форумом CAB. Если это будет достигнуто, новый пользовательский интерфейс для отображения содержимого, проверенного с помощью SXG, приведет пользователей к безопасному использованию Интернета.
Ссылки
1. https://travel.yahoo.co.jp/
2. https://amp.dev/
3. https://www.slideshare.net/techblogyahoo/maximize-yahoo-japans-ux-with-amp-andsigned-http-exchanges-ampconf-141537298
4. https://cdn2.hubspot.net/hubfs/3794894/PDF/Chartbeat%20AMP%20Study_082318%20.pdf
5. https://github.com/WICG/webpackage
6. https://github.com/ampproject/amppackager
7. https://docs.digicert.com/manage-certificates/certificate-profile-options/get-your-signed-http-exchange-certificate/
8. https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/
9. https://letsencrypt.org/stats/#percent-pageloads
10. https://www.thesslstore.com/blog/58-of-phishing-websites-now-use-https/
11. https://cabforum.org/wp-content/uploads/London-Protocol-Presentation.pdf
12. https://stripe.ian.sh/
13. https://cabforum.org/wp-content/uploads/201806AppleCABF.pdf
14. https://casecurity.org/2018/06/27/casc-announces-launch-of-london-protocol-to-improve-identity-assurance-and-minimize-phishing-on-identity-websites/
15. https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html
16. https://cabforum.org/
