HTTP - HTTPS

HTTP может также использоваться в роли «транспорта» для таких протоколов прикладного уровня как SOAP, WebDAV.

HTTPS (HyperText Transfer Protocol Secure) — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, инкапсулируются в криптографический протокол SSL или TLS. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.

В 1994 году это расширение создала компания Netscape Communications для своего браузера Netscape Navigator. HTTPS используется и поддерживается всеми популярными браузерами.

Принцип работы

Действие протокола HTTP происходит по следующему принципу: программа-клиент осуществляет TCP-соединение с сервером (стандартный номер порта-80) и выводит ему HTTP-запрос. Сервер прорабатывает данный запрос и выдает HTTP-ответ клиенту.

2022: Протокол HTTP 3.0 получил статус предложенного стандарта

7 июня 2022 года стало известно о том, что комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для протокола HTTP 3.0 и опубликовал связанные с ним спецификации под идентификаторами RFC 9114 (протокол) и RFC 9204 (технология сжатия заголовков QPACK для HTTP 3). Спецификация HTTP 3.0 получила статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний. Одновременно опубликованы обновлённые варианты спецификаций для протоколов HTTP 1.1 (RFC 9112) и HTTP 2.0 (RFC 9113), а также документы, определяющие семантику HTTP-запросов (RFC 9110) и HTTP-заголовки управления кэшированием (RFC 9111).

Протокол HTTP 3.0 получил статус предложенного стандарта

Как сообщалось, протокол HTTP 3 определяет использование протокола QUIC (Quick UDP Internet Connections) в качестве транспорта для HTTP 2. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS SSL. Протокол был создан в 2013 году компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных.

На июнь 2022 года поддержка QUIC и HTTP 3.0 уже реализована во всех популярных web-браузерах (в Chrome, Firefox и Edge поддержка HTTP 3 включена по умолчанию, а в Safari требует включения настройки "Advanced - Experimental Features - HTTP 3"). На серверной стороне реализации HTTP 3 доступны для nginx (в отдельной ветке и в форме отдельного модуля), Caddy, IIS и LiteSpeed. Поддержку HTTP 3 также обеспечивает сеть доставки контента Cloudflare.

Основные особенности QUIC:

• Надлежащая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);
• Контроль за целостностью потока, предотвращающий потерю пакетов;
• Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаев данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);
• Использование при повторной передаче пакета другого номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;
• Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
• Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
• Границы криптографических блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
• Отсутствие проблем с блокировкой очереди TCP;
• Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
• Возможность подключения расширенных механизмов контроля перегрузки соединения;
• Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
• Заметный прирост производительности и пропускной способности по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.

Из изменений в спецификации HTTP 1.1 можно отметить запрет на обособленное использование символа возврата каретки (CR) вне тела с содержимым, т.е. в элементах протокола символ CR может применяться только вместе с символом перевода строки (CRLF). Алгоритм компоновки chunked-запросов доработан для упрощения разделения прикреплённых полей и секции с заголовками. Добавлены рекомендации по обработке неоднозначного содержимого для блокирования атак класса "HTTP Request Smuggling", позволяющих вклиниваться в содержимое запросов других пользователей в потоке между фронтэндом и бэкендом.

В обновлении спецификации HTTP 2.0 явно определена поддержка TLS 1.3. Переведена в категорию устаревших схема определения приоритетов и связанные с ней поля в заголовках. Объявлен устаревшим не получивший распространения механизм обновления соединения с HTTP 1.1. Сокращены требования к проверке имён полей и значений. Предложены для использования некоторые ранее зарезервированные типы кадров и параметры. Более точно определены запрещённые поля заголовков, относящиеся к соединению^[1].

2019

Google придумала, как заставить сайты перейти на HTTPS

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

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

Тем не менее, в последнее время компании Google и Mozilla, каждая по своему, активно продвигают HTTPS. Mozilla и ее партнеры запустили сервис Let's Encrypt, предоставляющий бесплатные, простые в развертывании TLS-сертификаты. В свою очередь, Google Chrome стал обозначать загружаемые по HTTP сайты как небезопасные (Not Secure).

Теперь же Google намерена пойти еще дальше и заставить сайты полностью перейти на HTTPS. Начиная с версии Chrome 79, в браузер постепенно будут вноситься изменения, которые в итоге приведут к полной блокировке «смешанного контента» по умолчанию. Уже в Chrome 80 «смешанные» аудио и видео будут автоматически обновляться до HTTPS. В случае невозможности загрузки контента по HTTPS, он будет блокироваться. В Chrome 81 этот подход будет также применяться к «смешанным» изображениям.^[2]

