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

Использование протокола, очевидно связано, с безопасностью, однако, я выделяю дополнительно и другие его аспекты.

Работа с сетью

Как было отмечено еще на Google I/O 2014 - HTTPS Everywhere все сетевые взаимодействия должны быть по умолчанию безопасными. Безопасность соединения повышает приватность пользователя, исключает атаки типа человек посередине. Это означает, что не только перехват трафика злоумышленниками будет бесполезен для чтения, но он также будет безуспешен и для его модификации, например, ваш провайдер не сможет вставить на посещаемые вами сайты свой рекламный баннер.

Начиная с версии Chrome 68 для веб-сайтов, которые не используют https, возле адреса прямым текстом пишется Not Secure:

Также выделю легкость в использовании безопасного соединения веб-разработчиком в браузере. Достаточно указать используемый HTTPS протокол в URL, а дальше браузер уже сам сделает за вас весь networking, вне зависимости от используемого WebAPI. Под WebAPI понимаю те, которые работают с сетью: XmlHttpRequest, EventSource, WebSocket. Для WebSocket, HTTPS используется в WebSocket HTTPS Handshake.

Завершая сетевой аспект, добавлю, что версия протокола HTTP/2 в своей основе использует TLS, также как и HTTPS протокол.

Ранжирование в поисковой выдаче Google

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

…over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal.

И если спустя год, например, в отчете Search Engine Ranking Factors 2015 от moz.com можно было найти вывод о слабой корреляции или вывод о слабом влиянии HTTPS на поисковую выдачу, то в статьях последних лет уже говорится о том, что использование HTTPS протокола является факторов ранжирования.

Безопасная работа со смешанным контентом

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

Так среди всего прочего, можно выделить такую особенность как: Strictly block “blockable” mixed content, insecure ‘mixed content’.

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

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

Еще одна фича, которую стоит отметить — blocking insecure downloads from secure (HTTPS) contexts. Chrome блокирует небезопасные загрузки, инициированные из безопасных контекстов:

Безопасный контекст

Другое важное понятие, которое открывает доступ ко множеству браузерных API, это безопасный контекст. Можно было бы назвать статью 10 или даже 15 причин использования HTTPS протокола, только посчитав возможность использования каждого такого браузерного API.

Безопасный контекст — это Window или Worker, для которых соблюдаются определенные минимальные стандарты аутентификации и конфиденциальности. Существует целая спецификация Secure Contexts, которая детальнее раскрывает необходимость и детали контекстов. Основная цель безопасных контекстов — предотвратить атаку человек посередине.

Важным здесь является то, что многие браузерные API доступны только в безопасном контексте, например: Payment Request API, Push API, Storage API, Web Bluetooth и так далее. Кстати вот весь список доступных API на MDN.

Progressive Web Apps

Что такое прогрессивные веб приложения? Если говорить очень грубо и коротко, то это веб-приложения, которые похожи по функционалу на нативные и работающие на том же устройстве, что и нативные, детальнее изучить этот вопрос можно в цикле статей на web.dev.

PWA требуют, что веб-сайты обслуживались HTTPS, более того, API, которые предполагаются в PWA, работают исключительно в безопасном контексте, в частности Service Worker, Notification API, Background Sync API