Или потушить пожар с другой стороны железнодорожных путей. И очень нужно протянуть туда гидрант, но нельзя останавливать поезда — какие есть варианты? Никаких? Опять неправильно!
Заметили тенденцию? Давайте распространим её на цифровой мир и немного поговорим о HTTPS.
Вы обязаны использовать HTTPS. Нет, реально, если вы не заворачивается всё в HTTPS, то поступаете нехорошо. Разработчики браузеров знают об этом и всё плотнее прижимают к ногтю непослушные сайты. Давление особенно увеличилось в январе, когда одновременно Chrome и Firefox начали выводить предупреждения, если форма авторизации передаётся по небезопасному каналу. Не все были рады этому, потому что… блин, HTTPS это же трудно, так? Не так, но это не остановило компанию Oil and Gas International от регистрации баг-репорта в Mozilla:
«Ваше сообщение о небезопасной передаче пароля и/или авторизации автоматически появляется при авторизации на нашем сайте Oil and Gas International — оно не нужно и помещено туда без нашего разрешения. Пожалуйста, немедленно уберите его. У нас есть собственная система безопасности, и её не разу не взломали более чем за 15 лет. Ваше сообщение вызывает тревогу у наших подписчиков и наносит ущерб нашему бизнесу».
Это довольно забавно, потому что «вызвать тревогу у подписчиков и нанести ущерб бизнесу» — именно то, чего добивались разработчики браузеров! Это такое средство воздействия, чтобы заставить организации обезопасить свои сайты, когда простой здравый смысл на них не действует. (Кстати, я думаю, что их 15-летний период без взломов таки прервался, когда они сообщили об этом «баге» и сразу подверглись бесплатным пентестам).
Что же делать? Ну ясно, что если такие предупреждения мешают вашему бизнесу, то от них надо избавиться! Я не шучу, кое-кто действительно сделал это:
На самом деле я узнал об этом только вчера, когда один человек описал мне разговор с представителем компании ShopCambridge.ca:
«Я говорил с владельцем об использовании SSL перед тем, как я оформлю у них членство, но разработчик платформы сказал ей (это система франчайзера под названием ShopCity.com), что SSL скорее помогает Google монополизировать видимость контента, чем обеспечивает безопасность».
К ShopCity.com вернёмся чуть позже, а сейчас давайте попробуем понять их логику. Как известно, предупреждения безопасности в браузере появляются только если в input атрибут type установлен как "password". Если так, то возникает идея — создать то, что выглядит как форма для ввода пароля, но на самом деле таковой не является:
<input id="pw" placeholder="Password" name="pw" maxlength="100" class="textbox" style="width:230px;margin-bottom:5px;" onclick="javascript:this.placeholder='';" type="textbox">Она только говорит "Password", а на самом деле там установлен атрибут "textbox". В ней единственный класс CSS для некоторой стилизации, но если ввести курсор в поле, то происходит магия:
<script>
jQuery(document).on('click', '#pw', function() {
jQuery(this).addClass('text-security');
})
</script>И вот у нас в поле совершенно новый класс. Ну и конечно, событие onclick в поле ввода устанавливает текст заполнителя как пустая строка. Так что делает этот новый класс? Он просто меняет шрифт:
.text-security {
font-family: 'text-security-disc';
}И как вы могли догадаться, этот «шрифт» ни что иное, как единственный символ кружочка, который вы обычно видите, когда вводите пароль в правильную парольную форму. Всё должно работать в таком порядке, потому что иначе заполнитель не покажет надпись "Password", а вы просто увидите 8 кружочков для букв. И если всё связать вместе, то создаётся видимость парольного поля, но поскольку это не парольное поле, то нет никаких предупреждений браузера! Это как магия! Точнее говоря, это псевдопарольное поле для обмана пользователей, чтобы они не увидели предупреждение браузера.
И скрипт для добавления класса, и CSS для шрифта встроены рядышком в исходник страницы, как некая запоздалая мысль:
Вообще, этот блок JS и CSS там дважды, один раз на строке 1111, а другой раз — на строке 1156. Наиболее вероятное объяснение, которое приходит мне на ум, что где-то в течение этого года, когда начали появляться предупреждения безопасности на всех незащищённых сайтах, где-то выступил какой-то предприимчивый разработчик: «Я знаю, как это исправить!». O, и между прочим, используемый шрифт создан как минимум два с половиной года назад, что намного раньше, чем в браузерах появились предупреждения безопасности, которые этот «патч» должен был исправить.
Это действительно нелепо и никак не могло быть случайным совпадением. Я имею в виду, что не было никаких других дизайнерских решений, после чего в качестве побочного продукта появился хак с сокрытием предупреждений безопасности в браузерах. Это была преднамеренная попытка скрыть с экрана информацию, ценную с точки зрения безопасности — она была сделана специально для защиты пользователей. К счастью, подобная глупость больше не работает в Chrome 62 и, как я писал в недавней статье Happy Path to HTTPS, такое поведение постепенно станет доступно всем пользователям:
В идеале, браузер Firefox тоже продублирует этот патч, и Скотт Хельме уже зарегистрировал в Mozilla баг о сомнительном поведении ShopCambridge.ca. Но ясно, что суть проблемы в фундаментальном непонимании технологии со стороны разработчиков франчайзера ShopCity.com. Если помните, это их я упоминал в первом сообщении, которое получил от одного читателя, и вы можете увидеть такой же хак на других сайтах их платформы, таких как ShopMidland.com. При попытке загрузить любой из небезопасных сайтов по HTTPS выдаёт невалидный сертификат, в случае для ShopCity.com такой:
Хотя он не для ShopCity.com, а для Secure.ShopCity.com, так что если вы попытаетесь загрузить https://www.shopcity.com, то получите другое исключение безопасности, потому что, естественно, сертификат невалидный! Так что я попробовал вместо этого загрузить https://secure.shopcity.com, но здесь сертификат тоже (немного) не работает:
Похоже, их просто не волнует безопасная выдача контента, что возвращает нас к предыдущему комментарию: «SSL скорее помогает Google монополизировать видимость контента, чем обеспечивает безопасность». Я и раньше слышал подобное от человека, которого можно назвать разве что антивакцинатором в технологическом мире, он отпускает комментарии вроде таких:
Google просто зло, потому что это гигант. Пошёл он в ж**у.
Он объяснял, что из-за плохого кода на бэкенде сайт могут взломать даже при наличии SSL, но зелёный замочек остаётся, вводя пользователей в заблуждение, поэтому HTTPS бесполезен. Если поискать по тегу SSL в моём блоге, то можно найти на удивление много подобных высказываний, что SSL — просто бандитское крышевание со стороны Google.
Я на самом деле связался с ShopCity.com и спросил, почему же они ведут себя таким образом, но на момент публикации не получил ответа.
Так что предпринять этим ребятам? На самом деле ответ очень простой:
Для тех, кто хочет перейти на HTTPS, см. 6-шаговое руководство "Happy Path" to HTTPS, которое я уже упоминал. Сейчас это проще чем когда-либо, и вам даже не понадобится обманывать своих пользователей!
Комментарии (106)
oWart
04.11.2017 11:18На картинке про жд пути не хватает таблички sarcasm, долго пытался понять как это работает.
Хотя наверное небольшой смысл в этом есть: например обозначить шланг для трамваев.
alizar
04.11.2017 11:31+4ИМХО, эта картинка хорошо символизирует дальнейшее содержание статьи, где люди проявляют такую же «находчивость», чтобы обойти браузерные предупреждения.
alizar
04.11.2017 11:34+5Собственно, как и первая фотография, где люди убивают себя в бассейне.
zapimir
04.11.2017 17:57+1Да ладно, там явно через УЗОшку или дифавтомат подключено. Так что не более, чем стёб.
Shluzzz
06.11.2017 15:31Если там не хватает защитного проводника, как во многих древних «удлинителях», то не поможет :)
ploop
06.11.2017 16:03Вполне поможет, если есть хоть небольшая утечка на землю. А там она есть, как в прямом, так и в переносном смысле :)
Касаемо картинки: как выше сказали — обычный стёб. Эту конструкцию не обязательно включать в сеть, чтобы сделать фотку :)
linuxover
04.11.2017 11:20+2я так и не понял: автор-то как относится к навязыванию https — положительно или отрицательно?
по мне так: https — это то о чем может подумать разработчик того или иного сайта, заталкивать его насильно — неправильно.
А вот усилия, которые потрачены на заталкивание всех и вся на https лучше бы были потрачены на написание нормального драфта к скажем новому css. Ведь у css и скажем вообще W3C какая проблема? Пишут стандарты люди, которые сами ими никогда не пользуются, отсюда 100500 новых тегов, а как начинаешь вести разговор о нормальном layout manager'е (да он появляется со скрипом: flex уже местами можно использовать (пару багов на iphone починят и будет ок), grid пока нельзя (поддержка слабая)), так тебя аргументами долбят "html — это о гипертексте, а не о приложениях".
avost
04.11.2017 15:30А почему неправильно-то? У вас есть какой-то другой способ обезопасить передачу данных форм по незащищённому каналу? Ну, только не говорите про наколеночную эмуляцию функциональности tls яваскриптом.
rPman
04.11.2017 18:44+1это не поможет, так как злоумышленник подменит код проверки на свой
avost
05.11.2017 19:11Простите, что не поможет, о каком коде вы говорите и каким образом злоумышленник его подменит?
Nokta_strigo
05.11.2017 19:29Не поможет «наколеночная эмуляция функциональности tls яваскриптом», если имеется ввиду загружаемый с сайта яваскрипт. Злоумышленник заменит этот яваскрипт-TLS на свой код, который даст ему нужный доступ к вашему трафику.
linuxover
05.11.2017 22:13неправильно навяливать шифрование там где оно не нужно.
вот скажем был ресурс с некислой посещаемостью и на нем не было никогда взломов итп (хотите пример — forum.ixbt.com, например).
поскольку жил ресурс (и живет) на http, проблем не имея, то следовательно внедрение https ему кроме избыточной нагрузки на железо не принесет: пользователи не добавятся, с безопасностью ситуация не улучится итп.
и вот зачем такие сайты насильно загонять на https?
faiwer
06.11.2017 07:56И вот вы заходите на свой любимый форум (пусть это будет ixbt) в кафе, вводите логин и пароль и, как ни в чём не бывало, продолжаете сёрфить сеть. А ваш логин и пароль ушли в базу злоумышленника. Теперь эти люди могут использовать ваш аккаунт на форуме в гнусных целях. Скажем если там есть личка — слать людям спам. Или регистрировать спам-топики. Или накручивать голосования. Но вы то IT-ик, у вас, наверное, на ixbt особенный пароль. А вот у вашего знакомого, условно, Пети, на все сайты 1 пароль. И когда он зашёл в этом кафе в свой профиль на ixbt, то тут же подарил злоумышленникам доступ к своей почте, социальным сетям и прочим ресурсам. Продолжать? Замечу, что ixbt как был без уязвимостей, так и остался. Но из-за уязвимости соединения — кто-то хорошо разжился.
linuxover
06.11.2017 10:18-1> И вот вы заходите на свой любимый форум (пусть это будет ixbt) в кафе, вводите логин и пароль и, как ни в чём не бывало, продолжаете сёрфить сеть. А ваш логин и пароль ушли в базу злоумышленника.
вот пользуюсь forum.ixbt.com с 2000-го года, такого случая не было никогда
а вот на linux.org.ru, который года с 2001-го на https подобные случаи бывали
внимание вопрос: а нужно ли внедрять https такими варварскими методами? может лучше о безопасности подумать?
> Но вы то IT-ик, у вас, наверное, на ixbt особенный пароль.
ixbt запрещает свои пароли придумвать, а генерит их сам.
а linux.org.ru — напротив
> Но из-за уязвимости соединения — кто-то хорошо разжился.
гипотетически, а вот практически все наоборот :)Taciturn
06.11.2017 13:20Как это запрещает? forum.ixbt.com/users.cgi?id=profile — Пароль: Изменить. Только что проверил, всё прекрасно меняется.
linuxover
06.11.2017 14:08-1всегда пользовался тем паролем что сайт сгенерил и не задумывался о том существует ли возможность его поменять.
Думаю что 99% пользователей поступает точно так же :)Tallefer
06.11.2017 14:54Вот и главная ошибка — слишком много думаете за других. :) В последнее время в тренде поминать «ошибку выжившего», если так проще.
И «практически все наоборот» можно трактовать примерно как фразу того мужика из анека, летящего с крыши: «Пока все хорошо». :)
avost
07.11.2017 13:56+1неправильно навяливать шифрование там где оно не нужно.
вот скажем был ресурс с некислой посещаемостью и на нем не было никогда взломов итп (хотите пример — forum.ixbt.com, например).А давайте, вы сходите на этот ресурс, нажмёте там кнопочку логина и внезапно (вот сурпрайз-то!), попадёте на страничку с https :)
Спасибо за такой замечательный пример! Апплодирую стоя!
и на нем не было никогда взломов
Доказательства?
с безопасностью ситуация не улучится
Именно что улучшится. Почитайте что-нибудь по теме, кроме "у меня аккаунт не угоняли, значит ни у кого не угоняли".
baldr
08.11.2017 13:17А давайте, вы сходите на этот ресурс, нажмёте там кнопочку логина и внезапно (вот сурпрайз-то!), попадёте на страничку с https :)
А теперь давайте мы с вами снова вернемся в кафе, где хакер Va$$ilY, попивая смузи, заканчивает собирать куки сессий залогиненых пользователей сайта ixbt через свой хоспот «Free Cafee Wifi», а его скрипт «make_bad_thing.py» с помощью этих куки рассылает плохой спам.
Именно по этой причине браузеры и не разрешают mixed content.
lexore
04.11.2017 16:09+1по мне так: https — это то о чем может подумать разработчик того или иного сайта, заталкивать его насильно — неправильно.
Никто и не заставляет разработчиков под дулом пистолета переходить на https.
Просто в случае с https браузеростроители думают в первую очередь о своих пользователях.DrPass
05.11.2017 00:36Меня, кстати, оно и как пользователя раздражает, и очень хотелось бы видеть в браузере настройку вида «Спасибо, я уже знаю, чем мне может грозить передача форм по http». И ещё, как по мне, 90% сайтов в Интернете вообще не нуждаются в https, а 9.99% нуждаются в https только в той части, где происходит обработка заказов/платежей. Лично я бы предпочёл, чтобы сайт, на котором я заказываю пиццу, позволял бы злобным хакерам (при настойчивом желании, конечно), перехватывать информацию о том, какую пиццу и куда я заказываю, но при этом отзывался бы на полсекунды быстрее, не тратя вычислительные ресурсы на шифрование контента. Но это моё ИМХО.
Tallefer
05.11.2017 00:59Дело не в «пицце» (хотя и в ней тоже), дело в деньгах, а самое главное — в том, что можно подсунуть невдупляющему юзеру под видом сайта с пиццей. :)
А настройки такой не будет, и это хорошо. :)DrPass
05.11.2017 01:11Деньги-то не на сайте с пиццей платятся. 3D-secure же :)
, а самое главное — в том, что можно подсунуть невдупляющему юзеру под видом сайта с пиццей. :)
Вот не уверен я, что невдупляющему юзеру будет какая-то разница между просто поддельным сайтом с пиццей, или поддельным сайтом с пиццей и перечеркнутым красненьким замочком в строке адреса.
KivApple
05.11.2017 08:53Шифрование гораздо более лёгкая операция, чем рендеринг сложного DOM, просчёт влияния CSS стилей и исполнение JavaScript. Она просто капля в море на их фоне. Плюс скорость сети такова, что данные всегда поступают медленнее, чем обрабатываются. Так что для пользователя разница на уровне плацебо на самом деле.
DrPass
05.11.2017 11:28Да, но, грубо говоря, на тысячах обращений рендеринг страницы делается силами тысяч устройств, а шифрование — одним сервером тысячи раз. Поэтому на скорость отклика оно таки влияет.
KivApple
05.11.2017 13:55Так сервер помимо шифрования тоже выполняет кучу всяких действий — чтение данных с диска, запросы к БД, выполнение всяких серверных скриптов (PHP/NodeJS/Python/Java/etc). И опять мы приходим к тому, что шифрование будет отнимать слишком мало ресурсов на их фоне, чтобы о нём беспокоится.
firk
06.11.2017 14:25«Спасибо, я уже знаю, чем мне может грозить передача форм по http»
Во всеми нелюбимом IE было (а наверно и сейчас есть) предупреждение при отправке любой формы примерно такого содержания: "Данные, отправленные в интернет, могут быть доступны третьим лицам, продолжить?" (и опция "больше не спрашивать"). В других браузерах такого не видел. И на мой взгляд оно более честное, чем предупреждения только про http.
sshikov
05.11.2017 13:39Как не заставляют? Ну вот смотрите — на http соединении теперь не работает geolocation API, например. И еще service worker-ы.
Это авторы Chrome позаботились о том, чтобы наша геолокация не утекла к конкурентам. Причем заметьте — это наши пользователи, не их. У меня вот вообще интранет, закрытая сеть, либо пользователи на VPN. Это не их дело, не авторов хрома, как я собираюсь защищать своих пользователей, и нужно ли их вообще защищать.
Tallefer
05.11.2017 15:17Просто в случае с https браузеростроители думают в первую очередь о своих пользователях.
Они делают браузер для ВСЕХ пользователей, а о ваших они знать не знают, поэтому это и реально не их дело. :)
ploop
04.11.2017 23:18+1по мне так: https — это то о чем может подумать разработчик того или иного сайта, заталкивать его насильно — неправильно.
О чём думает разработчик тут не при чём, браузер предупреждает пользователя. А дальше ему решать.
alix_ginger
05.11.2017 10:29Да просто нет ни одной причины не использовать SSL. Даже бесплатные сертификаты уже есть
VolCh
05.11.2017 17:53В общем и целом полноценная настройка https в нетривиальной среде — задача не на 5 минут.
FyvaOldj
05.11.2017 10:57Неправильно то неправильно.
Но подавляющее большинство разработчиков и владельцев сайтов — обычные люди.
Им влом изучать что то новое, если это новое лежит не непосредственно на пути их интересов. Им влом платить пока жаренный петух не клюнул. И пр. И пр.
Работает же? Ну и хорошо. А мы поленимся.
Большая часть людей вообще работает только потому что кушать будет нечего. Поэтому людей нежно пинать
linuxover
05.11.2017 22:17большую часть сайтов в голову никакому «хакеру» не придет снифать и пытаться заполучить пароль от них
faiwer
06.11.2017 08:03Для этого не нужен никакой хакер. Просто обновляемое ПО для, скажем, роутера. В котором есть база на все популярные сайты. Или даже без базы. Роутер помимо основной задачи высматривает исходящий траффик на предмет полей вроде
passwd,passwordи им подобных. А обнаружив такое — просто шлёт на сервер злоумышленника. А там даже если под конкретный сайт Васи Пупкина поддержки ещё нет, эта информация будет лежать и ждать своего часа. Накопится, условно, критическая масса — на сайт "посмотрят", изучат формы, скажем, авторизации и страница профиля, и добавят в общую базу на общих основаниях. Хотя в принципе достаточно просто пары логин-пароль. У большинства пользователей 1-2 пароля на все сайты. Ещё можно людям подсовывать расширения на установку. А потом из таких вот заражённых ПК устраивать ботнеты. Честно говоря бездна всяких возможностей, вмешиваясь в трафик сайтов без уязвимостей, вершить грязные дела.DrPass
06.11.2017 11:36В случае установки зловредного кода на роутере справиться с https не так уж и сложно. Клиенту при первом запросе к сайту вернуть редирект на http, он ничего и не заметит. А безопасный хендшейк с сервером проводить на роутере, и возвращать клиенту уже расшифрованные данные по http. Описанная вами ситуация массово не происходит не потому, что https спасает, а потом, что злоумышленники не так часто добираются до прошивок всяких ТПлинков.
faiwer
06.11.2017 15:30Проблема с редиректом, насколько я понимаю, имеет место быть. Но там не всё так грустно. Если я правильно понял суть заголовка
Strict-Transport-Security, то он сильно усложняет жизнь таким редиректам, в случае, если этот сайт был открыт ранее в нормальных условиях. Ещё есть некийHSTS preload list, но он выглядит как-то несерьёзно в масштабах всего интернета. Надеюсь нас ждут какие-нибудь более серьёзные механизмы.
firk
06.11.2017 15:56Чтобы вернуть редирект, надо внедриться в https-сессию, а если у вас это получится, то редирект будет уже не нужен.
AntonAlekseevich
04.11.2017 11:39Однако всё же правы и те кто за SSL, и те кто против SSL.
SSL защищает только соединение. (Могу ошибаться.)
Но уязвимыми будут всегда и сервер, и клиент как конечные точки. (Здесь неправ? Всякие случаи бывают.)Nokta_strigo
05.11.2017 00:59SSL/TLS в первую очередь защищает именно соединение. Плюс SSL защищает пользователя от атак, связанных с инжектированием вредоносных JavaScript в код сайта. Плюс может подтверждать пользователю, что он находится на сайте, принадлежащем конкретному юр. лицу (если во-первых это юр. лицо раскошелилось на Extended Validation сертификат, а во-вторых пользователь достаточно грамотный).
За внедрение SSL борются, т.к. это не очень сложно и, при желании, бесплатно. И при этом заметно снижает количество векторов атак.AntonAlekseevich
05.11.2017 10:54SSL/TLS в первую очередь защищает именно соединение.
Значит не ошибся.
Плюс может подтверждать пользователю, что он находится на сайте, принадлежащем конкретному юр. лицу (если во-первых это юр. лицо раскошелилось на Extended Validation сертификат, а во-вторых пользователь достаточно грамотный).
Это всего лишь одна из приятных плюшек SSL.
Насчет второго, не все пользователи достаточно грамотные в этом плане.Nokta_strigo
05.11.2017 12:28Ну, надо распространять грамотность ;-) Можно начать прям тут:
Если в строке адреса рядом с зелёным замком появляется «плашка» с названием организации (пример: paypal.com) — значит на сайте Extended Validation сертификат и этот сайт правда принадлежит тому юр. лицу, которое указано на «плашке». Если просто зелёный замок (пример: habrahabr.ru) — значит соединение зашифровано и идёт до того сайта, который набран в строке адреса.AntonAlekseevich
05.11.2017 12:51Можно начать прям тут.
Тут частично бесполезно. Это лучше распространять на форумах "хомячков".
KivApple
05.11.2017 14:03Обычно именно соединение является наиболее ненадёжной частью. И клиент, и сервер подконтрольны лицам, которые крайне заинтересованны в безопасности данных. А вот между ними — очень много различных мутных лиц. Особенно это касается последней мили — взять хотя бы Wi-Fi в отеле или кафе — к нему может подключиться неопределённый круг лиц. Да и в домашних роутерах периодически находят всякие уязвимости, при этом обновлений они практически не получают. Или вот, например, уязвимость в WPA2 недавняя… Векторов атаки — куча, причём если защитить свой клиент или сервер вариантов масса (грамотная настройка, антивирусы и т. д.) и они часто необременительны, то повлиять на пространство между клиентом и сервером возможности нет, либо они связанны со значительными трудностями.
AntonAlekseevich
05.11.2017 14:32Или уязвимость в Dropbear(В последних и не очень обновах Sagemcom'ов).
Роутеры с каждым днем всё более и более уязвимы(исключения конечно есть.).
firk
04.11.2017 11:46Это довольно забавно, потому что «вызвать тревогу у подписчиков и нанести ущерб бизнесу» — именно то, чего добивались разработчики браузеров!
В таком случае компания в полном моральном (а наверно, и юридическом, но тут, к сожалению, не уверен) праве подать на указанных разработчиков в суд за вышеуказанное вредительство.
Нужность/ненужность https — отдельная тема, но браузерописатели сильно наглеют и забывают своё место, и в первую очередь естественно благодаря гуглу. Браузер — это программа для показа сайтов, она вторична и должна выполнять что ей говорит пользователь, вводя адрес, и сайт своим кодом, а не пытаться что-то навязывать как первой, так и второй стороне.lexore
04.11.2017 16:06+8Совсем обнаглели эти бесплатные опенсурсные браузеры.
nidalee
05.11.2017 00:59-1Было бы смешно ради интереса повесить (со стороны разработчиков браузера) всем посетителям Хабра плашку «Поставьте пользователю lexore минус в карму» со ссылкой для удобства.
Какова была бы реакция? А что, open source — могут вешать, что захотят, главное бесплатно…
Не то чтобы я был против HTTPS — мне в общем-то все равно.
ploop
04.11.2017 23:21Браузер — это программа для показа сайтов, она вторична и должна выполнять что ей говорит пользователь, вводя адрес
Нафига тогда пользователю вообще показывать в строке, https там или нет, лишние буквы только смущают. Так эти наглецы разработчики ещё и картинку рядом ставят!firk
05.11.2017 13:02Поставить ненавязчивое уведомление (которое пользователь, вероятно, захочет видеть) — это одно, а пытаться указывать пользователю "это смотри. а это не смотри" — совсем другое. С тем же https с невалидными сертификатами — ок, показали предупреждение, я нажал кнопку "мне пофиг, показывай и не возражай" — и браузер должен показывать. Но нет, они со временем прячут эту кнопку всё дальше и дальше, чтобы МНЕ затруднить её нажатие. А ещё ff с некоторых пор её вообще не показывает если на сайте было HSTS — пишет что "нельзя". Что это такое? Почему браузер запрещает мне проигнорировать предупреждение? Повторюсь, его первоочередная задача — исполнять указания пользователя, какими бы они ни были. Ну я то пропатчил ему исходник и убрал эту гадость, а многие просто послушаются.
superconductor
06.11.2017 15:31+1Так суть HSTS как раз в том, что если вдуг получился только http, значит это или mitm, или сервер хакнули и туда (сейчас) идти нельзя.
firk
06.11.2017 19:16Не браузеру решать, что можно а что нельзя. Решает пользователь, максимум его можно предупредить.
superconductor
06.11.2017 19:24+1Боюсь, что в этом случае вы не правы, т.к. спецификация явно требует разрывать не безопасные соединения с hsts хостами. https://tools.ietf.org/html/rfc6797#section-8.4
firk
06.11.2017 20:30Надо подсказать роскомнадзору оформить свои списки в виде спецификаций, тогда наверно сразу прекратятся возражения против них, а авторы браузеров встроят блокировки прямо в код браузеров и всем будет хорошо.
А если серьёзно, то в нормальных спецификациях (тот же http) наоборот призывается клиенту/серверу быть максимально толерантными к тем нарушениям протокола с удалённой стороны, которые не создают непреодолимых препятствий к пониманию чего они хотели.superconductor
06.11.2017 20:37Если роскомнадзор придумает вменяемую спецификацию, её обсудят сообществом и примут как рекомендацию w3c, то почему бы и нет.
Но это представляется маловероятным, ведь сообщество никогда не примет механизм для зацензуривания интернета, не так ли?firk
06.11.2017 21:35Обсуждаемую особенность конечно сложно назвать цензурой, но у неё и ркн-блокировок есть очень важная общая деталь: и там и там за вас решили, что вам это не надо, и какие-то люди по собственному желанию охраняют вас от "опасностей". И там и там они, разумеется, действуют в ваших же интересах, а то вдруг вы по глупости откроете что-то не то, да и пострадаете. Методы реализации этой "охраны" немного разные, да, но это уж кто как может так и делает.
superconductor
06.11.2017 22:01-1Мне кажется вы не до конца понимаете идею следованию спецификации для обеспечения безопасности соединения.
Или вам и ремень безопасности кажется ограничением вашей свободы? В таком случае у меня для вас плохие новости.
alix_ginger
05.11.2017 10:34Браузер — это программа для показа сайтов, она вторична и должна выполнять что ей говорит пользователь, вводя адрес, и сайт своим кодом
<sarcasm> И всплывающие окна браузер не должен пытаться блокировать, и редиректы, и без вопросов любому сайту давать доступ к вебкамере и микрофону — а не пытаться что-то навязывать. </sarcasm>firk
05.11.2017 13:07Блокировка неавторизованной ПОЛЬЗОВАТЕЛЕМ активности — хорошее дело. Но решать, что блокировать а что нет, должен именно пользователь, а браузер может только дать ему ненавязчивый и отключаемый в настройках совет.
alix_ginger
05.11.2017 14:33Так браузер и не блокирует. Просто предупреждает, что соединение не зашифровано и поэтому на этом сайте не стоит вводить чувствительную информацию, больше ничего — пользоваться сайтом никак не мешает.
firk
05.11.2017 15:54В данном случае — не блокирует, да. Мой комментарий был ответом на ваш, а не на статью.
Что касается первого, который на статью — там возмутила фраза "нанести ущерб бизнесу — именно то, чего добивались разработчики браузеров!". Это совершенно не их функции.
VolCh
05.11.2017 18:01Не вправе. Производители браузеров не имеют никаких обязательств ни перед пользователями, ни перед, тем более, владельцами сайтов. Не нравится забота о безопасности пользователей — пользуйтесь браузерами, которые не заботятся. А как владелец сайта агитируйте других пользоваться такими браузерами.
bogolt
06.11.2017 22:53+1Компания вправе запретить заходить на свой сайт с указанных браузеров. Вот elinks предупреждения не показывает, пускай им заходят.
Если бы компании могли диктовать браузеру что он должен показывать и как, то блокировщики рекламы давно были бы запрещены, как и кастомный цсс и хм… отображение сайта не на том разрешении которое стоит у генерального.
badfiles
04.11.2017 12:13+6Вообще-то это свинство, у меня есть внутри компании ресурсы, которые не смотрят в интернет. Ещё есть сбербанк онлайн, который весь трафик на usb токене шифрует, а с пользователем взаимодействует через http на локальном порту.
Подобные сообщения просто не соответствуют действительности для таких ресурсов, и сбивает пользователей с толку, а сделать с этим (в случае сбербанка) вообще ничего нельзя.baldr
04.11.2017 13:02+10у меня есть внутри компании ресурсы, которые не смотрят в интернет
Это не значит что они сразу стали безопасными. Один сниффер внутри сети — и все.
Митник прав до сих пор.DrPass
05.11.2017 11:38Ну только этот сниффер должен стоять на сервере, т.е. без злонамеренных действий сисадмина не обойтись. Современные сети ведь коммутируемые, чужой трафик на все компьютеры не рассылается. Разве что, если в офисе компании многие работают через Wi-Fi, удастся воспользоваться какой-нибудь незакрытой дырой в WPA2.
А если это сисадмин, то против него https и так бессилен :)rPman
06.11.2017 16:04не обязательно сервер, бывают конфигурации, когда достаточно подменить dhcp и dns запросы (точнее вернуть их клиентам первыми) и вот уже вы сервер, и вообще что угодно.
FreeManOfPeace
04.11.2017 15:58+1Применить на уровне корпоративной политики следующий параметр в about:config,
security.insecure_field_warning.contextual.enabled;false
Vindicar
04.11.2017 16:09Сообщения — полбеды. Вот у меня фаерфокс упорно перенаправляет веб-интерфейс локального(!) сервиса на HTTPS, которым там и не пахнет. Как следствие, «не удалось установить соединение».
Отключить не удается. Приходится открывать через IE.fukkit
04.11.2017 17:03+2Тоже недавно столкнулся с этим поведением. Файрфокс для некоторых сайтов насильно переписывает схему http на https даже при её явном указании. Вроде бы это не HSTS, т.к. сайты «забыты», 443 порт заблокирован на роутере и заголовку прилететь неоткуда.
Причём схема переписывается скрытно, без запроса, без уведомления, тупой безусловный рерайт.
Разработчики упорно навязывают пользователям свои понятия о добре и зле, хорошим это не кончится.michael_vostrikov
04.11.2017 20:04О да, SSL-сертификаты восстанут и захватят мир. И никто не сможет расшифровать однажды зашифрованное.
egoroof
06.11.2017 15:31В браузерах есть свои списки сайтов, которые будут открываться только по https и для этого не нужно делать куда-то сетевой запрос. Пожалуйста hstspreload.org
VolCh
05.11.2017 18:05Внутри компании как раз можете спокойно выбирать каким браузером должны пользоваться пользователи.
Iz0om
06.11.2017 15:31советую почитать про zero-trust. защищать надо данные, а не «внутри / не внутри»
Bonio
04.11.2017 17:17+1Он объяснял, что из-за плохого кода на бэкенде сайт могут взломать даже при наличии SSL, но зелёный замочек остаётся, вводя пользователей в заблуждение, поэтому HTTPS бесполезен.
Глупость какая, причем тут это? SSL в первую очередь защищает данные от перехвата на пути до того самого бекенда, что стало особенно актуально в некоторых странах в последние годы.
Tallefer
04.11.2017 19:55+1А может кто-то объяснить этот кусок «SSL скорее помогает Google монополизировать видимость контента»? Понятно, что не стоит искать логики в таком, но все же интересно, какая связь? :)
Aquahawk
04.11.2017 20:15+3Никакой. Просто все привыкли, что если кто-то большой и сильный что-то навязывает, то скорее всего он хочет вас поиметь
Tallefer
04.11.2017 20:19Не так давно набрел на сайт
Форум как форум, нашлось много интересной мне инфы, но это не важно.
С самого начала поразило, что все ссылки там циркулируют исключительно как HTTP, таким образом, почти любой переход по форуму ведет к принудительному редиректу на нешифрованную версию. При этом сертификат там есть и даже работает, но, как видно по скрину, практически на каждой странице есть элементы, которые передаются по HTTP. И даже это не такая большая проблема — я просто включил HTTPS Everywhere (там этот форум кстати уже прописан!), позже переключился на встроенное в NoScript средство, но в таком строгом режиме отрубается большинство полезных скриптов, подгружающих контент, типа превьюшек постов, профилей и т.п., так как они там захардкодены на HTTP, судя по всему. %)
Я даже пошел в HTTPS Everywhere и уже почти завел там тикет, чтобы они исключения добавили, но потом передумал, ибо нефиг поощрять раздолбайство… :)
Так вот, у меня вопрос, стоит ли им туда постить тему с просьбой пофиксить это безобразие или то, что в поиске по форуму не нашлось ни одной темы с таким вопросом за годы, уже говорит о том, что всем пофиг и реакция будет как у контор из этой статьи? :)
foxyrus
04.11.2017 22:42+1Например, kinohod, достаточно крупный сайт по продаже билетов, вообще не использует https при оплате картой
скрин
alexhemp
04.11.2017 22:51+2Там iframe с адресом securepayments.sberbank.ru/payment/merchants/kinohod4/payment_ru.html
Так что данные карт на этот сайт не попадают, а только статус транзакции передает сбербанк
imanushin
05.11.2017 01:36То есть MITM всего-то надо подменить адрес iframe в оригинальной странице (она же по http передаётся).
Так что это отличный пример того, что разработчики в принципе не понимают ничего в безопасности.
blind_oracle
04.11.2017 23:07+3Не понимаю откуда такая истерика про введение HTTPS. Его сейчас настроить может любой школьник по гайдам, выписать сертификат на Letsencrypt и получить А+ в ssllabs.
Железо современное с AES NI и прочим позволяет практически бесплатно шифровать. А если выписать ECDSA сертификаты то и хендшейки станут почти бесплатными.
lexore
05.11.2017 01:06+1Проблема в том, что бекенд должен генерировать все ссылки правильно, или $scheme://site/path, или //path.
Плюс, весь подгружаемый контент с других ресурсов и ссылки на всякие рекламные пиксели должны быть с такой же схемой (http/https).
А у сайта с большим количествомпомета мамонтастарого кода, скорее всего, полно мест, которые надо переписать для такого поведения.
Захардкоженные ссылки с http — обычное дело.
Короче, работы там много.
В данном случае кто-то просто решил пойти по пути страуса, сунуть голову в песок и не делать эту работу.
Затея глупенькая, хотя бы потому, что скоро вообще все http ресурсы будут помечаться, как небезопасные.
fukkit
05.11.2017 02:25-1Знаете ли, тут мировоззренческая пропасть. Ходят слухи, что поколение X предпочитает свободу несвободе, простые вещи сложным, сетевой нейтралитет игре в кошки-мышки с большим братом, а у поколения Z
беспринципнаяпрагматичная геймификация: игнорируя количество и длину зондов, очередной квест из интернета выполнил, там где велено А+ получил, и к попкорну быстрее — понаблюдать «а что же дальше будет».
oisee
05.11.2017 10:11Давай заменим «поколения» на «знаки зодиака», чтобы смысла прибавилось? «Овны на этой неделе предпочтут свободу несвободе», «козероги будут прагматично геймифицировать».
Или ещё лучще на расы и национальности. (Это к вопросу о том, как скоро в данной ветке будет упомянут Гитлер.)
VolCh
05.11.2017 18:13Не всё так просто как хотелось бы. Например в случае динамически создаваемых доменов, недоступных извне корпоративной сети. Да и с доступными не сильно проще.
Goron_Dekar
06.11.2017 15:31Вот только к ежегодной проверке домена получаем ежегодную проверку сертификата. Стоимость поддержки сайта возрастает. Без очевидных для хозяина сайта бонусов.
blind_oracle
06.11.2017 22:35Что такое «проверка»? Не протух ли сертификат?
Я же не зря написал про Letsencrypt — настроил один раз и забыл.VolCh
07.11.2017 14:21Не во всех ситуациях можно легко настроить Letsencrypt на автоматическое обновление. Скажем, нужно будет настраивать чтобы перед запуском cертбота открывался файерволл для серверов Letsencrypt, прописывались dns, а после обновления всё возвращалось на круги своя. Плюс помнится при попытке настроить Letsencrypt на нескольких серваках на одно имя, балансирующихся по rr, тоже проблемы были. В общем он только для простейших случаев годится, когда есть сервачок с постоянным адресом, с постоянным именем, с рутовым доступом.
blind_oracle
07.11.2017 14:40-1Скажем, нужно будет настраивать чтобы перед запуском cертбота открывался файерволл для серверов Letsencrypt, прописывались dns, а после обновления всё возвращалось на круги своя
Зачем так сложно? Паранои ради? Даже если так, то всё без проблем делается через pre/post скрипты.
Плюс помнится при попытке настроить Letsencrypt на нескольких серваках на одно имя, балансирующихся по rr, тоже проблемы были
Никаких проблем — проксируй со всех фронт-серверов URL /.well-known на бэкенд занимающийся обновлением сертификатов. Этот бэкенд уже раскидает их по необходимым хостам.
В общем он только для простейших случаев годится, когда есть сервачок с постоянным адресом, с постоянным именем, с рутовым доступом
См. выше, это заблуждение. Можно сделать любую желаемую топологию, софта для ACME уже куча со всякими разными возможностями. Зачем рут — не очень понятно.VolCh
07.11.2017 14:53Это понятно, что можно сделать любую. Но это не "настроил один раз и забыл", а так же как любые автоматические операции "настроил, мониторишь, поддерживаешь, развиваешь, реагируешь"
Tallefer
04.11.2017 23:56Еще странная вещь, возбуждающая паранойю: последний месяц, а особенно — последнюю неделю, буквально каждый второй сайт (из новых и незнакомых, разумеется), который выдает гугл в поиске — либо не имеет хттпс версии, либо она сломана. Вроде бы гугл ранжирует такие сайты ниже, или я ошибаюсь? Опять же — не может ли это быть какими-то махинациями со стороны росгопнадзора? Ни у кого нет подобного опыта с серфингом?
yarkov
06.11.2017 13:15А вот трюк с CSS я пытался воспроизвести на одном проекте, чтобы отключить автозаполнение формы входа. И в ФФ это не работает.
logikv
07.11.2017 08:13http/2 и spdy не смогут работать без ssl
blind_oracle
07.11.2017 09:21SPDY уже умер, а HTTP/2 вполне себе работает и без SSL.
Тут скорее упорство браузеров, которые не хотят его без SSL использовать.
zar0ku1
Картинка про гидрант и пожарных — это для машин, поезд проедет по ней, разрежет шланг и даже не заметит эту хрень.
Эта картинка скорее в юмор надо, чем в факты =)
atomlib
На самом деле эта вирусная фотография — бельгийская шутка: тот участок железной дороги был временно закрыт. В реальной ситуации рукав действительно порвётся.
Graf54r
? т.е. а первый способ электропроводки вас устраивает?