Власти Казахстана перехватывают трафик Facebook, Google и «ВКонтакте»

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

Правительство Казахстана начало перехватывать весь HTTPS-трафик в стране

17 июля 2019 года правительство Казахстана начало перехватывать весь интернет-трафик HTTPS в стране. Для этого местных телекоммуникационных операторов обязали к тому, чтобы заставлять пользователей на все свои устройства и в браузеры специальный сертификат, разработанный властями.

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

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

Без установки сертификата зайти на сайты с HTTPS (а таких большинство) нельзя — интернет-провайдер блокирует доступ и выдаёт страницу-заглушку, подобную той, которая представлена ниже.

Жителей Казахстана обязали установить сертификат безопасности «для защиты от хакерских атак и просмотра противоправного контента»

На этой странице выведено следующее сообщение:

Целью применения сертификата безопасности является ограничение распространения по сети телекоммуникаций запрещенной законодательством информации.

Пользователям предлагает перейти по ссылке для установки сертификата. Некоторым абонентам поступили SMS с напоминанием "в соответствии с Законом "О связи" ст. 26" установить сертификат на все выходящие в интернет устройства.

Операторы Kcell и Activ заявили, что сертификат был внедрен из-за участившихся случаев хищения персональных данных казахстанцев и кражи денег с их банковских карт. Он защитит абонентов «от хакерских атак и просмотра противоправного контента». У сертификата не будет доступа к персональным данным абонента, утверждают Kcell.^[3]

2018: 20% крупнейших сайтов не используют HTTPS

В апреле 2019 года стало известно о том, что 20% крупнейших в мире сайтов не используют протокол HTTPS с поддержкой шифрования, несмотря на ограничения, которые с которыми они сталкиваются в связи с этим.

По данным Google, 79 из 100 наиболее популярных веб-ресурсов, не связанных с компанией, не используют сертификат для защищенных HTTPS-соединений. Такую безопасность игнорируют, в частности, крупнейшая в мире база данных и интернет-портал о кинематографе IMDB и газета The New York Times. Правда, HTTP применяется не на всех страницах сайтов указанных и других крупных компаний.

Для установки безопасного соединения в интернете используется протокол HTTPS с поддержкой шифрования.

Авторы рейтинга Alexa, собирающие статистику о посещаемости сайтов, составили список ресурсов, которые автоматически не перенаправляют небезопасные запросы в ответ на безопасные. Данные Google подтверждаются: 20% из наиболее посещаемых сайтов относятся к разряду небезопасных.

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

Раньше внедрение HTTPS было весьма дорогостоящим для сайтов, особенно небольших, но к апрелю 2019 года работает множество компаний, предлагающих бесплатную и очень быструю установку SSL-сертификатов. Например, можно отметить сервис Lets's Encrypt, обеспечивающий автоматическую выдачу бесплатных сертификатов для TLS-шифрования и поддерживаемый Google на правах платинового члена.

Однако крупные сайты не спешат полностью переходить на HTTPS, считая эту миграцию технически сложной и зачастую невыгодной. Планируя такой переход, компании, как правило, задают себе несколько вопросов: «Не станет ли сеть доставки дороже в случае с HTTPS?», «Будет ли сторонний контент на сайте учитывать переход на HTTPS?» и др. Компании приходится проводить множество тестирований и исправлять многочисленные ошибки перед тем, как протокол начнет нормально функционировать.

Если HTML-ресурсы, которые предоставляет компания, имеют ссылки (картинки, скрипты…) на разные хосты и не используются относительные URL, то переход на HTTPS осложняется.

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

Кроме того, по словам эксперта в области информационной безопасности Malwarebytes Жерома Сегуры (Jérôme Segura), HTTPS не гарантирует 100-процентную безопасность. Например, некоторые сайты могут задействовать протокол на главной странице, но не включить его в другие страницы и сервисы.^[4]

Сайты, имеющие сертификаты HTTPS, помечаются браузерами значком в виде замка

Проверка 10 000 ведущих сайтов из рейтинга Alexa показала следующее: многие из них подвержены критическим уязвимостям протоколов SSL/TLS, обычно через поддомены или зависимости. Уязвимые криптографические конфигурации выявлены на 5574 хостах, то есть примерно на 5,5% от общего количества.

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

2017

Россия: число сайтов с SSL-сертификатами за год выросло в четыре раза

