Как проверить что сайт поддерживает https, не заходя на сайт?

Частично отвечаю самому себе..

Пока дописал топик, пришла простая мысль:

Проверить поддержку того или иного сайта (или какой-то части из общей массы сайтов) на наличие поддержки https, в том числе проверка поддержки https какой-то конкретной ссылки (ссылки на конретную страницу можно просто сделав запрос в поиске того же Google в виде нужной ссылки, добавив к ней приставку "https://" перед обычным www адресом.

Как примеры:
1) Сам linux.org.ru
Скрин: http://itmages.ru/image/view/1507335/60d896c0
и
2) Статья, о которой я упоянул в топике:
Скрин: http://itmages.ru/image/view/1507337/0bec65ae

Как видно из скринов, если тот же Google уже проиндексировал целевой сайт или статью, то можно легко определить наличиие поддержки https нужной ссылки. Минус этого способа конечно же в том, что индексирование любым поисковиком новых статей или сайтов занимает некоторое время и видимо какой-то процент ссылок так не получится проверить быстро (а может и часть ссылок просто не попадут – или исключены из поисковой выдачи?).

Поэтому вопрос специализированного сервиса для проверки поддержки https все-таки актуален.

К примеру, на ютьюб можно заходить по HTTPS. Названия страниц, которые вы там смотрите, исходящему узлу не видны. Но все ролики с этих же страниц идут в открытом HTTP без S. И HTTPS-everywhere здесь принципиально не помогает. Так что поток с youtube можно распарсить. Это касается также многих сайтов со смешанным контентом: изображения и отдельные элементы страницы могут отдаваться в открытом виде.

О Ютубе буду знать..

