Pull to refresh

Comments 44

UFO just landed and posted this here
Mozilla тоже планомерно урезает возможности сайтов, открываемых по незащищённому HTTP.
войну с http давно нужно было затеять. Захочешь через wifi на сайта по http, а там скрипт встроенный в страницу, который ворует куки со всех сайтов которые работают по http. Многие думаю, что для «бложиков» https не нужен и они в корне не правы. Любой сайт по http на который вы зашли не через wifi, это потенциально выполненный у вас в браузере скрипт, оно вам надо?
UFO just landed and posted this here

Оратор выше имел ввиду левые скрипты, передаваемые пользователю человеком или машиной между пользователем и сервером, но в целом с замечанием согласен

Речь видимо про то, что на WiFi arp spoofing не канает.

Как будто кто-то ещё пользуется публичным вайфаем без впн.

Войну надо не с http затевать, а с теми, кто модифицирует трафик. У нас вообще есть какая-то вроде даже статья в духе "… внесение проблем в средства коммуникации..." — почему бы (в идеале) её на практике не использовать?

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

Самое неприятное, что гугл уже начал лезть переопределять поведение стандартного протокола. Показать, что «сайт не безопасный» — ладно, ок, это личное дело каждого браузера, в общем-то. Переопределять поведение стандартного протокола (на куки, между прочим, в многих старых системах авторизация завязана) — вот это уже вредительство, похожее на то, что Майкрософт делало во времена господства ИЕ, когда неподдержка стандарта мотивировалась «удобством пользователя». Теперь вместо «удобства» — «безопасность»
Войну надо не с http затевать, а с теми, кто модифицирует трафик.

Эту войну уже не выиграть. Опасна не только модификация, но и прослушивание. Шифрование всего трафика в сети это логичный шаг на пути эволюции интернета и не стоит, наверное, этому противиться.
Другое дело, что такие вещи, как назойливые сообщения и органичения при работе с http, должны именть возможность отключатсья. Как минимум внутри корпоративной сети https не всегда нужен и подобное поведение браузеров может быть раздражающим.
UFO just landed and posted this here
Но не ценой умышленного нарушения стандарта.
Вы описали проблему не http, а проблему халявного wifi к которому подрубаетесь.
UFO just landed and posted this here
Году к 2020 сделаеют http нерабочим, а потом вдруг letsencrypt внезатно станет платным…

Сертификаты всю жизнь были платными, причём обычно дешевле хостинга. Я сейчас и у кого-то вроде PositiveSSL / RapidSSL видел бесплатные сертификаты на 3 месяца, можно выпустить самоподписанный (какая разница, на что ругаться браузеру — каждый раз на HTTP или один раз на недоверенный SSL)…
Или можно найти из расчета 200 рублей в год на трёхлетний сертификат.

Да только туже самую всю жизнь браузеры спокойно относились к HTTP. Сейчас HTTP выживают, и оставляют только HTTPS. Когда его выживут окончательно, цены на сертификаты могут изменится, да и условия их использования тоже могут изменится как угодно. Поэтому то что сейчас 200 рублей в год, может оказаться 2000 в год, а может случится так что вам его вообще не выдадут. Это всё конечно слишком негативные варианты развития событий, но где гарантия что такого не случится.
Еще один шаг к контролю. Цель — возможность неконкурентной борьбы через блокирование неугодных.
Под фанфары «за безопасность», конечно…
UFO just landed and posted this here
> сейчас все идет к тому что в обозримом будущем мы сайты на localhost будем отлаживать платя дяде за то чтобы на localhost его пустить.

Где-то такое уже было, и называлось это ngrok.com
Уже потихонечку внедряют — www.techdirt.com/articles/20180506/13013839781/more-copyright-holders-move-up-stack-more-they-put-everyone-risk.shtml — Comodo заставили отозвать сертификат SciHub'а (не потому что он скомпроментирован или так далее а потому что кто-то решил имеет право вот так типа интеллектуальную собственность защищать, то что процедура отзыва немного для других целей предназначена — а плевать).
UFO just landed and posted this here
Мне эта фраза понравилась:
Они убеждены, что так будет сложнее отследить действия пользователей в интернете на разных сайтах.
Я недавно гуглил моторные масла, а потом в одной игрушке Амазон предложил мне его купить. Я бы сказал, что ничего сложного — отследили ведь.