По данным аналитического сервиса StatOnline, в российских национальных доменных зонах количество сайтов, использующих SSL-сертификаты, за год выросло в четыре раза. В июле 2015 года в зоне .RU количество таких ресурсов составляло 109 тыс., в том же месяце 2016 года — 189 тыс., а в июле 2017 года — 531 тыс. Для сравнения, показатели зоны .РФ составляли 18 тыс., 21 тыс. и 65 тыс. соответственно. По состоянию на август 2017 года, всего в зоне .RU насчитывается 5,5 млн сайтов, в зоне.РФ — 900 тыс., передают «Известия».^[5]

HTTPS-протокол призван защитить данные пользователей от перехвата. Согласно обещаниям Google, ссылки на ресурсы, которые всё еще не перешли на HTTPS, с начала 2018 года будут отображаться в результатах поиска с предупреждением об их небезопасности. С похожей инициативой выступила и компания Mozilla, выпускающая браузер Firefox.

SSL-сертификаты — уникальная цифровая подпись сайта, необходимая для организации защищенного соединения между браузером интернет-пользователя и сервером. Обычные сайты используют для обмена данными протокол HTTP, ресурсы с сертификатом — защищенный HTTPS. SSL-сертификаты выпускаются на разные сроки. По данным StatOnline, наиболее распространенный период действия SSL-сертификата — менее 1 года. В зоне .RU число таких сертификатов составляет 82% от общего числа, а в зоне .РФ — 95%.

Антивирусы влияют на безопасность HTTPS

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

В составе группы действовали специалисты Mozilla, Google, CloudFlare, представители университета Мичигана, иллинойсского университета в Урбан-Шампейне, калифорнийского университета в Беркли и Международного института информатики^[6].

Эксперты подозревали о влиянии инструментов защиты на защищенные соединения, в результате чего зашифрованный трафик подвергается риску и безопасность ослабевает. Они оказались правы в своих подозрениях. Исследователи проанализировали подтверждения сессий связи (handshakes), связанных с браузерами, антивирусными продуктами и вредоносными программами, и на основе этого создали эвристические методы контроля перехвата и вмешательства в HTTPS, определения субъекта перехвата трафика.

Созданные для тестов инструменты разместили на серверах Mozilla Firefox, CloudFlare CDN и сайтах электронной коммерции. Анализ показал: 4% соединений Firefox, 6,2% соединений e-commerce сайтов и 11% соединений CloudFlare перехвачены. После чего большинство этих соединений стали менее безопасны (97% применительно к Firefox, 54% для CloudFlare и 32% для e-commerce ресурсов). Безопасность более 62% процентов соединений ослабла до относительно приемлемого уровня, а 58% соединений стали подвержены критическим уязвимостям.

По мнению экспертов, беспокойство вызывает не только то, что перехватчики соединений использовали более слабые криптографические алгоритмы, но и то, что 10-40% из них объявили о поддержке давно взломанных шифров, что позволяет атакующему в позиции Man in the middle (MITM) перехватить соединение, произвести downgrade и расшифровать его.

Исследователи изучили работу продуктов A10 Networks, Blue Coat, Barracuda, Check Point, Cisco, Forcepoint, Fortinet, Juniper Networks, Microsoft, Sophos, Untangle и WebTitan. Из этого списка только технологии Blue Coat, по мнению исследователей, обращались с TLS-соединениями корректно. Остальные продукты получили 2-3 балла по пятибалльной шкале из-за уязвимостей и потенциальных MitM-атак.

Таблица оценки влияния антивирусных систем на трафик HTTPS, (2017)

2016: Только 5% HTTPS-серверов используют корректно настроенный HSTS

По данным компании Netcraft, 95% от всех использующихся в мире HTTPS-серверов уязвимы к хакерским атакам из-за неправильно настроенного механизма HSTS или его отсутствия. Как показали результаты исследования, только 5% изученных экспертами HTTPS-серверов используют корректно настроенный HSTS. Подобное исследование также проводилось три года назад, и с тех пор практически ничего не изменилось. По мнению исследователей, администраторы либо не знают о проблеме, либо относятся к ней недостаточно серьезно.

HSTS активирует форсированное защищенное соединение через HTTPS вместо HTTP. В настоящее время данный механизм поддерживается браузерами Internet Explorer (браузер) 11, Microsoft Edge, Firefox, Chrome, Safari и Opera. С его помощью администраторы web-ресурсов могут предотвращать атаки «человек посередине», манипуляции с файлами cookie и т.д.