"Это касается также многих сайтов со смешанным контентом: изображения и отдельные элементы страницы могут отдаваться в открытом виде." имеете ввиду отдельные элементы, которые лежат не на сервере самого сайта (например если сайт хостит изображния на сторонних сайтах (storage)?
Или имеете ввиду что даже элементы лежащие на сервере сайта с https могут отдаваться частично открыто?

Как вариант конечно есть еще – https://ru.wikipedia.org/wiki/Ixquick с его "Startpage также включает бесплатный анонимный веб-прокси, который может открывать веб-сайты, используя их https-прокси ixquick-proxy ("Startpage также включает бесплатный анонимный веб-прокси, который может открывать веб-сайты, используя их прокси сервис"), но этот прокси всегда режет весь Javascript, который все-таки нужен иногда..

Указанная в топике статья через этот прокси – Ссылка

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


Если сайт не поддерживает HTTPS, он иногда не отвечает по 443-ему, а иногда редиректит автоматически на 80-ый (HTTP). И это поведение может ещё и зависеть от конкретных страниц сайта. Автоматические редиректы можно отключить в настройках браузера, но часто они удобны и нужны, т.е. будет некоторое неудобство.

Единственное, что можно посоветовать (хотя я считаю такую цель бредовой) — поставить дополнительный файерволл между браузером и той ОС, что будет его заворачивать в интернет/Tor/ещё куда-то, и зарезать там 80-ый порт. Ну, или даже завести два профиля браузера: один для работы только по HTTPS, а другой незалоченный.


Да. Правда, это приведёт к битости замка в строке адреса. Но если отдача идёт через плагины (как на youtube из-за flash), то даже замок не побьётся.

Или имеете ввиду что даже элементы лежащие на сервере сайта с https могут отдаваться частично открыто?

Почему нет? Достаточно ссылки абсолютные использовать.
А на практике довольно часто статические данные отдают с отдельного сервера на поддомене, чтобы уменьшить нагрузку на основной. И https там запросто может отсутствовать.

Правда, это приведёт к битости замка в строке адреса. Но если отдача идёт через плагины (как на youtube из-за flash), то даже замок не побьётся.

Да.

Решил поискать по поиску расширений Firefox по запросу "https"
и 7-ым результатом нашел HTTP Nowhere. Суть расширения:

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

Вот статья об этом расширении – HTTP Nowhere — полная блокировка незащищенного трафика в Firefox, к минусам можно отнести (из этой статьи):
"HTTP Nowhere не совсем совместим с HTTPS Everywhere. Если включить два расширения одновременно, то они будут работать, но блокируются редиректы HTTPS Everywhere." (о чем сказано и на странице расширения).
Доп инфо по лицензии:

Глянул в поиске по форуму, нашел только одно упоминание – https://www.pgpru.com/comment72015

Я так думаю, можно ведь просто выключать тогда тот же HTTPS Everywhere, вместо него использовать HTTP Nowhere как полноценную и более функциональную замену, когда надо попользоваться конкретным https-сайтом? Хотя наверное HTTP Nowhere может создать дополнительное профилирование ввиду немассовости как у HTTPS Everywhere, который сейчас ставиться в Tor "прямо из коробки"?

Как побочный результат конечно профилирование по использованию HTTP Nowhere, который можно засечь так:
если выходной узел знает, что на неком сайте с https по-любому есть элементы, передающиеся открыто, "но вот у этого конкретного пользователя почему-то они не передаются, а стало быть блокируются", но зато выигрышь получается в том, чтобы выходной узел не мог определить по открыто переданой картинке X (или другому элементу) что пользователь посетил страницу Y целевого сайта, где эта картинка представлена например в качестве иллюстрации к тексту (статье).

Для избежания профилирования использовать свои плагины/расширения с TBB не рекомендуется. За HTTPS Everywhere стоит EFF и PGP-подпись, это достаточно доверяемое расширение, в отличие от HTTP Nowhere. И оно встроено в TBB. На этом стоит успокоиться. IMHO. Лучше создайте список сайтов, которые вам важны, и не забывайте руками дописывать для них в строке адреса https://

Если отдача части контента идёт через посторонние домены безо всяких плагинов, то замок тоже биться не будет? Или всё же будет? На pgpru в своё время бился.

Сильный противник может профилировать и шифрованный трафик. С картинками это сравнительно просто: узел знает какой сайт посещён, выкачивает с него все миллиарды картинок и для каждой строит статистический профиль. Правда, при такой модели угрозы, Tor вообще бесполезен.

Если отдача части контента идёт через посторонние домены безо всяких плагинов, то замок тоже биться не будет?

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

Судя по вашему пояснению, вы хотели сказать не «Да», а «Нет, будет биться, потому что

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

Верно, прочитал "тоже биться будет?". Как верно отмечают психологи, частица "не" плохо воспринимается.

Оригинальный пост на тему.


Нет, не оно. Нагуглил всё-таки: это HTTPS Finder. Его критика здесь. Ещё есть какой-то Force TLS, который на pgpru ещё не обсуждался, поэтому ничего сказать не могу кроме всё тех же общих замечаний про профилирование.


В общем, да. Если что-то делается разово, это ещё не так страшно, но если вдруг вы начинаете это делать регулярно, оно становится шаблоном, и тут профилирование — медленная, но надёжная и гарантированная смерть для анонимности.


Описание последствий для тех, кто ещё не в курсе:

Пользователю шлётся предупреждение, что страница имеет частично незашифрованный контент и замок помечается, как битый. На практике это означает, что противник может как угодно менять пропорцию между шифрованным и нешифрованным трафиком, фактически делая из HTTPS разновидность dog sign security. На самом pgpru.com такая проблема тоже долго была, и для её решения приходилось убирать рекламные ссылки резчиками рекламы или фильтрующими HTTP-прокси.

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

Новость на эту тему: «Техника успешного внедрения в SSL соединение».


Это известная проблема, когда, противоположные по смыслу (казалось бы) ответы имеют одинаковый смысл, поэтому требуется пояснение (что именно «да» или «нет»):
— Вы ещё не выкопали картошку?
— Да
Сравните с:
— Вы ещё не выкопали картошку?
— Нет
Когда-то здесь указание на эту тонкость уже приводилась в оффтопах.

"К примеру, на ютьюб можно заходить по HTTPS. Названия страниц, которые вы там смотрите, исходящему узлу не видны. Но все ролики с этих же страниц идут в открытом HTTP без S."

О как... Это точно? Просто я когда смотрю ролики там через Firefox с HTTPS Everywhere, у меня показывается в адресной строке замочек, то биш полностью шифрованое соединение. А что насчёт видеороликов и музыки ВК, если ВК по https работает?

тред не читай @ вопросы задавай

А что насчёт видеороликов и музыки ВК, если ВК по https работает?

Без понятия. Возьмите Wireshark и проверьте, что за трафик там ходит.