Проблемы с HTTP Strict Transport Security (HSTS)
От: Буравчик Россия  
Дата: 22.03.17 06:30
Оценка:
Последнее время стал наталкиваться на сайты, для которых не применились css-стили, т.е. голый текст.
Когда стал подробнее разбираться, оказалось, что CSS действительно не загружаются из-за ошибки безопасности.

Например, эта страница не отображается:
https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20format%20specification.md

Она подгружает CSS, который находится по адресу:
https://assets-cdn.github.com/assets/frameworks-5b61aadc846f0818981ceec31b49c475fb084c163fdec5efbc2c21ef539092a9.css

Но firefox при загрузке этой страницы пишет:

Владелец assets-cdn.github.com неправильно настроил свой веб-сайт. Чтобы защитить вашу информацию от кражи, Firefox не соединился с этим веб-сайтом.

Этот сайт использует HTTP Strict Transport Security (HSTS), чтобы указать, что Firefox должен подключаться к нему только через защищённое соединение. В результате, добавление исключения для этого сертификата невозможно.


Почему это происходит? Как исправить?



23.03.17 09:43: Перенесено по просьбе автора — ShaggyOwl
Best regards, Буравчик
Re: Проблемы с HTTP Strict Transport Security (HSTS)
От: Буравчик Россия  
Дата: 22.03.17 07:19
Оценка: 6 (1)
Здравствуйте, Буравчик, Вы писали:

Б>Но firefox при загрузке этой страницы пишет:

Б>

Б>Владелец assets-cdn.github.com неправильно настроил свой веб-сайт. Чтобы защитить вашу информацию от кражи, Firefox не соединился с этим веб-сайтом.

Б>Этот сайт использует HTTP Strict Transport Security (HSTS), чтобы указать, что Firefox должен подключаться к нему только через защищённое соединение. В результате, добавление исключения для этого сертификата невозможно.


Захожу из chrome — страница с CSS загружется, говорит соединение защищенное и все ок
Захожу из firefox — выдает ошибку выше, соединение не защищенное

Проверил сертификат здесь, говорит, все ок:
https://www.sslshopper.com/ssl-checker.html#hostname=https://assets-cdn.github.com/assets/frameworks-5b61aadc846f0818981ceec31b49c475fb084c163fdec5efbc2c21ef539092a9.css

Адрес assets-cdn.github.com соответствует ip 151.101.192.133
Захожу на этот ip, получаю сообщение, что доступ ограничен РосКомНадзором!

Это он во всем виноват??? Может провайдер в связи с блокировкой что-то подменяет, и делает это неправильно (ну там, сертификаты неправильно передает и т.п.).

Но почему chrome работает? Не замечает "подмен"? Или их нет?
Best regards, Буравчик
Re[2]: Проблемы с HTTP Strict Transport Security (HSTS)
От: Буравчик Россия  
Дата: 22.03.17 07:42
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Но почему chrome работает? Не замечает "подмен"? Или их нет?


nslookup выдал:

C:\Users\Dima>nslookup assets-cdn.github.com
github.map.fastly.net
Addresses: 151.101.0.133
151.101.192.133
151.101.64.133
151.101.128.133
Aliases: assets-cdn.github.com


Адрес 151.101.192.133 заблокирован (выдает страницу о блокировке), остальные адреса нет

Прописал 151.101.0.133 в файл hosts, чтобы firefox лазил на него при обращении к assets-cdn.github.com. И все заработало!

Значит виноват все-таки надзор и блокировка!
Но почему-же на chrome не влияет эта блокировка? Значит ли это, что chrome проксирует трафик? Или ему просто повезло и он подхватил "чистый" ip?

P.S. Модераторы, может лучше данную тему в "Безопасность" перенести?
Best regards, Буравчик
Re[3]: Проблемы с HTTP Strict Transport Security (HSTS)
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 23.03.17 08:19
Оценка: 13 (3)
Здравствуйте, Буравчик, Вы писали:

Б>Но почему-же на chrome не влияет эта блокировка? Значит ли это, что chrome проксирует трафик? Или ему просто повезло и он подхватил "чистый" ip?


Chrome использует виндовое хранилище сертификатов, а Firefox собственное. Возможно, у вас в системе установлен корневой сертификат, которым ваш провайдер подписывает свои сертификаты для подмены трафика блокированных сайтов.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[4]: Проблемы с HTTP Strict Transport Security (HSTS)
От: Буравчик Россия  
Дата: 24.03.17 20:05
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Chrome использует виндовое хранилище сертификатов, а Firefox собственное. Возможно, у вас в системе установлен корневой сертификат, которым ваш провайдер подписывает свои сертификаты для подмены трафика блокированных сайтов.


Интересно, но не то.

Словил такую же ошибку и на chrome (когда хром тоже попал на заблокированный ip). Так что виноват оказался провайдер и надзор со своими блокировками.
Best regards, Буравчик
Re[5]: Проблемы с HTTP Strict Transport Security (HSTS)
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 24.03.17 20:14
Оценка: :))) :)
Здравствуйте, Буравчик, Вы писали:

Б>Словил такую же ошибку и на chrome (когда хром тоже попал на заблокированный ip). Так что виноват оказался провайдер и надзор со своими блокировками.


Жаль. Мой вариант был и параноидальнее, и подразумевал теорию заговора провайдеров, которую можно было бы обсудить ^_^
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[6]: Проблемы с HTTP Strict Transport Security (HSTS)
От: Ops Россия  
Дата: 25.03.17 22:24
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Жаль. Мой вариант был и параноидальнее, и подразумевал теорию заговора провайдеров, которую можно было бы обсудить ^_^