Как сообщают эксперты, простейший сценарий атаки выглядит следующим образом: пользователь вводит в строку поиска адрес сайта, указывая http:// вместо https://. Ресурс без поддержки HSTS открывается через HTTP, и у злоумышленников появляется возможность осуществить фишинговую атаку или атаку «человек посередине».

2015

Браузеры способствуют существованию фальшивых сайтов

Браузеры Google (Chrome), Microsoft (Internet Explorer (браузер)), Apple (Safari) и Mozilla (Firefox) позволяют нарушать режим безопасного использования информации программам вроде Superfish, PrivDog, Gogo и аналогичным. Они делают это путем бездействия^[7].

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

Это необходимо потому, что конструкция Интернета делает возможным жульническую подмену имен сайтов. То есть, пользователь заходит на somebankingsite.com, а вместо реального банка это может быть дубликат сайта, созданный для обмана пользователей самыми разными способами.

Один из способов защиты против этого — файл цифрового сертификата. Так же, как почтовый штемпель показывает — где и когда письмо было отправлено по почте, файл сертификата должен доказать идентичность сайта.

Для использования защищенного веб-сайта HTTPS, необходимо вначале получить файл сертификата у любой из компаний в бизнесе по их продаже. Эти компании называют Центрами Сертификации (Certificate Authorities). Они берут на себя хлопоты по проверке идентичности субъекта, делающего запрос.

Технари упоминают файл сертификата, как «сертификат» или, чаще всего, просто «cert». Иногда его называют «сертификат HTTPS» или «сертификат шифрования». Google называет его «сертификат безопасности».

Чтобы подтвердить свою идентичность, сайты, использующие SSL-сертификаты, предоставляют сертификаты безопасности для Chrome, например. Любой желающий может создать веб-сайт, притворяющийся другим сайтом, но только реальный сайт имеет действительный сертификат безопасности для конкретного URL. Недействительные сертификаты могут означать: кто-то пытается манипулировать подключением к сайту.

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

Одна из самых больших уязвимостей в системе в том, что любой Центр Сертификации (CA) может поручиться за любой веб-сайт. При этом, существуют сотни Центров Сертификации, у каждого имеются субподрядчики, которые также могут выдавать сертификаты.

Помимо этого, никто не знает эти компании. GeoTrust, Entrust, USERTrust, GTE CyberTrust, Starfield, CertPlus, DigiCert и Thawte не являются общеизвестными. Почтамт Гонконга, например, является доверенным Центром Сертификации. Кто будет доверять веб-узлу, идентичность которого удостоверена почтамтом Гонконга? Браузеры в пользовательских системах доверяют.

Компании-вендоры веб-браузеров, не создавали эту уязвимую систему, но они способствуют ей, скрывая происходящее от пользователей.

Нет сомнения, что Microsoft, Apple, Google и Mozilla будет указывать на то, что имя поручающегося Certificate Authority легко доступно. Технически, это так. Реально это не так, по крайней мере, не для не-технарей, которые нуждаются в этом больше всего.

Чтобы увидеть имя Certificate Authority, потребуется совершить несколько манипуляций, а маршрут передвижения никто никогда не объясняет новичкам. И эти манипуляции отличны для каждого браузера.

Рассмотрим действия на платформе Windows. Существует несколько путей по раскрытию имени CA.

В Firefox 36 (и выше), необходимо нажать на замок, слева от адреса сайта в адресной строке. Во всплывающем окне появится «Подтверждено» и имя Центра Сертификации.

В Chrome 41 название компании темно-зеленое в светло-зеленом прямоугольнике. Нужно нажать на название компании или на замок рядом с адресом, затем на слово «Соединения». Это не сразу понятно, в появившемся окне есть две вкладки — одна для Разрешений, другая для Соединений.

По какой-то причине, визуальный дизайн этих вкладок полностью отличается от вкладок браузера прямо над ними. На вкладке Соединения видно название Центра Сертификации.

В Internet Explorer 11 надо щелкнуть на замке с правой стороны адресной строки. В появившемся окне видно информацию об идентификации веб-сайта. Внизу окна щелкнуть Просмотр сертификатов и видно подробную информацию о Центре Сертификации, кому он выдан и сроках действия.

В Opera 27 требуется нажать на название компании, отображаемое зеленым цветом рядом с черным названием сайта, или на замок слева от адреса. Затем, нажать на слово «Подробнее». Название Центра Сертификации показывается, но он не идентифицирован, как таковой.

