Comments 90
не вижу особой проблемы, не надо использовать абсолютные ссылки. Большинство сайтов, гугл и прочие, при встраивании скриптов делает либо http либо https, если у вас он есть. Для локальных ресурсов достаточно указать "//my_big_picture.jpg" вместо «myhost/my_big_picture.jpg»
Тут видимо проблемы от того что мало кто делал https у себя. Но до Let's Encrypt были другие поставщики бесплатных ssl решений.
Тут видимо проблемы от того что мало кто делал https у себя. Но до Let's Encrypt были другие поставщики бесплатных ssl решений.
UFO just landed and posted this here
А кто берет дороже? Cloudflare, например, только пропагандирует переход на http/2. Кстати он же трафик не считает, а считает коннекты — тут выигрыш прям многократный получается.
HTTPS не нужен ни пользователям, ни владельцам большинства сайтов.
Все зависит от сайта. Если у вас магазин, то как показала практика, многие откажутся от покупки на сайте без https.
Чего отказываться если платежные данные вводятся на страницы банка уже где https EV?
много где есть магазины без онлайн-оплаты, но требующие личные данные (телефон, мыло и т.д.). Их защита не столь критична, но тоже желательна.
Телефоны — не стоит беспокоиться о том что из стырят. Какой нить TrueCallerId делает это добровольно и массово (в цианогене он предустановлен местами). Отправка смс на несуществующий номер закачивается ошибкой и оплата не взнимается. Всяческие системы подтверждения телефона — уже копят данные и обмениваются ими.
Система работает как часы и спалить через инет свой телефон — все равно что бояться заболеть гриппом при переливании крови от непроверенных доноров. Или бояться съесть что то не то в обеде в самолете авиакомпании «АлькаидаЭйрБабах».
Система работает как часы и спалить через инет свой телефон — все равно что бояться заболеть гриппом при переливании крови от непроверенных доноров. Или бояться съесть что то не то в обеде в самолете авиакомпании «АлькаидаЭйрБабах».
Почта еще есть, домашний адрес при заказе пиццы/суш, дата рождения и т.д. Даже промокод — и тот могут украсть.
К сожалению, много кто из знакомых сидит «через бесплатный вайфай от соседа». В университетах, кафешках, библиотеках часто публичный вайфай без пароля => при желании можно много узнать о человеке, сделав MITM (не говоря уже о возможности навредить).
Друг таким нестандартным способом узнавал телефоны девушек во время учебы :)
К сожалению, много кто из знакомых сидит «через бесплатный вайфай от соседа». В университетах, кафешках, библиотеках часто публичный вайфай без пароля => при желании можно много узнать о человеке, сделав MITM (не говоря уже о возможности навредить).
Друг таким нестандартным способом узнавал телефоны девушек во время учебы :)
вот всякие Javajdk6, как бы EOL ещё начале 2013 года, а jdk7 (который тоже EOL с апреля 2015) уже поддерживает sni.
1. HTTPS не нужен ни пользователям, ни владельцам большинства сайтов.
Конечно, пусть провайдеры и прочие Mans in the middle снифают пароли и токены пользователей.
Есть огромное количество сайтов, где нет ни паролей, ни логинов.
Простейший пример — сайт-визитка. С контактными данными. Зачем ему HTTPS?
Простейший пример — сайт-визитка. С контактными данными. Зачем ему HTTPS?
Чтобы хостер или другой MITM подсовывал свой код в HTML сайта. Собственно, атаки с подменой скриптов google analytics уже были.
Суть HTTPS в том, что если заходишь на сайт Васи Пупкина с мобилы в кафе, ты был уверен, что тебе не прилетит контент с заражённой WiFi-точки.
Суть HTTPS в том, что если заходишь на сайт Васи Пупкина с мобилы в кафе, ты был уверен, что тебе не прилетит контент с заражённой WiFi-точки.
Может быть это проблема всё же последней мили (провайдер и проч), не?
Ну мало ли на какой миле сидит Mitm, задача https бороться с атаками mitm. В реальности проблемы провайдера часто являются проблемой пользователя. Скажите спасибо, что у нас ещё подмена сертификата провайдерами относительная редкость.
Если ваш сайт поддерживает https, то это значит, что вы защищаете своих пользователей. В принципе, я считаю, что хорошо если все сайты будут поддерживать https. Но пока это относительно дорого и сложно.
Если ваш сайт поддерживает https, то это значит, что вы защищаете своих пользователей. В принципе, я считаю, что хорошо если все сайты будут поддерживать https. Но пока это относительно дорого и сложно.
Есть две немного разных задачи:
1) Гарантировать, что от сервера к киленту придет ровоно то, что отправил сервер (и наоборот)
2) То же что в 1, но еще гарантировать, что никто (в том числе провайдер) не сможет узнать, что было внутри переданных данных
HTTPS обеспечивает 2. Но часто было бы достаточно 1 (просто подпись контента).
1) Гарантировать, что от сервера к киленту придет ровоно то, что отправил сервер (и наоборот)
2) То же что в 1, но еще гарантировать, что никто (в том числе провайдер) не сможет узнать, что было внутри переданных данных
HTTPS обеспечивает 2. Но часто было бы достаточно 1 (просто подпись контента).
Для HTTP/2.
По вашему HTTPS/2 будет быстрее HTTP? Или вы именно про HTTP/2 (без TLS)? Вроде бы браузеры его не поддерживают.
В том то и суть. HTTP/2 требует TLS. Но при этом HTTP/2 с TLS быстрее чем HTTP
Но при этом HTTP/2 с TLS быстрее чем HTTPХм. А вы в этом уверены? Вам попадалась такая статистика/исследования? Вопрос в общем то интересный, но я пока натыкался скорее на отзывы об обратном. Более того HTTP/2 без TLS (что должно быть куда быстрее чем HTTP/2 с TLS) попросту не поддерживается браузерами.
«Более того HTTP/2 без TLS (что должно быть куда быстрее чем HTTP/2 с TLS) попросту не поддерживается браузерами.»
Он вроде как в стандарте и не описан, разве нет?
Я сам перешел на HTTP/2 и заметил, что если файлов очень много (например polymer использует include на html, библиотеки различные — файлов штук 100 например ресурсов, для крупных сайтов вообще нормальная практика) то конечно загружать 100 файлов одновременно быстрее, чем по очереди по несколько штук.
Он вроде как в стандарте и не описан, разве нет?
Я сам перешел на HTTP/2 и заметил, что если файлов очень много (например polymer использует include на html, библиотеки различные — файлов штук 100 например ресурсов, для крупных сайтов вообще нормальная практика) то конечно загружать 100 файлов одновременно быстрее, чем по очереди по несколько штук.
Где-то быстрее, где-то может чуть медленнее. Вообще, быстрее, т.к. обычно файлов и запросов очень много стало на большинстве сайтов. И вообще, я имел виду другое. Новая версия протокола, какой смысл сидеть на старой?
Где-то быстрее, где-то может чуть медленнее. Вообще, быстрееНе, «ну я так не играю». Ориентироваться на «где-то», «вообще» и пр. несерьёзно. Я сам пока в эту сторону особо не копал, но похоже в HTTP и без того особых проблем с большим кол-вом запросов не было, так что HTTP/2 c TLS штука под вопросом. Судя по риторике ребят, её внедряющих, преимуществ для http:// не видно.
И вообще, я имел виду другое. Новая версия протокола, какой смысл сидеть на старой?Эх, если бы производители браузеров согласились бы на HTTP/2 без TLS, я был бы с вами согласен. Но похоже тут только Edge взялся реализовывать.
Я сам пока в эту сторону особо не копал, но похоже в HTTP и без того особых проблем с большим кол-вом запросов не было, так что HTTP/2 c TLS штука под вопросом.Там проблемы обычно не с большим количеством запросов на стороне сервера, а с тем, что браузер ограничивает количество запросов к одному хосту. Основные бонусы http2, которые обычно вспоминают — возможность уйти от head of line blocking, приоритеты стримов, мультиплексирование стримов через одно соединение, server push. В общем, упор на уменьшение времени ожидания пользователем и увеличение интерактивности веб-приложений.
Lets Encrypt не работает в Windows XP, а это >5% в россии, что зачастую не позволяет использовать его в продакшне
Думаете, что так много людей хостят сайты на ХР?
Не хостят, а смотрят. На Windows XP сайты с Let's Encrypt работают только в Firefox.
Да, на своем опыте убедился в этом, когда в публиной бете let's encrypt попробовал сертификат на рабочий сайт поставить. Суппорт стал сообщать о странных проблемах. Пришлось поставить платный сертификат. К сожалению, это не дает пользовать let's encrypt вообще на данный момент.
С приходом HTTP/2 и Let's Encrypt, https уже стал стандартом. Вопрос в другом, почему до сих пор повсеместно не используется HTTP/2? Ожидаемо, в этом году, будет массовый переход на HTTP/2.
HTTP/2 все еще в dev ветке у nginx, а больше его особо запустить не на чем.
Да и пользы-то от него… Все кто хотел мультиплексирования запросов — много лет назад поставили себе SPDY и получили главный профит. В чем там еще разница? Я честно говоря даже не в курсе.
Опять же, кто действительно беспокоился о скорости загрузки давно оптимизировали код и страница состоит из 5 элементов — включать на них http/2 даже вредно — будет тормознее.
Да и пользы-то от него… Все кто хотел мультиплексирования запросов — много лет назад поставили себе SPDY и получили главный профит. В чем там еще разница? Я честно говоря даже не в курсе.
Опять же, кто действительно беспокоился о скорости загрузки давно оптимизировали код и страница состоит из 5 элементов — включать на них http/2 даже вредно — будет тормознее.
1. Только очень странные люди внутри сайта делают ссылки на локальные ресурсы, включающие и схему, хост (т.е. — полные URL-ы). Все остальные разумно пишут абсолютные URI (т.е. ссылки, начинающие от корня собственного веб-сайта), и никаких проблем с этим при переходе на https не испытают. Для совсем тяжелых случаев и HTTP Strict Transport Security поможет, если что.
2. Однако ссылки на внешние ресурсы не всегда «вылечишь» простым убиранием схемы («http://...» -> "//..."), потому что на разных сайтах URL по http и по https бывают разными, да еще алгоритмически, через js, собираемыми — рекламные сети и счетчики как пример.
3. Но вопрос в том, что прикрутить https не всем легко. Во-первых, shared хостинги просто не предлагают такой услуги бесплатно. Предлагают за деньги, и сертификаты часто устанавливают руками. Серверных скриптов, дружащих с let's encrypt, и делающих все автоматом, у них особо не видно — не нужно оно им.
4. Переход для старых, развитых сайтов, на https, не так чтобы прост с точки зрения тестирования и сохранения аудитории. Вроде как легко включить поддержку, а ну как где-то на сайте что-то поломается (сайт — старый, напомню), и юзеры начнут быть недовольны, а как следствие — побегут с ресурса? Тестирование, а оно долгое и порой сложное.
Напоследок взять Хабр как пример: вроде и руки, и головы в редакции есть. А рисковать как-то никто не хочет, ибо единственная цель, которую можно озвучить громко — SEO — у ТМ-ресурсов и так неплохо достигается без https. Ждем перечеркивания http в браузерах? :)
2. Однако ссылки на внешние ресурсы не всегда «вылечишь» простым убиранием схемы («http://...» -> "//..."), потому что на разных сайтах URL по http и по https бывают разными, да еще алгоритмически, через js, собираемыми — рекламные сети и счетчики как пример.
3. Но вопрос в том, что прикрутить https не всем легко. Во-первых, shared хостинги просто не предлагают такой услуги бесплатно. Предлагают за деньги, и сертификаты часто устанавливают руками. Серверных скриптов, дружащих с let's encrypt, и делающих все автоматом, у них особо не видно — не нужно оно им.
4. Переход для старых, развитых сайтов, на https, не так чтобы прост с точки зрения тестирования и сохранения аудитории. Вроде как легко включить поддержку, а ну как где-то на сайте что-то поломается (сайт — старый, напомню), и юзеры начнут быть недовольны, а как следствие — побегут с ресурса? Тестирование, а оно долгое и порой сложное.
Напоследок взять Хабр как пример: вроде и руки, и головы в редакции есть. А рисковать как-то никто не хочет, ибо единственная цель, которую можно озвучить громко — SEO — у ТМ-ресурсов и так неплохо достигается без https. Ждем перечеркивания http в браузерах? :)
UFO just landed and posted this here
Мне кажется, Хабру не только на это «несколько неважно». Собственно, Хабр — это уже давно не такая, как было когда-то, узкая компания ИТ-ников, сами и для себя творящая контент на сайте. Это бизнес-предприятие, которое, вспомните, продавали-то за совсем недетские деньги. Так что цель «сделать вами хорошо», конечно, есть, но, как и с «мобильной» версткой, в которой невозможно масштабировать контент на экране телефона (тоже вопрос удобства), как и с загружаемыми шрифтами (которые на текстовом ресурсе мало нужны), как с работой «редакторов», которые контент компилируют из «открытых источников», а вовсе не производят новый (по сути, превращая Хабр в сборник краткого изложения статей на других ИТ-ресурсах), как и с блогами компаний, на контент в которых не ругался наверное только ленивый — это все идет по логике «есть ли от изменения существенная прибыль?»
А теперь подумайте: есть ли компании смысл рисковать, вводя https, если непонятно, какой в нем смысл в смысле выгоды? Перечеркнутый http в адресной строке браузера, скорее всего, будет посерьезнее проблем в метро — это уже удар по репутации, т.е. минус в доход.
Правда, когда массовове движение в сторону https (вдруг) начнется, вы уверены, что в метро вас не попросят принять самопальные сертификаты на зоны *.*. и *.*.*. (грубо говоря), выпущенные MSKMetroCA, без которых ничего работать не будет, и не возьмутся вписывать рекламу уже в код https-ных страниц? :)
А теперь подумайте: есть ли компании смысл рисковать, вводя https, если непонятно, какой в нем смысл в смысле выгоды? Перечеркнутый http в адресной строке браузера, скорее всего, будет посерьезнее проблем в метро — это уже удар по репутации, т.е. минус в доход.
Правда, когда массовове движение в сторону https (вдруг) начнется, вы уверены, что в метро вас не попросят принять самопальные сертификаты на зоны *.*. и *.*.*. (грубо говоря), выпущенные MSKMetroCA, без которых ничего работать не будет, и не возьмутся вписывать рекламу уже в код https-ных страниц? :)
Хабр и другие российские сайты, того, что роскомнадзор забанит их домен целиком, а только не страницу с «недопустимым» контентом.
Думаю, что в российском сегменте страх перед роскомнадзором выше, чем забота о безопасности и приватности пользователей.
Думаю, что в российском сегменте страх перед роскомнадзором выше, чем забота о безопасности и приватности пользователей.
1. Только очень странные люди внутри сайта делают ссылки на локальные ресурсы, включающие и схему, хост (т.е. — полные URL-ы). Все остальные разумно пишут абсолютные URI (т.е. ссылки, начинающие от корня собственного веб-сайта), и никаких проблем с этим при переходе на https не испытают. Для совсем тяжелых случаев и HTTP Strict Transport Security поможет, если что.
Например, у если у вас раздача статических ресурсов идет с отдельных доменов, то вам придется писать домен.
Конечно, можно выкрутиться решением "//cdn.example.com/1.jpg" — чтобы браузер сам запрашивал по нужному протоколу. Либо же вообще перевести всю статику на https, но потерять во времени загрузки.
Во-первых, именно что "//cdn.domain.com/...", а не http или https — оно безопаснее в дальнейшем, мало ли что придется делать. Во-вторых, nginx умеет заменять текстовые строки в контенте, так что заменить вполне можно и при отдаче (если нет желания весь сайт перелопачивать).
http/2 должен помочь с раздачей статики с того же хоста — после того, как соединение установлено, контент летит более чем шустро. А если статики много, или у вас на сайте много поддоменов, а статика отдается для всех с одного — иметь выделенный домен для статики вполне вариант, работает более чем быстро.
Ну и конечно, поднять и попробовать, а потом сравнить впечатления никто не мешает. Обидно, что онлайновые тулзы для тестирования скорости загрузки сайтов часто не умеют пользоваться http/2, так что не всегда и узнаешь, есть ли от него выгода.
http/2 должен помочь с раздачей статики с того же хоста — после того, как соединение установлено, контент летит более чем шустро. А если статики много, или у вас на сайте много поддоменов, а статика отдается для всех с одного — иметь выделенный домен для статики вполне вариант, работает более чем быстро.
Ну и конечно, поднять и попробовать, а потом сравнить впечатления никто не мешает. Обидно, что онлайновые тулзы для тестирования скорости загрузки сайтов часто не умеют пользоваться http/2, так что не всегда и узнаешь, есть ли от него выгода.
> Во-первых, именно что "//cdn.domain.com/...", а не http или https — оно безопаснее в дальнейшем, мало ли что придется делать.
Ну я видел серьезный премиальный магазин у которого сайт на https, а картинки раздаются по http c 7 поддоменов. То есть безопасность такая…
> Во-вторых, nginx умеет заменять текстовые строки в контенте, так что заменить вполне можно и при отдаче (если нет желания весь сайт перелопачивать).
Очень большая вероятность, что что-то поломается.
Ну я видел серьезный премиальный магазин у которого сайт на https, а картинки раздаются по http c 7 поддоменов. То есть безопасность такая…
> Во-вторых, nginx умеет заменять текстовые строки в контенте, так что заменить вполне можно и при отдаче (если нет желания весь сайт перелопачивать).
Очень большая вероятность, что что-то поломается.
А разве хабр не работает по https?
Или я что то не так понимаю?
Заголовок спойлера
Или я что то не так понимаю?
Похоже, они его только сегодня включили. Ждём статьи от ТМ.
Дождались. Теперь ждём HTTP/2 на хабре.
Лучше поздно. Но принудительного редиректа на https-версию нет, видимо, работы еще в процессе (либо приостановлены).
Кстати, по поводу коммента musuk по поводу того, что Хабр не включает режим «только https», т.к. не хочет попасть в бан весь, целиком: уверен, что нехороший контент, будя такому появиться на страницах сайта, будет вычищен при первой же жалобе «куда положено» со стороны «нашего всего» — никого не спросят, тупо выпилят. Даже без попыток спора обойдется, если таковое действие не принесет ни пиара, ни выгоды, а потенциально принесет блокировку. В общем, для Хабра https — всего лишь одна из бизнес-возможностей (и бизнес-проблем, если что не так пойдет), это мы с вами понимаем хорошо.
Кстати, по поводу коммента musuk по поводу того, что Хабр не включает режим «только https», т.к. не хочет попасть в бан весь, целиком: уверен, что нехороший контент, будя такому появиться на страницах сайта, будет вычищен при первой же жалобе «куда положено» со стороны «нашего всего» — никого не спросят, тупо выпилят. Даже без попыток спора обойдется, если таковое действие не принесет ни пиара, ни выгоды, а потенциально принесет блокировку. В общем, для Хабра https — всего лишь одна из бизнес-возможностей (и бизнес-проблем, если что не так пойдет), это мы с вами понимаем хорошо.
https увы ОЧЕНЬ сильно повышает требования к процессору при раздаче тяжелого контента. Отдача видео, например, на 30 Гбитах полностью укладывает 2*2687w, при том, что в обычных условиях эти процессоры держат 80.
А без видео по https ругань на смешанный контент и все такое.
А без видео по https ругань на смешанный контент и все такое.
выход OpenSSL новой версии со встроенной поддержкой POLY1305/CHACHA20 сможет снизить нагрузку на процессор?
Не знаю, но сомневаюсь. Все равно шифровать надо порядка 10Гбайт данных в секунду. Возможно, помогла бы специальная шифрующая карта, но это уже сильно усложняет дело.
Проще на https забить. Я пока не очень понимаю, зачем это может быть нужно на развлекательном сайте. Ради 0.001% юзеров, которым злой провайдер может подменить контент — точно не стоит. От Роскомнадзора тоже вроде как не помогает (блокируют по ip, что еще хуже).
Проще на https забить. Я пока не очень понимаю, зачем это может быть нужно на развлекательном сайте. Ради 0.001% юзеров, которым злой провайдер может подменить контент — точно не стоит. От Роскомнадзора тоже вроде как не помогает (блокируют по ip, что еще хуже).
Для развлекательного контента может и HTTP ок, не спорю. Но вот когда доходит до оплаты, я лично стремаюсь вводить номер кредитки на криво сделанном сайте без нормально настроенного HTTPS (не будем тыкать пальцем).
Думаю, достаточно сделать раздел оплаты на https. Трафик (сетевой) там не большой, а профита много. А какой профит от повсемесного https — неясно.
Ну так у них форма оплаты какая-то стрёмная, без HTTPS. Может, конечно, скрипт/ифрейм и по https у них грузится, но в итоге браузер ругается на некошерный смешанный контент. Лично мне стрёмно на такой странице вводить личные платёжные данные: хз какой там скрипт MitM подменит? А попытка насильно загрузить их сайт по HTTPS ручной заменой схемы в адресной строке приводит к полной не функциональности сайта, поскольку куча скриптов и стилей грузятся по абсолютным ссылкам с HTTP. Я зарёкся у них что-то покупать, пока не сделают нормальное шифрование. Не доверяю я таким конторкам. Ещё мне встречался сайт бронирования авиабилетов, который требовал полных паспортных данных и работал только по HTTP. Хотелось материться, просто.
А профит в том, что когда шифруется только критичные данные, это привлекает внимание: «что-то у них всё открыто, а вот тут и тут шифруются, значит там что-то интересное, можно ломать!» А вот если шифруется всё без разбора, то выбрать, где контент важный/чувствительный, а где просто развлекательный атакующему уже не так просто.
ssl на сколько я знаю ломается одинаково, что для всего сайта, что для одного какого-то раздела.
Дело не в том, как ломается, понятно что ломается домен. Дело в том, что если все сайты будут по HTTPS, то отличить те, которые стоит ломать, от тех, которые ломать не интересно.
В 90% случаев, если не 99, ломают подменой сертификатов. На уровне провайдеров или трояном (да что там трояном, антивирусы, адблокеры тоже часто ставят свои сертификаты в систему). Т.е. если сломают, то для всех сайтов сразу (для конкретного пользователя или группы)
Есть одна вещь, которая не будет работать в таком случае — Strict-Transport-Security.
Вы не можете объявить ее на поддомен, не объявив на родительский домен.
Казалось бы мелочь, но…
Надо очень тщательно следить за куками, чтобы случайно не поставить куку на несекурный домен, откуда ее потом можно будет увести.Так же держать в голове, что потенциально пользователю могут подпихнуть куку, которую он потом отправит на https-поддомен.
Есть риск перехвата запроса не несекурный поддомен с редиректом на домен злоумышленников. Причем этот домен может быть очень похожим и использовать https — то есть пользователь может и не заметить.
Технически еще придется поднимать тот же поддомен на http, который будет только редиректить на https и больше ничего не делать — но это мелочи. Впрочем опять надо не начать сервить с этого домена реальные платежные данные.
Вы не можете объявить ее на поддомен, не объявив на родительский домен.
Казалось бы мелочь, но…
Надо очень тщательно следить за куками, чтобы случайно не поставить куку на несекурный домен, откуда ее потом можно будет увести.Так же держать в голове, что потенциально пользователю могут подпихнуть куку, которую он потом отправит на https-поддомен.
Есть риск перехвата запроса не несекурный поддомен с редиректом на домен злоумышленников. Причем этот домен может быть очень похожим и использовать https — то есть пользователь может и не заметить.
Технически еще придется поднимать тот же поддомен на http, который будет только редиректить на https и больше ничего не делать — но это мелочи. Впрочем опять надо не начать сервить с этого домена реальные платежные данные.
Вы не можете объявить ее на поддомен, не объявив на родительский домен.
А как мы тогда объявляем HSTS на example.ru? Она объявлена на родительском домене ru., а для этого — на корневом .? Корневой вообще к HTTP не имеет никакого отношения, там невозможно ничего подобного объявить.
Или я не понял, о чём вы.
Я не очень четко выразился, имеется ввиду, что без объявления HSTS на example.com, объявление HSTS будет малополезной опцией.
Например, у вас есть example.com, где показывается видео, и есть account.example.com для управления своим счетом. покупками и пр.
Естественно, у вас на example.com есть ссылка на account.example.com (и на всякий вы объявили для этого поддомен HSTS, если вдруг пользователь пойдет туда без правильной ссылки).
Толку от этого 0, ссылку на example.com можно подменить, например, на account-example.com и пользователь по ней попадет в совсем другое место.
То есть если у вас не защищен предыдущий сайт, то защита следующего даст очень мало.
Например, у вас есть example.com, где показывается видео, и есть account.example.com для управления своим счетом. покупками и пр.
Естественно, у вас на example.com есть ссылка на account.example.com (и на всякий вы объявили для этого поддомен HSTS, если вдруг пользователь пойдет туда без правильной ссылки).
Толку от этого 0, ссылку на example.com можно подменить, например, на account-example.com и пользователь по ней попадет в совсем другое место.
То есть если у вас не защищен предыдущий сайт, то защита следующего даст очень мало.
Мы тут про фишинг говорим?
Это другое место отображается в адресной строке браузера? Оно отображается с замочком, а может быть — с зелёной строкой и надписью, кто там подтверждён EV? И эта надпись совпадает? Это что за удостоверяющий центр, который может подписать одно и то же название для двух разных cname, да ещё и EV влепить?
Если пользователь видит другое и тем не менее ломится как баран — ну, он и есть баран.
Это другое место отображается в адресной строке браузера? Оно отображается с замочком, а может быть — с зелёной строкой и надписью, кто там подтверждён EV? И эта надпись совпадает? Это что за удостоверяющий центр, который может подписать одно и то же название для двух разных cname, да ещё и EV влепить?
Если пользователь видит другое и тем не менее ломится как баран — ну, он и есть баран.
И про фишинг, и про mitm, и про отравление кеша DNS, да и вообще про обеспечение безопасности с помощью HSTS.
Суть в том, что уязвимости будут «транслироваться» в защищенный сайт и считать что HSTS для поддомена достаточно для его защиты и использования несекурного протокола.
Суть в том, что уязвимости будут «транслироваться» в защищенный сайт и считать что HSTS для поддомена достаточно для его защиты и использования несекурного протокола.
Вообще, DNSSEC с DANE было бы достаточно, чтобы послать все эти удостоверяющие центры в анналы истории.
Это была бы идеальная технология domain validation — цепочка доверия начинается с dnssec корневой зоны ., который удостоверяет TLD, который удостоверяет наш домен, который удостоверяет TLSA-запись, в которой хеш публичного ключа из HTTPS-сертификата. Сам этот сертификат — да хоть самоподписанный.
А по дороге бонус — DNS вообще никак не отравишь, он же весь обвешан подписями. В худшем случае выдаёт отказ с сообщением «где-то по дороге завёлся жук и подписи не совпадают».
Но почему-то не спешат, внедряют всякую хрень, изобретают костыли вида letsencrypt.
Это была бы идеальная технология domain validation — цепочка доверия начинается с dnssec корневой зоны ., который удостоверяет TLD, который удостоверяет наш домен, который удостоверяет TLSA-запись, в которой хеш публичного ключа из HTTPS-сертификата. Сам этот сертификат — да хоть самоподписанный.
А по дороге бонус — DNS вообще никак не отравишь, он же весь обвешан подписями. В худшем случае выдаёт отказ с сообщением «где-то по дороге завёлся жук и подписи не совпадают».
Но почему-то не спешат, внедряют всякую хрень, изобретают костыли вида letsencrypt.
Возможно, в какой-то момент к этому придут. Когда бизнес на сертификатах станет совсем не выгодным.
С другой стороны — получается, что будет зависеть от DNS-провайдеров, что тоже не очень хорошо. Серьезный сбой DNS, разделегирование и пр — и ничего не работает и не защищено.
Здесь есть хоть запасной вариант — прописать адреса руками и работать.
С другой стороны — получается, что будет зависеть от DNS-провайдеров, что тоже не очень хорошо. Серьезный сбой DNS, разделегирование и пр — и ничего не работает и не защищено.
Здесь есть хоть запасной вариант — прописать адреса руками и работать.
К слову, на YouTube в Chrome отдача идет как раз через CHACHA20_POLY1305.
У Cloudflare в Universal SSL также используется по возможности данный шифр, как они писали в блоге, это сильно позволяет снизить нагрузку на процессор.
К сожалению, пока что дефолтные версии серверов/библиотек из репозиториев на большинстве систем не поддерживают эти шифры.
Понятно, что у YouTube на порядки больше серверов, чем у вас, и им проще перейти на SSL. Однако, уже в ближайшем времени трафик без шифрования планируется пометить небезопасным значком, поэтому лучше подготовиться заранее…
У Cloudflare в Universal SSL также используется по возможности данный шифр, как они писали в блоге, это сильно позволяет снизить нагрузку на процессор.
К сожалению, пока что дефолтные версии серверов/библиотек из репозиториев на большинстве систем не поддерживают эти шифры.
Понятно, что у YouTube на порядки больше серверов, чем у вас, и им проще перейти на SSL. Однако, уже в ближайшем времени трафик без шифрования планируется пометить небезопасным значком, поэтому лучше подготовиться заранее…
А как у https дела с кэширующими прокси? Я слышал, что без страшных хаков и костылей никак, да и не укладываются кэширующие прокси в философию https.
Имхо, вся эта истерия с https наруку только «продаванам» доверенных сертификатов и гугол в данном случае на их стороне.
А у меня только что дата сбилась. В результате 99% сайтов перестали грузится, не давая зайти по https. Среди них и гугл, через который хотел найти решение проблеммы с ntpd.
Спас elinks.
Так-то.
Спас elinks.
Так-то.
А когда https станет (если станет) повсеместным, то нам скажут: им пользуются террористы и педофилы, надо запретить.
Раз уж тут делятся печальным опытом работы с HTTPS тоже добавлю.
В августе прошлого года купил COMODO SSL и поставил себе на домен. Спустя какое-то время сайт вылетел из выдачи Яндекса из-за… чувака который повесил DNS своего домена на меня. У меня видимо не было настроено поведение сервера в случае отсутствия хоста в nginx, хотя по идее должен отдаваться дефолтный/первый. C http точно было все ок.
Более того даже в Яндекс-Вебмастере я увидел над своими сайтами в виде главного зеркала чужой домен…
В августе прошлого года купил COMODO SSL и поставил себе на домен. Спустя какое-то время сайт вылетел из выдачи Яндекса из-за… чувака который повесил DNS своего домена на меня. У меня видимо не было настроено поведение сервера в случае отсутствия хоста в nginx, хотя по идее должен отдаваться дефолтный/первый. C http точно было все ок.
Более того даже в Яндекс-Вебмастере я увидел над своими сайтами в виде главного зеркала чужой домен…
Кажется, должно быть наоборот. По правильному имени вы видите нормальный валидный https, а по неправильному — даже если увидите сам сайт, по https он не будет валидным (т.к. неправильного имени нет в вашем сертификате). Или что-то я не понимаю?
Здравствуйте, Дмитрий!
Главное зеркало выбирается роботом с учетом пользовательских указаний, которыми могут являться 301 редирект, а также директива host в robots.txt всех зеркал, только в том случае, если они соответствуют одному и тому же адресу и не противоречат друг другу. В противном случае, как, например, в Вашем, робот может выбрать главное зеркало автоматически на основании собственного алгоритма, подробности работы которого мы не разглашаем.
С уважением, Платон Щукин
Ну бред же. Если сайт доступен по https, то это нормально — считать его основным. Shame on you, Yandex.
Да у Яндекса вообще с зеркалами непонятная политика. Полгода назад у нас был 301 редирект с условного example.com на example.org. Затем мы переделали редирект в обратную сторону. Нормальные поисковики на букву G через некоторое время подхватили редирект и сменили все ссылки в выдаче на example.com. А Яндекс нас просто молча выкинул из выдачи вообще. Оказалось яндекс-бот, заходит на example.com, находит редирект на example.org, далее смотрит в свою БД и находит там редирект в обратную сторону, после чего у него наступает, видимо, когнитивный диссонанс. В результате оба домена в бане по причине «неглавное зеркало». Нам пришлось оба домена держать открытыми почти полгода, чтобы Яндекс наконец соизволил переклеить нам зеркала.
У меня вопрос. Правильно ли я понимаю что при использовании HTTPS не будет работать HTTP кэширование? Это вполне ожидаемо в случае HTTPS, но вызывает дополнительную нагрузку на сервер и канал. Мало того что придется шифровать запрос/ответ, но еще и контент придется отдавать на каждый запрос. Всю статику придется тянуть каждый раз.
Получается мы повышаем безопастность сайта в ущерб производительности. По моему это не совсем правильно. Поправьте меня если я ошибаюсь.
Получается мы повышаем безопастность сайта в ущерб производительности. По моему это не совсем правильно. Поправьте меня если я ошибаюсь.
Если в браузере включено кэширование, и сервером корректно установлены ETag, Cahe-Control, то кэширование будет работать.
Почитайте про мифы: blog.httpwatch.com/2011/01/28/top-7-myths-about-https
Почитайте про мифы: blog.httpwatch.com/2011/01/28/top-7-myths-about-https
Спасибо за ссылку. Тоже самое только на русском. Может кому пригодится
Sign up to leave a comment.
Почему до сих пор повсеместно не используется HTTPS?