Проблема в сертификатах?
Первый и наиболее распространённый барьер к переходу на HTTPS это цена получения, настройки и поддержки валидного сертификата. Вы должны найти поставщика сертификатов, подтвердить свою личность, заплатить за него и настроить сервер, а также своевременно продлевать.
Большинство предложений перехода на повсеместное шифрование звучат примерно так: «NSA записывает весь наш трафик, почему бы не шифровать его?». Целью подобных предложений является повышение стоимости пассивного слежения за всем трафиком, а не более сложные и целевые атаки, которые применяются злоумышленниками.
Ребята из Let's Encrypt уже догадались, что проблема с сертификатами почти полностью поддаётся автоматизации, и что её реализация для выпуска, установки, конфигурации и продления на нескольких наиболее распространённых платформах может покрыть подавляющее большинство Интернета. Замечательная работа, и, хоть и осталось сделать многое, я думаю, что мы можем считать проблему сертификатов решённой.
Теперь у нас есть сертификат, мы можем включить HTTPS, правильно?
Ну, может быть. Но возможно и нет. Если все HTML ресурсы, которые вы предоставляете, имеют ссылки (картинки, скрипты…) на тот же хост и вы используете только относительные URL, то всё отлично. В противном случае скорее всего HTTPS не будет работать правильно.
Что? HTTPS — это же хорошо, почему всё сломалось?
Всё сломалось потому что почти наверняка у вас на странице есть смешанный контент.
Что такое смешанный контент и почему он должен меня волновать?
Рассмотрим следующий случай, когда вы — оператор «OriginA». Зелёные круги означают ресурсы, доступные по http и https? красные — только по http. Пунктирные линии это подгрузка контента через http. Обычные линии — https. Допустим, что все ссылки абсолютные. Красный крест означает, что загрузка завершится ошибкой.
Теперь допустим, что вы настроили сертификат и включили https на OriginA. Как теперь будет выглядеть диаграмма?
Если вы не обновите абсолютные ссылки в HTML, браузер всё равно будет пытаться получить ресурсы по http. Большинство запрещают такие загрузки и показывают предупреждения в таких случаях, и со временем становятся только строже.
Почему браузеры блокируют смешанный контент? Почему я не могу повлиять на это как владелец сайта?
В большинстве моделей Web безопасности(web security model) Источники ответственны за собственную информацию. Контент, загруженный через HTTPS может перенаправить пользователя на небезопасный сайт, может отправить POST запрос или postMessage() на небезопасный источник, и https сайт может получить GET, POST или onMessage() от документов, загруженных через http. При всём этом, почему разрешён POST, но запрещён XHR?
Есть формальное правило безопасности, которые браузеры пытаются применять к сайтам. Впервые это правило было сформулировано как «Tranquility». Простыми словами это означает, что безопасный документ не станет небезопасным во время взаимодействия.
Из всех сложностей и ловушек Web безопасности, браузеры пришли к выводу, что есть только один более-менее надёжный и полезный индикатор безопасности: адресная строка и замочек, означающий использование HTTPS. Если вы печатаете «https://» в адресной строке или видите иконку замка документа с которым взаимодействуете, браузер обещает вам, что контент защищён от угроз извне.
Если бы https сайт загрузил скрипт или картинку через http, это обещание было бы нарушено. Конкретные последствия такого действия могут сильно разниться, но браузер не в праве разбираться с этим, так что он просто пресекает подобное поведение. Это сделано не только для защиты пользователей, которые не могут сами разобраться, например открывая в браузере почтовый клиент, запрашивающий скрипт через http, в кофейне, но и как индикатор для авторов контента, которые могли что-то упустить.
Это хорошее решение для пользователей, но оно доставляет операторам сайтов некоторые сложности при переводе сайтов на https. Все их HTML ресурсы, ссылающиеся на небезопасный контент, ломаются или пугают пользователей предупреждениями. Эта проблема с зависимостями, я полагаю, настоящее препятствие, которое нужно преодолеть для перевода 100% ресурсов на HTTPS.
Чиним смешанный контент
Если вам необходимо исправлять проблему со смешанным контентом, то стоимость перехода на https несколько повышается. Это чуть сложнее, чем конфигурация сервера или получение сертификата, удаление смешанного контента затратно и не всегда поддаётся автоматизации.
Для сложного сайта нельзя просто запустить s/http/https/g на всех страницах, или написать правило в mod_rewrite. Вы можете столкнуться с http ресурсами во многих местах: статический контент, динамический, клиентский, хранящийся в БД, получение данных со сторонних ресурсов, и так далее.
Новые спецификации, находящиеся в разработке, нацелены на облегчение этого процесса; они помогают автоматически заменять http ресурсы на https.
До:
После:
Upgrade-Insecure-Resources помогли с доступом OriginA в данном примере. Один из HTML ресурсов теперь не содержит смешанного контента потому, что протоколы были незаметно подменены и удалённые зависимости стали доступны через https. Этот пример показывает почему множество сайтов неохотно предоставляют собственный контент через https, во избежание пугающих сообщений об ошибках и дефектов функциональности.
Это ведёт к печальному обстоятельству, что наименее ответственные участники на конце цепочки зависимостей могут тормозить прогресс. Циклические зависимости(так как они точно существуют в огромной структуре веба) могут создавать взаимные блокировки, которые не разрешить без координации действий.
Ни один из этих сайтов не может включить https
Устранение циклических зависимостей
Не хватает промежуточного состояния между http и https. Было бы идеально, если бы данное состояние имело следующие свойства:
1. Разрешало бы безопасным источникам, которые зависят от ваших ресурсов, получать их не нарушая принцип tranquility.
2. Не заставляло бы другие ресурсы делать поспешные выводы о безопасности или отсутствии смешанного контента.
3. Было бы крайне дешёвым и не создающим никаких рисков для внедрения. Идеально — добавление http заголовка.
4. Позволяло бы определять зависимости, нарушающие принцип tranquility или создающие ошибки смешанного контента.
OriginB переходит в режим «https-transitional». Это означает, что ресурс всё ещё не доступен по https://, но будет в будущем доступен через TLS с полными гарантиями, включая валидный сертификат. Это не должно ничего стоить OriginB, так как браузеру и пользователям ничего не известно про состояние безопасности этого ресурса.
Теперь ресурсы OriginB доступны через «https-transitional». OriginA включает HTTPS. Браузер знает, что он может инициировать TLS соединение к OriginB и запросить ресурсы через традиционный http протокол. Если эта смена протокола не удастся, ресурс будет помечен как небезопасный и появится предупреждение о смешанном контенте. Если всё закончится успешно, все гарантии о безопасности OriginA заявляемые браузером будут истинны, не появятся предупреждения о смешанном контенте, несмотря на то, что файл был передан через http.
После обновления OriginA OriginC также может обновиться. OriginB всё ещё зависим от OriginD, так что он ещё не может перейти на https, но включая «транзитный» режим он разрешает ресурсам A и B доступ к ресурсам через https.
Как мы можем создать это состояние?
Для разрешения циклической зависимости без создания документов со смешанным контентом нужно настроить фильтр, который возвращал бы 404 на все запросы, кроме тех, на которые можно вернуть Content-Type text/html. Довольно хорошее решение, исключая некоторые случаи, связанные с CORS. Из четырёх свойств нужных нам этот подход реализует три.
Четвёртое свойство — возможность определить состояния своих зависимостей чтобы знать момент, когда можно включить полноценный HTTPS. Что если бы браузеры могли применять Content-Security-Policy-Report-Only с «upgrade-insecure-requests» для http документов?
- Пробуем подменить протокол
- В случае неудачи: Откат на http, сообщение администратору
Возможно, что не понадобится делать ничего, кроме вышеуказанных шагов. Эта конфигурация, с «upgrade-insecure-requests», реализованная для A, B и C:
iframe
К сожалению простого перехода к отдаче html ресурсов через https недостаточно, это не работает с зависимостями HTML к HTML через iframe. Это довольно часто используется.
Нужно реализовать возможность загрузки HTML ресурса подменяя протокол на TLS, но только на безопасной странице. Это не нарушит безопасность потому, что без подмены протокола контент уже был бы небезопасным, так что мы не создаём смешанный контент для пользователей OriginB.
https-transitional при помощи ALPN и HTTP Alt-Svc
ALPN позволяет клиенту общаться с сервером через TLS указывая другой протокол, который клиент хотел бы использовать.
Давайте представим новый тип ALPN протокола: «https-transitional». Сервер, у которого клиент запрашивает данные таким образом понимает это как: «соедини меня с сервером через http, но через TLS, не через https». Как и описано в черновике HTTP Alt-Svc, должно произойти TLS соединение, сервер должен представить сертификат, подходящий к домену.
Ресурс, открытый через «https-transitional», будет иметь следующие свойства:
- Ресурс не должен быть заблокирован как смешанный контент.
- Настройки документа, переданного через «https-transitional», не должны запрещать смешанный контент.
- Предыдущие свойства выполняются до тех пор, пока родительский фрейм документа не запрещает; в таком случае автоматически должен произойти upgrade-insecure-requests
Upgrade-Insecure-Requests будет модифицирован следующим образом:
- В случае подмены протокола для зависимого ресурса подключаемся к https, добавляем новый «https-transitional» ALPN протокол как предпочтительный, в добавок к http/spdy/h2.
- Если сервер понимает «https-transitional», ответить по этому протоколу и доставить http ресурс через TLS.
- Если сервер не понимает «https-transitional» — ответить по https.
Блокировка смешанного контента также должна быть модифицирована. Браузеры в данный момент не пытаются автоматически заменить http на https, так как нет гарантии, что обе схемы предоставляют одинаковый контент. Схема с «https-transitional» такую гарантию предоставляет. Сервет также может сообщать о доступности транзитного режима с помощью HTTP Alt-Svc заголовка.
После загрузки документа в транзитном режиме браузер должен попытаться заменить все соединения, заблокированные как смешанный контент, как если бы upgrade-insecure-requests был включен, но также должен незаметно загрузить контент через https если предыдущая попытка закончится неудачно. Он также должен вывести ошибку в консоль.
Диаграмма выше демонстрирует реализацию вышеописанных правил. Ресурсы, загруженные с OriginA, iframe которого указывает на OriginB никогда не будут содержать смешанного контента, так как OriginB поддерживает транзитный режим. Однако если ресурсы OriginB загружаются из документа, который блокирует смешанный контент и зависят от ресурсов, для которых замена протокола невозможна(например JS файл на OriginD), то такие запросы будут тихо заблокированы. Частичная поломка предпочтительнее полной. Ресурсы, загруженный напрямую от OriginB, которые зависят от тех же на OriginD не будут заблокированы, так как не требуется соблюдение принципа tranquility.
Влияние на производительность
Для https ресурсов данное предложение не должно создать никаких новых задержек по сравнению с использованием Upgrade-Insecure-Requests. Браузеры будут предпочитать TLS, так что не потребуется новых запросов для определения поддержки https-transitional.
Единственное место, которое может потерять в производительности, это замена соединения из-за Alt-Svc заголовка. Браузер будет пытаться рекурсивно обновить все зависимые ресурсы, некоторые из которых могут быть недоступны через https, что может создать большие задержки. Также они могут это исправить помня, что TLS был недоступен для определённого источника определённое количество времени, либо же распараллелить запросы. Возможно, нужны некоторые эксперименты для определения лучшей стратегии.
В какой-то момент все сайты захотят уйти от http. Загрузка через https никогда не откатывается до http, но вышепредложенного сценария недостаточно для защиты от хакеров, использующих атаки для снятия шифрования. Как мы можем перейти от транзитного веба к полностью безопасному, особенно если существование первого означает избегание необходимости изменения схемы запроса для каждой ссылки на сайте?
Мы можем начать разрабатывать паттерны основываясь на HTTP Strict Transport Security, который был создан для решения проблем сайтов, желающих полностью отказаться от http и Alt-Svc заголовка.
Первое, что администратор может сделать — установить Alt-Svc в infinite, что будет сигналом для браузеров не пытаться подключиться по http, использовать только https-transitional и https, всегда. После этого сайт может оставить поддержку http для устаревших клиентов, или совсем её отключить.
Следующим шагом будет применение принципа tranquility для транзитного контента. Возможно, лучший способ сделать это — HTTP заголовок. Установка бита «tranquil» будет означать запрет смешанного контента. Это возможно также позволит данному ресурсу получить иконку замка, или вызвать подобные изменения в интерфейсе.
Однажды, если распространение транзитного режима будет достаточным, браузеры смогут начать отказ от http. Возможно началом будет появление пункта в настройках, затем показ большого предупреждения. Множество сайтов скорее всего останутся в транзитном режиме на неограниченное время, но пользователи всё же будут получать преимущества от использования сайтом TLS.
Комментарии (90)
vsb
20.01.2016 01:02+14Проблемы с HTTPS:
1. HTTPS не нужен ни пользователям, ни владельцам большинства сайтов. Удобств пользователям он не приносит, каких-то насущных проблем владельцев сайтов он не решает. Скоро этот фактор исчезнет, когда браузеры начнут перечёркивать не-HTTPS адреса. Возможно ещё внедрение HTTP/2 станет тем самым фактором, который захотят пользователи и владельцы, но не факт.
2. Проблемы с рекламными сетями. Есть рекламные сети, которые не работают по HTTPS. Переводить сайт на HTTPS значит терять деньги с рекламы. Скоро этот фактор исчезнет, т.к. все значимые рекламщики уже мигрируют на HTTPS.
3. CDN-провайдеры берут больше за HTTPS. Причём некоторые в разы (а те, что не в разы и за HTTP берут в разы больше конкурентов).
4. Требует отдельного IPv4 адреса. Можно использовать SNI, но с ним другие проблемы — браузеры его худо-бедно поддерживают (хотя достаточно большой процент пользователей отсечётся), а вот всякие Java, Python-ы и прочие — только последних версий. Многие внутренние инструменты сломаются.
ArjLover
20.01.2016 05:21А кто берет дороже? Cloudflare, например, только пропагандирует переход на http/2. Кстати он же трафик не считает, а считает коннекты — тут выигрыш прям многократный получается.
FeelGood
20.01.2016 08:31+8HTTPS не нужен ни пользователям, ни владельцам большинства сайтов.
Все зависит от сайта. Если у вас магазин, то как показала практика, многие откажутся от покупки на сайте без https.
psman
20.01.2016 14:40+1Чего отказываться если платежные данные вводятся на страницы банка уже где https EV?
istui
20.01.2016 14:48+1много где есть магазины без онлайн-оплаты, но требующие личные данные (телефон, мыло и т.д.). Их защита не столь критична, но тоже желательна.
psman
20.01.2016 15:10-1Телефоны — не стоит беспокоиться о том что из стырят. Какой нить TrueCallerId делает это добровольно и массово (в цианогене он предустановлен местами). Отправка смс на несуществующий номер закачивается ошибкой и оплата не взнимается. Всяческие системы подтверждения телефона — уже копят данные и обмениваются ими.
Система работает как часы и спалить через инет свой телефон — все равно что бояться заболеть гриппом при переливании крови от непроверенных доноров. Или бояться съесть что то не то в обеде в самолете авиакомпании «АлькаидаЭйрБабах».istui
22.01.2016 15:03Почта еще есть, домашний адрес при заказе пиццы/суш, дата рождения и т.д. Даже промокод — и тот могут украсть.
К сожалению, много кто из знакомых сидит «через бесплатный вайфай от соседа». В университетах, кафешках, библиотеках часто публичный вайфай без пароля => при желании можно много узнать о человеке, сделав MITM (не говоря уже о возможности навредить).
Друг таким нестандартным способом узнавал телефоны девушек во время учебы :)
grossws
20.01.2016 11:19вот всякие Java
jdk6, как бы EOL ещё начале 2013 года, а jdk7 (который тоже EOL с апреля 2015) уже поддерживает sni.
musuk
20.01.2016 14:16+11. HTTPS не нужен ни пользователям, ни владельцам большинства сайтов.
Конечно, пусть провайдеры и прочие Mans in the middle снифают пароли и токены пользователей.
Regis
20.01.2016 16:07-2Есть огромное количество сайтов, где нет ни паролей, ни логинов.
Простейший пример — сайт-визитка. С контактными данными. Зачем ему HTTPS?musuk
20.01.2016 17:53+6Чтобы хостер или другой MITM подсовывал свой код в HTML сайта. Собственно, атаки с подменой скриптов google analytics уже были.
Суть HTTPS в том, что если заходишь на сайт Васи Пупкина с мобилы в кафе, ты был уверен, что тебе не прилетит контент с заражённой WiFi-точки.Regis
20.01.2016 23:34-1Может быть это проблема всё же последней мили (провайдер и проч), не?
musuk
20.01.2016 23:59+3Ну мало ли на какой миле сидит Mitm, задача https бороться с атаками mitm. В реальности проблемы провайдера часто являются проблемой пользователя. Скажите спасибо, что у нас ещё подмена сертификата провайдерами относительная редкость.
Если ваш сайт поддерживает https, то это значит, что вы защищаете своих пользователей. В принципе, я считаю, что хорошо если все сайты будут поддерживать https. Но пока это относительно дорого и сложно.Regis
21.01.2016 00:33+1Есть две немного разных задачи:
1) Гарантировать, что от сервера к киленту придет ровоно то, что отправил сервер (и наоборот)
2) То же что в 1, но еще гарантировать, что никто (в том числе провайдер) не сможет узнать, что было внутри переданных данных
HTTPS обеспечивает 2. Но часто было бы достаточно 1 (просто подпись контента).
ZoomLS
20.01.2016 18:36Для HTTP/2.
faiwer
20.01.2016 18:58По вашему HTTPS/2 будет быстрее HTTP? Или вы именно про HTTP/2 (без TLS)? Вроде бы браузеры его не поддерживают.
BupycNet
20.01.2016 19:39-1В том то и суть. HTTP/2 требует TLS. Но при этом HTTP/2 с TLS быстрее чем HTTP
faiwer
20.01.2016 20:05+2Но при этом HTTP/2 с TLS быстрее чем HTTP
Хм. А вы в этом уверены? Вам попадалась такая статистика/исследования? Вопрос в общем то интересный, но я пока натыкался скорее на отзывы об обратном. Более того HTTP/2 без TLS (что должно быть куда быстрее чем HTTP/2 с TLS) попросту не поддерживается браузерами.BupycNet
20.01.2016 20:36«Более того HTTP/2 без TLS (что должно быть куда быстрее чем HTTP/2 с TLS) попросту не поддерживается браузерами.»
Он вроде как в стандарте и не описан, разве нет?
Я сам перешел на HTTP/2 и заметил, что если файлов очень много (например polymer использует include на html, библиотеки различные — файлов штук 100 например ресурсов, для крупных сайтов вообще нормальная практика) то конечно загружать 100 файлов одновременно быстрее, чем по очереди по несколько штук.faiwer
21.01.2016 06:59Он вроде как в стандарте и не описан, разве нет?
Несмотря на стандарт, разработчики браузеров упёрлись рогом и ни в какую. Мол не секурно, так нельзя, бла-бла-бла.
ZoomLS
21.01.2016 01:18Где-то быстрее, где-то может чуть медленнее. Вообще, быстрее, т.к. обычно файлов и запросов очень много стало на большинстве сайтов. И вообще, я имел виду другое. Новая версия протокола, какой смысл сидеть на старой?
faiwer
21.01.2016 21:15Где-то быстрее, где-то может чуть медленнее. Вообще, быстрее
Не, «ну я так не играю». Ориентироваться на «где-то», «вообще» и пр. несерьёзно. Я сам пока в эту сторону особо не копал, но похоже в HTTP и без того особых проблем с большим кол-вом запросов не было, так что HTTP/2 c TLS штука под вопросом. Судя по риторике ребят, её внедряющих, преимуществ для http:// не видно.
И вообще, я имел виду другое. Новая версия протокола, какой смысл сидеть на старой?
Эх, если бы производители браузеров согласились бы на HTTP/2 без TLS, я был бы с вами согласен. Но похоже тут только Edge взялся реализовывать.grossws
22.01.2016 01:29Я сам пока в эту сторону особо не копал, но похоже в HTTP и без того особых проблем с большим кол-вом запросов не было, так что HTTP/2 c TLS штука под вопросом.
Там проблемы обычно не с большим количеством запросов на стороне сервера, а с тем, что браузер ограничивает количество запросов к одному хосту. Основные бонусы http2, которые обычно вспоминают — возможность уйти от head of line blocking, приоритеты стримов, мультиплексирование стримов через одно соединение, server push. В общем, упор на уменьшение времени ожидания пользователем и увеличение интерактивности веб-приложений.
grobitto
20.01.2016 03:09-3Lets Encrypt не работает в Windows XP, а это >5% в россии, что зачастую не позволяет использовать его в продакшне
aik
20.01.2016 07:24Думаете, что так много людей хостят сайты на ХР?
valera5505
20.01.2016 07:47+1Не хостят, а смотрят. На Windows XP сайты с Let's Encrypt работают только в Firefox.
aik
20.01.2016 08:06А что, с их сертификатами еще пользователь должен какой-то клиент/аддон к браузеру ставить?
valera5505
20.01.2016 08:30Нет, просто сертификаты слишком новые :)
Fedcomp
20.01.2016 09:20+2а разве у них не кросс-подписка с каким то сертификатом другого вендора для совместимости?
wrewolf
20.01.2016 10:15+3к кросс подписи отношения не имеет.
тут длинна отпечатка/ключа большая слишком для XPgrobitto
25.01.2016 03:05не совсем так
рут их сертификата по лицензии требует ограничить доменные имена не .mil доменами, а такая запись в сертификате портит его не а ХР
разбираются пока, но перспективы туманны. а счастье было так близко
Biggo
20.01.2016 08:00+1Да, на своем опыте убедился в этом, когда в публиной бете let's encrypt попробовал сертификат на рабочий сайт поставить. Суппорт стал сообщать о странных проблемах. Пришлось поставить платный сертификат. К сожалению, это не дает пользовать let's encrypt вообще на данный момент.
ZoomLS
20.01.2016 03:47С приходом HTTP/2 и Let's Encrypt, https уже стал стандартом. Вопрос в другом, почему до сих пор повсеместно не используется HTTP/2? Ожидаемо, в этом году, будет массовый переход на HTTP/2.
ArjLover
20.01.2016 05:20+2HTTP/2 все еще в dev ветке у nginx, а больше его особо запустить не на чем.
Да и пользы-то от него… Все кто хотел мультиплексирования запросов — много лет назад поставили себе SPDY и получили главный профит. В чем там еще разница? Я честно говоря даже не в курсе.
Опять же, кто действительно беспокоился о скорости загрузки давно оптимизировали код и страница состоит из 5 элементов — включать на них http/2 даже вредно — будет тормознее.
el777
20.01.2016 14:39Причем есть мнение, что в nginx мультиплексирование для SPDY реализовано лучше, чем для HTTP/2.
Поэтому еще вопрос, что надо ли сейчас апгрейдиться до HTTP/2 — несмотря на более развитый протокол, можно проиграть в скорости.
achekalin
20.01.2016 08:04+31. Только очень странные люди внутри сайта делают ссылки на локальные ресурсы, включающие и схему, хост (т.е. — полные URL-ы). Все остальные разумно пишут абсолютные URI (т.е. ссылки, начинающие от корня собственного веб-сайта), и никаких проблем с этим при переходе на https не испытают. Для совсем тяжелых случаев и HTTP Strict Transport Security поможет, если что.
2. Однако ссылки на внешние ресурсы не всегда «вылечишь» простым убиранием схемы («http://...» -> "//..."), потому что на разных сайтах URL по http и по https бывают разными, да еще алгоритмически, через js, собираемыми — рекламные сети и счетчики как пример.
3. Но вопрос в том, что прикрутить https не всем легко. Во-первых, shared хостинги просто не предлагают такой услуги бесплатно. Предлагают за деньги, и сертификаты часто устанавливают руками. Серверных скриптов, дружащих с let's encrypt, и делающих все автоматом, у них особо не видно — не нужно оно им.
4. Переход для старых, развитых сайтов, на https, не так чтобы прост с точки зрения тестирования и сохранения аудитории. Вроде как легко включить поддержку, а ну как где-то на сайте что-то поломается (сайт — старый, напомню), и юзеры начнут быть недовольны, а как следствие — побегут с ресурса? Тестирование, а оно долгое и порой сложное.
Напоследок взять Хабр как пример: вроде и руки, и головы в редакции есть. А рисковать как-то никто не хочет, ибо единственная цель, которую можно озвучить громко — SEO — у ТМ-ресурсов и так неплохо достигается без https. Ждем перечеркивания http в браузерах? :)
Aingis
20.01.2016 13:52Напоследок взять Хабр как пример: вроде и руки, и головы в редакции есть.
А Хабру не всё равно, что на всяких бесплатных вай-фаях, по типу того, что в Метро, на сайте показывается совсем левая реклама? Загораживая родную.achekalin
20.01.2016 14:04+3Мне кажется, Хабру не только на это «несколько неважно». Собственно, Хабр — это уже давно не такая, как было когда-то, узкая компания ИТ-ников, сами и для себя творящая контент на сайте. Это бизнес-предприятие, которое, вспомните, продавали-то за совсем недетские деньги. Так что цель «сделать вами хорошо», конечно, есть, но, как и с «мобильной» версткой, в которой невозможно масштабировать контент на экране телефона (тоже вопрос удобства), как и с загружаемыми шрифтами (которые на текстовом ресурсе мало нужны), как с работой «редакторов», которые контент компилируют из «открытых источников», а вовсе не производят новый (по сути, превращая Хабр в сборник краткого изложения статей на других ИТ-ресурсах), как и с блогами компаний, на контент в которых не ругался наверное только ленивый — это все идет по логике «есть ли от изменения существенная прибыль?»
А теперь подумайте: есть ли компании смысл рисковать, вводя https, если непонятно, какой в нем смысл в смысле выгоды? Перечеркнутый http в адресной строке браузера, скорее всего, будет посерьезнее проблем в метро — это уже удар по репутации, т.е. минус в доход.
Правда, когда массовове движение в сторону https (вдруг) начнется, вы уверены, что в метро вас не попросят принять самопальные сертификаты на зоны *.*. и *.*.*. (грубо говоря), выпущенные MSKMetroCA, без которых ничего работать не будет, и не возьмутся вписывать рекламу уже в код https-ных страниц? :)
kstep
20.01.2016 15:41+1Вопрос масштабирования на мобилке я давно решил, включив опцию «Принудительно изменять масштаб» в спецвозможностях хрома:
musuk
20.01.2016 14:21+3Хабр и другие российские сайты, того, что роскомнадзор забанит их домен целиком, а только не страницу с «недопустимым» контентом.
Думаю, что в российском сегменте страх перед роскомнадзором выше, чем забота о безопасности и приватности пользователей.
el777
20.01.2016 14:441. Только очень странные люди внутри сайта делают ссылки на локальные ресурсы, включающие и схему, хост (т.е. — полные URL-ы). Все остальные разумно пишут абсолютные URI (т.е. ссылки, начинающие от корня собственного веб-сайта), и никаких проблем с этим при переходе на https не испытают. Для совсем тяжелых случаев и HTTP Strict Transport Security поможет, если что.
Например, у если у вас раздача статических ресурсов идет с отдельных доменов, то вам придется писать домен.
Конечно, можно выкрутиться решением "//cdn.example.com/1.jpg" — чтобы браузер сам запрашивал по нужному протоколу. Либо же вообще перевести всю статику на https, но потерять во времени загрузки.achekalin
20.01.2016 15:12Во-первых, именно что "//cdn.domain.com/...", а не http или https — оно безопаснее в дальнейшем, мало ли что придется делать. Во-вторых, nginx умеет заменять текстовые строки в контенте, так что заменить вполне можно и при отдаче (если нет желания весь сайт перелопачивать).
http/2 должен помочь с раздачей статики с того же хоста — после того, как соединение установлено, контент летит более чем шустро. А если статики много, или у вас на сайте много поддоменов, а статика отдается для всех с одного — иметь выделенный домен для статики вполне вариант, работает более чем быстро.
Ну и конечно, поднять и попробовать, а потом сравнить впечатления никто не мешает. Обидно, что онлайновые тулзы для тестирования скорости загрузки сайтов часто не умеют пользоваться http/2, так что не всегда и узнаешь, есть ли от него выгода.el777
20.01.2016 16:53> Во-первых, именно что "//cdn.domain.com/...", а не http или https — оно безопаснее в дальнейшем, мало ли что придется делать.
Ну я видел серьезный премиальный магазин у которого сайт на https, а картинки раздаются по http c 7 поддоменов. То есть безопасность такая…
> Во-вторых, nginx умеет заменять текстовые строки в контенте, так что заменить вполне можно и при отдаче (если нет желания весь сайт перелопачивать).
Очень большая вероятность, что что-то поломается.
Yahweh
20.01.2016 19:51+3А разве хабр не работает по https?
Заголовок спойлера
GamePad64
20.01.2016 21:40+6Похоже, они его только сегодня включили. Ждём статьи от ТМ.
achekalin
21.01.2016 02:19Лучше поздно. Но принудительного редиректа на https-версию нет, видимо, работы еще в процессе (либо приостановлены).
Кстати, по поводу коммента musuk по поводу того, что Хабр не включает режим «только https», т.к. не хочет попасть в бан весь, целиком: уверен, что нехороший контент, будя такому появиться на страницах сайта, будет вычищен при первой же жалобе «куда положено» со стороны «нашего всего» — никого не спросят, тупо выпилят. Даже без попыток спора обойдется, если таковое действие не принесет ни пиара, ни выгоды, а потенциально принесет блокировку. В общем, для Хабра https — всего лишь одна из бизнес-возможностей (и бизнес-проблем, если что не так пойдет), это мы с вами понимаем хорошо.
esc
20.01.2016 10:43+1https увы ОЧЕНЬ сильно повышает требования к процессору при раздаче тяжелого контента. Отдача видео, например, на 30 Гбитах полностью укладывает 2*2687w, при том, что в обычных условиях эти процессоры держат 80.
А без видео по https ругань на смешанный контент и все такое.istui
20.01.2016 14:53выход OpenSSL новой версии со встроенной поддержкой POLY1305/CHACHA20 сможет снизить нагрузку на процессор?
esc
20.01.2016 15:03Не знаю, но сомневаюсь. Все равно шифровать надо порядка 10Гбайт данных в секунду. Возможно, помогла бы специальная шифрующая карта, но это уже сильно усложняет дело.
Проще на https забить. Я пока не очень понимаю, зачем это может быть нужно на развлекательном сайте. Ради 0.001% юзеров, которым злой провайдер может подменить контент — точно не стоит. От Роскомнадзора тоже вроде как не помогает (блокируют по ip, что еще хуже).kstep
20.01.2016 15:45Для развлекательного контента может и HTTP ок, не спорю. Но вот когда доходит до оплаты, я лично стремаюсь вводить номер кредитки на криво сделанном сайте без нормально настроенного HTTPS (не будем тыкать пальцем).
esc
20.01.2016 15:47+1Думаю, достаточно сделать раздел оплаты на https. Трафик (сетевой) там не большой, а профита много. А какой профит от повсемесного https — неясно.
kstep
20.01.2016 15:52Ну так у них форма оплаты какая-то стрёмная, без HTTPS. Может, конечно, скрипт/ифрейм и по https у них грузится, но в итоге браузер ругается на некошерный смешанный контент. Лично мне стрёмно на такой странице вводить личные платёжные данные: хз какой там скрипт MitM подменит? А попытка насильно загрузить их сайт по HTTPS ручной заменой схемы в адресной строке приводит к полной не функциональности сайта, поскольку куча скриптов и стилей грузятся по абсолютным ссылкам с HTTP. Я зарёкся у них что-то покупать, пока не сделают нормальное шифрование. Не доверяю я таким конторкам. Ещё мне встречался сайт бронирования авиабилетов, который требовал полных паспортных данных и работал только по HTTP. Хотелось материться, просто.
esc
20.01.2016 15:55Я еще раз говорю — для разделов оплаты — да, это актуально. На всех страницах зачем?
kstep
20.01.2016 16:00Так я про эти разделы и говорю. Вы внимательно читали? Лично мне стрёмно на такой странице [HTTP] вводить личные платёжные данные. Ну и формы для ввода личных данных (паспортных) данных тоже к этому относятся.
esc
20.01.2016 16:02-1Ну а я говорю в контексте заголовка статьи. Везде-везде https не используется потому, что это ведет к дополнительным затратам и сложностям, а профит от внедрения прям везде-везде совсем не очевиден.
kstep
20.01.2016 15:55А профит в том, что когда шифруется только критичные данные, это привлекает внимание: «что-то у них всё открыто, а вот тут и тут шифруются, значит там что-то интересное, можно ломать!» А вот если шифруется всё без разбора, то выбрать, где контент важный/чувствительный, а где просто развлекательный атакующему уже не так просто.
esc
20.01.2016 15:57ssl на сколько я знаю ломается одинаково, что для всего сайта, что для одного какого-то раздела.
kstep
20.01.2016 16:06Дело не в том, как ломается, понятно что ломается домен. Дело в том, что если все сайты будут по HTTPS, то отличить те, которые стоит ломать, от тех, которые ломать не интересно.
esc
20.01.2016 16:08В 90% случаев, если не 99, ломают подменой сертификатов. На уровне провайдеров или трояном (да что там трояном, антивирусы, адблокеры тоже часто ставят свои сертификаты в систему). Т.е. если сломают, то для всех сайтов сразу (для конкретного пользователя или группы)
kstep
20.01.2016 16:55Если подменят сертификат сайта по пути ко мне, у меня будет ругаться браузер на не доверенный сертификат. А чтобы не ругался, атакующим ещё нужно и как-то добавить свой корневой сертификат мне в браузер как доверенный, что не так просто.
esc
20.01.2016 17:17Ну окей, если захотят взломать не все, а какой-то конкретный раздел, действовать будут не так? В чем разница между взломом какого-то раздела или всего https у пользователя целиком?
el777
20.01.2016 17:00+1Есть одна вещь, которая не будет работать в таком случае — Strict-Transport-Security.
Вы не можете объявить ее на поддомен, не объявив на родительский домен.
Казалось бы мелочь, но…
Надо очень тщательно следить за куками, чтобы случайно не поставить куку на несекурный домен, откуда ее потом можно будет увести.Так же держать в голове, что потенциально пользователю могут подпихнуть куку, которую он потом отправит на https-поддомен.
Есть риск перехвата запроса не несекурный поддомен с редиректом на домен злоумышленников. Причем этот домен может быть очень похожим и использовать https — то есть пользователь может и не заметить.
Технически еще придется поднимать тот же поддомен на http, который будет только редиректить на https и больше ничего не делать — но это мелочи. Впрочем опять надо не начать сервить с этого домена реальные платежные данные.
merlin-vrn
21.01.2016 10:50+1Вы не можете объявить ее на поддомен, не объявив на родительский домен.
А как мы тогда объявляем HSTS на example.ru? Она объявлена на родительском домене ru., а для этого — на корневом .? Корневой вообще к HTTP не имеет никакого отношения, там невозможно ничего подобного объявить.
Или я не понял, о чём вы.el777
21.01.2016 16:39Я не очень четко выразился, имеется ввиду, что без объявления HSTS на example.com, объявление HSTS будет малополезной опцией.
Например, у вас есть example.com, где показывается видео, и есть account.example.com для управления своим счетом. покупками и пр.
Естественно, у вас на example.com есть ссылка на account.example.com (и на всякий вы объявили для этого поддомен HSTS, если вдруг пользователь пойдет туда без правильной ссылки).
Толку от этого 0, ссылку на example.com можно подменить, например, на account-example.com и пользователь по ней попадет в совсем другое место.
То есть если у вас не защищен предыдущий сайт, то защита следующего даст очень мало.merlin-vrn
21.01.2016 16:51+1Мы тут про фишинг говорим?
Это другое место отображается в адресной строке браузера? Оно отображается с замочком, а может быть — с зелёной строкой и надписью, кто там подтверждён EV? И эта надпись совпадает? Это что за удостоверяющий центр, который может подписать одно и то же название для двух разных cname, да ещё и EV влепить?
Если пользователь видит другое и тем не менее ломится как баран — ну, он и есть баран.el777
21.01.2016 17:04И про фишинг, и про mitm, и про отравление кеша DNS, да и вообще про обеспечение безопасности с помощью HSTS.
Суть в том, что уязвимости будут «транслироваться» в защищенный сайт и считать что HSTS для поддомена достаточно для его защиты и использования несекурного протокола.merlin-vrn
21.01.2016 17:17+1Вообще, DNSSEC с DANE было бы достаточно, чтобы послать все эти удостоверяющие центры в анналы истории.
Это была бы идеальная технология domain validation — цепочка доверия начинается с dnssec корневой зоны ., который удостоверяет TLD, который удостоверяет наш домен, который удостоверяет TLSA-запись, в которой хеш публичного ключа из HTTPS-сертификата. Сам этот сертификат — да хоть самоподписанный.
А по дороге бонус — DNS вообще никак не отравишь, он же весь обвешан подписями. В худшем случае выдаёт отказ с сообщением «где-то по дороге завёлся жук и подписи не совпадают».
Но почему-то не спешат, внедряют всякую хрень, изобретают костыли вида letsencrypt.el777
22.01.2016 17:34Возможно, в какой-то момент к этому придут. Когда бизнес на сертификатах станет совсем не выгодным.
С другой стороны — получается, что будет зависеть от DNS-провайдеров, что тоже не очень хорошо. Серьезный сбой DNS, разделегирование и пр — и ничего не работает и не защищено.
Здесь есть хоть запасной вариант — прописать адреса руками и работать.merlin-vrn
26.01.2016 16:06А сейчас и так от них зависят. И запасной вариант «доверять этому сайту» тоже остаётся.
istui
22.01.2016 15:28+1К слову, на YouTube в Chrome отдача идет как раз через CHACHA20_POLY1305.
У Cloudflare в Universal SSL также используется по возможности данный шифр, как они писали в блоге, это сильно позволяет снизить нагрузку на процессор.
К сожалению, пока что дефолтные версии серверов/библиотек из репозиториев на большинстве систем не поддерживают эти шифры.
Понятно, что у YouTube на порядки больше серверов, чем у вас, и им проще перейти на SSL. Однако, уже в ближайшем времени трафик без шифрования планируется пометить небезопасным значком, поэтому лучше подготовиться заранее…esc
22.01.2016 15:31Если речь будет о троекратном росте процессорной мощности ради ssl, то проще будет объяснить пользователям что это за значек. CHACHA20_POLY1305 надо глянуть, что сомневаюсь что оверхед будет в допустимых пределах. Шифровать _видео_ трафик как по мне это чистой воды блаж Гугла.
konsoletyper
20.01.2016 10:53А как у https дела с кэширующими прокси? Я слышал, что без страшных хаков и костылей никак, да и не укладываются кэширующие прокси в философию https.
zxmd
20.01.2016 14:15-8Имхо, вся эта истерия с https наруку только «продаванам» доверенных сертификатов и гугол в данном случае на их стороне.
AndersonDunai
20.01.2016 21:56+2А у меня только что дата сбилась. В результате 99% сайтов перестали грузится, не давая зайти по https. Среди них и гугл, через который хотел найти решение проблеммы с ntpd.
Спас elinks.
Так-то.
franzose
21.01.2016 09:59+2А когда https станет (если станет) повсеместным, то нам скажут: им пользуются террористы и педофилы, надо запретить.
DIvan4ik
21.01.2016 12:12Раз уж тут делятся печальным опытом работы с HTTPS тоже добавлю.
В августе прошлого года купил COMODO SSL и поставил себе на домен. Спустя какое-то время сайт вылетел из выдачи Яндекса из-за… чувака который повесил DNS своего домена на меня. У меня видимо не было настроено поведение сервера в случае отсутствия хоста в nginx, хотя по идее должен отдаваться дефолтный/первый. C http точно было все ок.
Более того даже в Яндекс-Вебмастере я увидел над своими сайтами в виде главного зеркала чужой домен…merlin-vrn
21.01.2016 16:56Кажется, должно быть наоборот. По правильному имени вы видите нормальный валидный https, а по неправильному — даже если увидите сам сайт, по https он не будет валидным (т.к. неправильного имени нет в вашем сертификате). Или что-то я не понимаю?
DIvan4ik
21.01.2016 16:59Здравствуйте, Дмитрий!
Главное зеркало выбирается роботом с учетом пользовательских указаний, которыми могут являться 301 редирект, а также директива host в robots.txt всех зеркал, только в том случае, если они соответствуют одному и тому же адресу и не противоречат друг другу. В противном случае, как, например, в Вашем, робот может выбрать главное зеркало автоматически на основании собственного алгоритма, подробности работы которого мы не разглашаем.
С уважением, Платон Щукинmerlin-vrn
21.01.2016 17:01+2Ну бред же. Если сайт доступен по https, то это нормально — считать его основным. Shame on you, Yandex.
Blumfontein
26.01.2016 14:53+3Да у Яндекса вообще с зеркалами непонятная политика. Полгода назад у нас был 301 редирект с условного example.com на example.org. Затем мы переделали редирект в обратную сторону. Нормальные поисковики на букву G через некоторое время подхватили редирект и сменили все ссылки в выдаче на example.com. А Яндекс нас просто молча выкинул из выдачи вообще. Оказалось яндекс-бот, заходит на example.com, находит редирект на example.org, далее смотрит в свою БД и находит там редирект в обратную сторону, после чего у него наступает, видимо, когнитивный диссонанс. В результате оба домена в бане по причине «неглавное зеркало». Нам пришлось оба домена держать открытыми почти полгода, чтобы Яндекс наконец соизволил переклеить нам зеркала.
ghost404
23.01.2016 15:17У меня вопрос. Правильно ли я понимаю что при использовании HTTPS не будет работать HTTP кэширование? Это вполне ожидаемо в случае HTTPS, но вызывает дополнительную нагрузку на сервер и канал. Мало того что придется шифровать запрос/ответ, но еще и контент придется отдавать на каждый запрос. Всю статику придется тянуть каждый раз.
Получается мы повышаем безопастность сайта в ущерб производительности. По моему это не совсем правильно. Поправьте меня если я ошибаюсь.istui
23.01.2016 18:11Если в браузере включено кэширование, и сервером корректно установлены ETag, Cahe-Control, то кэширование будет работать.
Почитайте про мифы: blog.httpwatch.com/2011/01/28/top-7-myths-about-https
crackedmind
не вижу особой проблемы, не надо использовать абсолютные ссылки. Большинство сайтов, гугл и прочие, при встраивании скриптов делает либо http либо https, если у вас он есть. Для локальных ресурсов достаточно указать "//my_big_picture.jpg" вместо «myhost/my_big_picture.jpg»
Тут видимо проблемы от того что мало кто делал https у себя. Но до Let's Encrypt были другие поставщики бесплатных ssl решений.
ArjLover
Согласен, упоминание абсолютных ссылок в статье прям коробит. Все можно и нужно сделать на относительных с указанием хостов, но без указания схемы.
//example.com/test.jpg — валидная ссылка под обе схемы.