Браузер Vivaldi technical preview 2 предлагает секретный намек. Если навести курсор мыши на название компании, отображаемое зеленым цветом, слева от имени сайта, всплывающее окно покажет «информацию о сайте». После нажатия, цвет фона меняется со светло-зеленого до темно-зеленого. Нажатие на название компании вызовет окно, которое выглядит так же, как в Chrome — с вкладками Разрешения и Соединения.

В Safari на OS X необходимо нажать на маленький зеленый замок слева от названия компании.

Два браузера iOS 8 работают как Джекил и Хайд. Chrome не показывает название компании, только адрес. Safari, напротив, показывает только название компании и скрывает URL.

Хуже всего в Safari на iOS 8 то, что независимо от того, где ни щелкай, ни нажимай или наводи, он не выдаст название Центра Сертификации для безопасных веб-сайтов. Он не показывает даже полные URL-адреса. Chrome на Android также не в состоянии идентифицировать поручительства Центра Сертификации для защищенного веб-сайта.

Странное совпадение, что в наиболее популярных браузерах на iOS и Android отсутствует важная функция безопасности.

В скриншотах выше заметно, что Центр Сертификации никогда не идентифицируется как таковой. Разработчики интерфейса решили, что все на планете уже знакомы с системой.

В Windows, Firefox, Chrome и Vivaldi используется слово «подтверждено», Internet Explorer (браузер) использует «определил веб-сайт как», а Opera просто показывает имя.

Лучшее объяснение в Safari на OS X: Компания X определила сайт Y, как принадлежащий компании Z. Довольно просто. Но даже это объяснение не определяет Certificate Authority как Certificate Authority (Центр Сертификации), что делает ситуацию гораздо сложнее для не-технарей.

Добавляет путаницы название Центров Сертификации. В приведенных выше примерах Bank Of America, видно четыре различных названия: VeriSign Inc, VeriSign (без Inc), Symantec Corporation и Symantec Class 3 EV SSL CA — G3.

Как Центр Сертификации может использовать четыре названия?

Отчасти это происходит из файла сертификата, имеющего несколько встроенных имен для каждого Центра Сертификации. Chrome отображает «общее название», а Firefox выводит «Название организации». Ни один из браузеров не показывает название «Организационной единицы», которое, в данном случае, «Symantec Trust Network».

Несколько имен возникают из-за использования субподрядчиков (технари используют другой термин, но он лучше представляет концепцию) Центров Сертификации.

Эти субподрядчики, в свою очередь, могут иметь собственных субподрядчиков. На самом деле, один корневой CA никогда не ручается за индивидуальный сайт, это делает субподрядчик самого низкого уровня. Так, какое название должен показывать браузер? То, которое у субподрядчика самого низкого уровня, промежуточного субподрядчика или Центра Сертификации высокого уровня?

В примерах с Bank Of America, браузеры сообщали, что VeriSign подтверждающая этот веб-сайт, получила название либо от CA-субподрядчика среднего уровня, или от оригинального CA (известного среди технарей, как корневой центр сертификации).

И все становится еще хуже.

В случае с Bank of America, технари знают, что Symantec купила VeriSign, так что эти два названия, по сути, одно и то же.

Но действительно ли Bank of America использует VeriSign? Может быть, они используют DigiCert или GeoTrust или Thawte. Как узнать? Единственный способ - если родственник работает в этом банке.

Кто еще думает, что определение «мошенничество» слишком сурово?

При этом вполне понятно, как работал Superfish.

Человек посередине (Man in the middle)

Superfish размещает себя между жертвой и остальным миром. Когда клиенты Lenovo думали, что у них установлено безопасное соединение с somebankingsite.com, его на самом деле не было. У них было безопасное соединение с программным обеспечением Superfish на их ПК с Windows 8.

Кроме того, банк тоже обманули, заставляя думать, что он общается непосредственно с клиентом. На самом деле, банк также общался с Superfish. Это классическая атака посредника, атака «человек посередине», MitM-атака^[8].

В старые времена, только плохие парни и шпионы проводили атаки посредника. Теперь рекламные компании делают это.

Классическая атака "человека посередине" использовала незащищенное соединение HTTP между веб-браузером и мошенником. Если происходит замена HTTPS на HTTP, то должен отсутствовать значок замка. С тех времен многие вещи изменились.

Superfish может скрыть свое присутствие представлением веб-браузеру файла сертификата - не настоящего файла-сертификата, а того, который Superfish создает "на лету". Независимо от того, какой защищенный веб-сайт HTTPS клиент Lenovo посещал, Superfish динамически создавал сертификат для него.