Мне интересно, как в твоем варианте сертификат должен попадать в систему.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[7]: Проблемы с HTTP Strict Transport Security (HSTS)
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 25.03.17 23:00
Оценка: 3 (1)
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Жаль. Мой вариант был и параноидальнее, и подразумевал теорию заговора провайдеров, которую можно было бы обсудить ^_^

Ops>Мне интересно, как в твоем варианте сертификат должен попадать в систему.

Ну, к примеру, у большинства провайдеров есть собственные утилиты для настройки соединения. Которые требует прав локального админа. Вполне годный вектор. Некоторые провайдеры предлагают брендированные версии браузеров, бесплатные версии платных антивирусов и прочей шелухи... да мало ли вариантов?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[2]: Проблемы с HTTP Strict Transport Security (HSTS)
От: wildwind Россия  
Дата: 26.03.17 07:29
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Адрес assets-cdn.github.com соответствует ip 151.101.192.133

Б>Захожу на этот ip, получаю сообщение, что доступ ограничен РосКомНадзором!

В реестре этот IP не находится. Значит, виноват прежде всего твой провайдер, который не умеет/не хочет блокировать по URL.
Re[3]: Проблемы с HTTP Strict Transport Security (HSTS)
От: Буравчик Россия  
Дата: 26.03.17 09:48
Оценка:
Здравствуйте, wildwind, Вы писали:

W>В реестре этот IP не находится. Значит, виноват прежде всего твой провайдер, который не умеет/не хочет блокировать по URL.


Да, не находится. Но провайдер подтвердил, что ip заблокирован именно Роскомнадзором.
Я оставил им заявку про пару сайтов с такой проблемой. Обещали разблокировать. Если я правильно понял, то они блокируют ip, но при поступлении заявок разблокируют по url.

P.S. Подумываю, настроить какой-нибудь локальный dns, который среди имеющихся у домена адресов выдавал бы только те, которые в настоящий момент не заблокированы.
Best regards, Буравчик
Re[4]: Проблемы с HTTP Strict Transport Security (HSTS)
От: wildwind Россия  
Дата: 26.03.17 16:14
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Я оставил им заявку про пару сайтов с такой проблемой. Обещали разблокировать. Если я правильно понял, то они блокируют ip, но при поступлении заявок разблокируют по url.


Это вряд ли. Не вижу в этом практического смысла. Если техническая возможность блокировать по URL имеется, провайдеру гораздо проще так и делать, чем иметь дело с вашими заявками.

Б>P.S. Подумываю, настроить какой-нибудь локальный dns, который среди имеющихся у домена адресов выдавал бы только те, которые в настоящий момент не заблокированы.


Есть готовые решения, проксирующие только заблокированные сайты. Например: https://antizapret.prostovpn.org/
Re[5]: Проблемы с HTTP Strict Transport Security (HSTS)
От: Буравчик Россия  
Дата: 26.03.17 16:25
Оценка:
Здравствуйте, wildwind, Вы писали:

W>Это вряд ли. Не вижу в этом практического смысла. Если техническая возможность блокировать по URL имеется, провайдеру гораздо проще так и делать, чем иметь дело с вашими заявками.


Но тогда провайдер не сможет отчитаться перед Роскомандзором о том, что они заблокировал плохой ip И у него заберут лицензцию.
А насчет заявки: оператор спросил урл, подтвердил, что часть ip адресов заблокирована, принял заявку. Позже отчитался о выполнении заявки и сказал, что теперь с этим сайтом будет все ок. Также предложил назвать и другие урлы
Best regards, Буравчик
Re[5]: Проблемы с HTTP Strict Transport Security (HSTS)
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 26.03.17 17:23
Оценка:
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Буравчик, Вы писали:

W>Если техническая возможность блокировать по URL имеется, провайдеру гораздо проще так и делать, чем иметь дело с вашими заявками.


Блокировка по URL возможна только на прикладном уровне и только, если не используется TLS (либо все пользователи провайдера должны иметь у себя в доверенных корневой сертификат провайдера, чтобы тот мог MitM'ить весь трафик). Чем больше правил на шлюзе с DPI, тем меньше его пропускная способность. Блокировка же по IP возможна уже на сетевом уровне, она существенно меньше влияет на пропускную способность шлюза и ей побоку все эти TLS'ы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[6]: Проблемы с HTTP Strict Transport Security (HSTS)
От: wildwind Россия  
Дата: 26.03.17 18:40
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Но тогда провайдер не сможет отчитаться перед Роскомандзором о том, что они заблокировал плохой ip И у него заберут лицензцию.


Если в реестр внесен URL, то и отчитываться провайдер должен за URL, даже если владелец сайта сменит IP адрес.
Re[6]: Проблемы с HTTP Strict Transport Security (HSTS)
От: wildwind Россия  
Дата: 26.03.17 18:53
Оценка: +1
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Блокировка по URL возможна только на прикладном уровне и только, если не используется TLS (либо все пользователи провайдера должны иметь у себя в доверенных корневой сертификат провайдера, чтобы тот мог MitM'ить весь трафик). Чем больше правил на шлюзе с DPI, тем меньше его пропускная способность. Блокировка же по IP возможна уже на сетевом уровне, она существенно меньше влияет на пропускную способность шлюза и ей побоку все эти TLS'ы.


Я в курсе. Серьезные системы маршрутизируют трафик на DPI шлюз по IP, а там уже анализируют URL. На остальной трафик и общую ПС сети это почти не влияет. Если только проблемный IP не принадлежит Youtube или VK.

Блокировка по URL (точнее, по доменному имени) при использовании TLS также возможна, по SNI.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.