Создайте свой собственный CA, установите корневой сертификат на все машины в сети (через AD или ещё как) и выдавайте какие угодно сертификаты чему угодно.

Не (везде) поможет. Certificate pinning на андроид + в новых версиях андроида специально нужно в приложении прописать доверие не-системным сертификатам.
В других местах могут быть вообще произвольные глюки (в SecondLife например — сбой телепорта с предложением проверить часы).
Ну я исходил из предположения что мы выпускаем сертификаты для своих сайтов в интранете, а не для гугла, например :) Поэтому certificate pining нам не помешает.

А вот с андроидом беда, конечно. Кстати, а вы не знаете, может можно поставить свой сертификат через поддержку корпоративных аккаунтов? Или там тоже нельзя?
Ну зачем гуглу конкуренты в деле отслеживания действий пользователя?
А гугл не хочет нам рассказать, как получить SSL сертификат на сайт в интранете, причём этот интранет никак не контачит с внешним миром?

Конечно, может. Гуглите любую статью про генерацию сертификатов. Просто не выполняйте ту её часть, которая касается процедуры подписывания сертификата центром авторизации. Это для еденичного сайта. А если у вас в интранете целая система развёрнута, то придётся прочитать ещё как сгенерировать сертификат, которым потом будете подписывать сертификаты прочих сайтов. Ну, и потом на клиентах просто добавляете или сертификат сайта в первом случае, либо тот сертификат, которым вы подписывали прочие. Там ничего сложного нет.

Регистрируйте обычный домен, который будет резолвиться только в вашем интранете, на домен регистрируйте сертификат. У нас примерно так сделано.
Иначе придётся в каждой клиенте, на каждом устройстве придётся прописывать доверенные сертификаты.

Сек, я из статьи следует, что если время жизни куки, при установке, больше порога, то она вообще не установится? не очень тогда понятно, как с этим согласуется заявление об обратной совместимости. Вообще много необоснованного форса ssl, например, webcrypto api, недоступен в несекурных протоколах, в том числе, такие простые вещи как хэши (приходится использовать алгоритмы без потенциального аппаратного ускорения). Всё это движение в сторону ssl конечно полезно, но мне кажется, что в последнее время, гугл лезет не в свою зону ответственности, нарушая принципы сетевого нейтралитета.

Я, конечно, против SSL-насилия и позиции Гугла по вопросам отслеживания, но куки старше года, что по HTTP, что нет — это ж дыра похлеще многих.
Данная конкретная инициатива пользователю на пользу.
Что мешает серверу обновлять необходимые куки при каждом визите или каждые полгода — не ясно.
3. Отказаться от cookies как идентификаторов и использовать вместо них localStorage.

Вот этого не нужно, на скрипты завязываться — абсолютное зло.
Визиты раз в год, например, причём не строго, а плюс-минус несколько дней, а то и месяцев. Сервисы поздравлений или подарков, например. Сервисы бронирования отелей, ресторанов и т. п. Сервисы подготовки годовых деклараций или отчётов. Куча всего бывает нужна с периодичностью около года.
Мне кажется, не случится с Вами большой беды, если раз в год авторизуетесь на таком сервисе по паролю вместо кук.
Для патологических лентяев, конечно же, могли б сделать эту фичу отключаемой в настройках.
В лисе, надеюсь, так и будет, хрому в плане приватности уже ничто не поможет.
Скорее всего придётся проходить процедуру восстановления пароля, а не просто авторизоваться. Плюс куки используются не только для авторизации, а, например, для сохранения настроек.
Тех, кто хранит в куках настройки вместо сессии, следует пороть ремнём и в 7й класс не переводить.
Сессии нарушают принципы REST в общем случае.
UFO just landed and posted this here
предлагете не мыть всю еду и не подвергать тепловой обработке определенные типы еды?
Вы подвергаете тепловой обработке фрукты, ягоды, зелень и т. п.? Моете молоко и сметану?

99.5% молока — стерелизованное/пастеризованное — с тепловой обработкой и производители у вас не спрашивали делать ли им её — так тупо выгоднее и безопаснее. Зелень и фрукты/ягоды — я мою из-за того, что нельзя гарантировать что она читая. Ну пожалуй за исключением готовых нарезанных салатов которые идут с пометкой «уже помыто/не надо мыть»

Sign up to leave a comment.