Другая часть атаки заставляет веб-браузеры доверять сертификатам от Superfish. Нормальные компьютеры так не делают.

Долгие месяцы клиенты Lenovo не замечали, что Superfish ручается за каждый защищенный веб-сайт в мире. Это свидетельствует о том, что найти название Certificate Authority довольно трудно. Gogo долго выпускал мошеннические сертификаты YouTube, пока этого не заметил сотрудник Google.

Веб-браузеры должны четко показывать Certificate Authority на видном месте - лучше заставить пользователя "щелкать", для сокрытия названия, а не для его показа. Браузеры должны пролить свет на систему, функционирующую в темноте.

Существовавшая некогда компания розничной торговли Sy Syms использовала слоган для рекламы: «Образованный потребитель — наш лучший клиент». В мире технологий все не так. Возникает стойкое чувство, что есть цель - удержание в неведении технически неграмотных пользователей.

Если имя Центра сертификации (Certificate Authority) будет на видном месте в окне браузера, конечные пользователи могут получить некоторые преимущества:

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

Спецслужбы не любят образованных потребителей. Нынешняя система служит им хорошо. Они могут предложить мошенническую копию веб-сайта и поручиться за него сертификатом от скомпрометированного Центра Сертификации. Компрометация одного CA, позволяет им поручиться за любой веб-сайт, пока скрыто название CA. Если бы мы могли видеть, что Центр Сертификации Harveys ручается за Bank of America, афера бы не сработала.

Все зависит от Google, Apple, Mozilla и Microsoft. Им стоит показать своим потребителям название Центров Сертификации, подтверждающих подлинность, якобы, безопасных веб-сайтов.

Идентичность Certificate Authority очень важный аспект во взаимном доверии между потребителями и поставщиками данных.

Спецификации HTTP/2

18 февраля 2015 года стало известно о предстоящих усовершенствованиях протокола HTTP. Цель модернизации - значительное ускорение загрузки страниц.

Разработкой спецификаций протокола занималась рабочая группа IETF HTTP.

HTTP2 – первый значимый апдейт протокола с 1999 года, когда на свет вышла версия HTTP под номером 1.1. Обновление ускорит загрузку интернет-страниц, улучшит качество интернет-соединений с удалёнными серверами, оптимизирует работу кэша на компьютере, чтобы браузеру не приходилось загружать одни и те же данные по нескольку раз, нагружая интернет-канал.

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

Корпорация Google официально заявила, что постарается перейти на протокол HTTP/2 максимально оперативно, чтобы ускорить загрузку данных для пользователей Интернета. Разработчики, заинтересованные в обновлённом протоколе, могут получить доступ к его спецификациям.

Основные особенности цифрового протокола HTTP2:

• Повышение эффективности использования сетевых ресурсов за счёт мультиплексирования запросов, расстановки приоритетов для запросов и сжатия заголовков HTTP, проактивных push-ответов со стороны сервера.
• Серьёзное увеличение производительности для современных браузеров и мобильных устройств.
• Возможность развёртывания в современном интернете, используя IPv4 и IPv6 и не забывая о NAT.
• Упрощение развёртывания решений на основе HTTP.
• Обеспечение современных требований к безопасности.

В основе HTTP/2 протокол SPDY^[9].

2014: Сайты с доступом по HTTP перейдут в разряд "опасных"

17 декабря 2014 года стало известно о предстоящей в 2015 году изменении в системе предупреждений браузера о небезопасных соединениях.

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

На 17 декабря 2014 года предупреждение появляется только в случае HTTPS-соединения, сертификат которого устарел или считается недопустимым (невалидным) и в то же самое время незащищённые каналы считаются браузером заслуживающими доверия, что не соответствует реалиям.

Согласно планам Chrome Security Team, будут определены три уровня безопасности:

• безопасное соединение с доступом по валидному HTTPS;
• сомнительное соединение, где в основном применяется доступ по HTTPS, но некоторые ресурсы используют обычный HTTP или имеются несущественные ошибки TLS;
• небезопасное соединение, где применяется обычный HTTP или некорректный HTTPS.

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

Смотрите также

• Криптография
• Криптография в цифровых технологиях
• ИБ - Средства шифрования
• PKI
• HTTPS
• DNS поверх HTTPS (DNS-over-HTTPS, DoH)
• SSL
• Электронная подпись (ЭЦП)

• Описание протокола HTTP
• HTTPS

Примечания