Однако на этом работа ИТ-гиганта с HTTP не закончилась. В прошлом месяце стало известно, что Google дополнительно уменьшит «время жизни» cookies, полученных с применением незащищенного протокола, до одного года. Подробнее о ситуации расскажем далее.
/ Flickr / Jeff Herbst / PD
Отправка cookies по HTTP в Google называют риском безопасности. Представители компании отмечают, что «cookie-долгожители» позволяют проводить атаку, получившую название «всеобъемлющий мониторинг» (Pervasive Monitoring). Это масштабное (и часто скрытое) отслеживание передаваемой информации путем сбора артефактов протокола, метаданных (например, заголовков) и данных приложений. Примером ситуации, в которой был замешан этот тип мониторинга, может быть история, когда NSA использовало PREF cookie для слежения за пользователями сети.
Google заявляют, что от подобного типа атак защищает HTTPS. Но так как на более защищенный протокол перешли не все (лишь 81 из 100 сайтов используют HTTPS по умолчанию), исследователи решили пойти дальше и уменьшить время жизни cookies.
Согласно данным телеметрии Google, cookie, полученные по HTTP, «живут» больше года. Разработчики Chrome планируют ограничить время жизни cookie. И сделать это постепенно: сперва сократить до одного года, потом — до нескольких дней. Они убеждены, что так будет сложнее отследить действия пользователей в интернете на разных сайтах.
Это изменение реализуют в обновлении Chrome 70, которое выйдет в конце октября 2018 года.
Суть предложения
Инженеры Google предлагают изменить формат передачи cookie следующим образом.
При формировании заголовка для исходящего запроса на незащищенный URL, сперва будет проверяться дата создания каждого cookie. Если «возраст» больше некоторого порогового значения (12 месяцев, а позднее — несколько дней), то cookie не добавляется в заголовок, а удаляется. Также предлагается изменить алгоритм установки времени создания cookie. Если содержимое осталось прежним, то время создания нового cookie согласуется со временем создания старого.
Как это скажется на работе веб-сервисов?
По заверениям разработчиков, проблем с обратной совместимостью возникнуть не должно. Однако это может сказаться на работе сервисов, использующих незащищенные долговременные cookies. Поэтому в Google предлагают рассмотреть следующие варианты:
- Все же перейти на HTTPS.
- Внедрить систему, похожую на ротацию ID в DoubleClick, значение которых повторно шифруется и обновляется каждый день. Это решение подойдет для тех, кто по каким-то причинам не может перейти на HTTPS.
- Отказаться от cookies как идентификаторов и использовать вместо них localStorage.
/ Flickr / Joi Ito / CC
А что с другими браузерами?
Разработчики других браузеров также пытались внедрить что-то подобное. Например, 2 года назад представители Mozilla предлагали превратить некоторые cookie браузера Firefox в сеансовые (1 и 2), но от этого предложения отказались.
Идея была в том, чтобы устанавливать cookies на сессию, если они не имели флага secure. Однако тестирование инициативы показало, что слишком малое число сайтов выставляют этот флаг. Даже сайты, которые используют HTTPS (в том числе google.com), пренебрегали этим.
Что касается предложения Google, то в компании надеются, что их решение сократить время жизни cookie подтолкнет сообщество к тому, чтобы сделать HTTPS «стандартом» в веб-среде.
О чем еще мы пишем в корпоративном блоге 1cloud:
Комментарии (44)
linuxover
12.05.2018 20:58автору: все ссылки раздела
О чем еще мы пишем в корпоративном блоге 1cloud:
поломаны, там пробелы надо поубирать. поправьте плз
VBKesha
12.05.2018 21:38+8Году к 2020 сделаеют http нерабочим, а потом вдруг letsencrypt внезатно станет платным…
BaRoN
13.05.2018 09:30Сертификаты всю жизнь были платными, причём обычно дешевле хостинга. Я сейчас и у кого-то вроде PositiveSSL / RapidSSL видел бесплатные сертификаты на 3 месяца, можно выпустить самоподписанный (какая разница, на что ругаться браузеру — каждый раз на HTTP или один раз на недоверенный SSL)…
Или можно найти из расчета 200 рублей в год на трёхлетний сертификат.VBKesha
13.05.2018 11:13+1Да только туже самую всю жизнь браузеры спокойно относились к HTTP. Сейчас HTTP выживают, и оставляют только HTTPS. Когда его выживут окончательно, цены на сертификаты могут изменится, да и условия их использования тоже могут изменится как угодно. Поэтому то что сейчас 200 рублей в год, может оказаться 2000 в год, а может случится так что вам его вообще не выдадут. Это всё конечно слишком негативные варианты развития событий, но где гарантия что такого не случится.
zhka
12.05.2018 21:40+6Еще один шаг к контролю. Цель — возможность неконкурентной борьбы через блокирование неугодных.
Под фанфары «за безопасность», конечно…linuxover
12.05.2018 21:45-3дык все вот это обоснование «изображение из картинок скриптов» — это все не обоснование перехода на https. На https так же можно картинкой скрипт/html изобразить.
единственное что является обоснованием — возможность снифа авторизации. Да. но и только.
почему мне нельзя разместить картинку в http и вставить ее в https? вообще не понимаю.
давайте сделайте полиси, что браузер передает куки на вставляемые объекты (картинки, фонты) только по своему протоколу. Зачем резать возможность вставить картинку/сделать ajax запрос? сделали же опцию кукам http only? почему еще одну не запилить?
сейчас все идет к тому что в обозримом будущем мы сайты на localhost будем отлаживать платя дяде за то чтобы на localhost его пустить. Как вот чтобы поставить приложение на айфон товарищу — надо с дядей за океаном согласовать.
vikarti
13.05.2018 08:41+2Уже потихонечку внедряют — www.techdirt.com/articles/20180506/13013839781/more-copyright-holders-move-up-stack-more-they-put-everyone-risk.shtml — Comodo заставили отозвать сертификат SciHub'а (не потому что он скомпроментирован или так далее а потому что кто-то решил имеет право вот так типа интеллектуальную собственность защищать, то что процедура отзыва немного для других целей предназначена — а плевать).
OnYourLips
13.05.2018 20:29+1А я за такую борьбу. Это борьба между пользователями и веб-разработчиками, и Google выбрал сторону пользователей.
До сих пор из 20 основных закладок в моем браузере три не работают по https (это хоббийные форумы не IT тематики). Я бы очень сильно хотел, чтобы им пришлось использовать https, мне как пользователю это очень выгодно.
Vest
12.05.2018 22:07+2Мне эта фраза понравилась:
Они убеждены, что так будет сложнее отследить действия пользователей в интернете на разных сайтах.
Я недавно гуглил моторные масла, а потом в одной игрушке Амазон предложил мне его купить. Я бы сказал, что ничего сложного — отследили ведь.lorc
13.05.2018 02:42Создайте свой собственный CA, установите корневой сертификат на все машины в сети (через AD или ещё как) и выдавайте какие угодно сертификаты чему угодно.
vikarti
13.05.2018 08:43Не (везде) поможет. Certificate pinning на андроид + в новых версиях андроида специально нужно в приложении прописать доверие не-системным сертификатам.
В других местах могут быть вообще произвольные глюки (в SecondLife например — сбой телепорта с предложением проверить часы).lorc
13.05.2018 19:45Ну я исходил из предположения что мы выпускаем сертификаты для своих сайтов в интранете, а не для гугла, например :) Поэтому certificate pining нам не помешает.
А вот с андроидом беда, конечно. Кстати, а вы не знаете, может можно поставить свой сертификат через поддержку корпоративных аккаунтов? Или там тоже нельзя?
Barafu_Albino_Cheetah
13.05.2018 01:17А гугл не хочет нам рассказать, как получить SSL сертификат на сайт в интранете, причём этот интранет никак не контачит с внешним миром?
avost
13.05.2018 01:32+4Конечно, может. Гуглите любую статью про генерацию сертификатов. Просто не выполняйте ту её часть, которая касается процедуры подписывания сертификата центром авторизации. Это для еденичного сайта. А если у вас в интранете целая система развёрнута, то придётся прочитать ещё как сгенерировать сертификат, которым потом будете подписывать сертификаты прочих сайтов. Ну, и потом на клиентах просто добавляете или сертификат сайта в первом случае, либо тот сертификат, которым вы подписывали прочие. Там ничего сложного нет.
Goodkat
13.05.2018 11:38+1Регистрируйте обычный домен, который будет резолвиться только в вашем интранете, на домен регистрируйте сертификат. У нас примерно так сделано.
Иначе придётся в каждой клиенте, на каждом устройстве придётся прописывать доверенные сертификаты.
Opaspap
13.05.2018 08:58+1Сек, я из статьи следует, что если время жизни куки, при установке, больше порога, то она вообще не установится? не очень тогда понятно, как с этим согласуется заявление об обратной совместимости. Вообще много необоснованного форса ssl, например, webcrypto api, недоступен в несекурных протоколах, в том числе, такие простые вещи как хэши (приходится использовать алгоритмы без потенциального аппаратного ускорения). Всё это движение в сторону ssl конечно полезно, но мне кажется, что в последнее время, гугл лезет не в свою зону ответственности, нарушая принципы сетевого нейтралитета.
fukkit
13.05.2018 14:39+1Я, конечно, против SSL-насилия и позиции Гугла по вопросам отслеживания, но куки старше года, что по HTTP, что нет — это ж дыра похлеще многих.
Данная конкретная инициатива пользователю на пользу.
Что мешает серверу обновлять необходимые куки при каждом визите или каждые полгода — не ясно.
3. Отказаться от cookies как идентификаторов и использовать вместо них localStorage.
Вот этого не нужно, на скрипты завязываться — абсолютное зло.VolCh
13.05.2018 15:01Визиты раз в год, например, причём не строго, а плюс-минус несколько дней, а то и месяцев. Сервисы поздравлений или подарков, например. Сервисы бронирования отелей, ресторанов и т. п. Сервисы подготовки годовых деклараций или отчётов. Куча всего бывает нужна с периодичностью около года.
fukkit
13.05.2018 15:21Мне кажется, не случится с Вами большой беды, если раз в год авторизуетесь на таком сервисе по паролю вместо кук.
Для патологических лентяев, конечно же, могли б сделать эту фичу отключаемой в настройках.
В лисе, надеюсь, так и будет, хрому в плане приватности уже ничто не поможет.VolCh
14.05.2018 06:08-1Скорее всего придётся проходить процедуру восстановления пароля, а не просто авторизоваться. Плюс куки используются не только для авторизации, а, например, для сохранения настроек.
shifttstas
13.05.2018 22:57+1что плохого в SSL?
linuxover
13.05.2018 23:07-2нет ничего плохого в еде.
но если пихать в человека еду насильно (мотивируя это тем, что кто-то когда-то мог бы его отравить), то он может умереть. во всяком случае сопротивление процессу будет закономерным.shifttstas
13.05.2018 23:08+1предлагете не мыть всю еду и не подвергать тепловой обработке определенные типы еды?
VolCh
14.05.2018 06:05-1Вы подвергаете тепловой обработке фрукты, ягоды, зелень и т. п.? Моете молоко и сметану?
shifttstas
14.05.2018 10:25+199.5% молока — стерелизованное/пастеризованное — с тепловой обработкой и производители у вас не спрашивали делать ли им её — так тупо выгоднее и безопаснее. Зелень и фрукты/ягоды — я мою из-за того, что нельзя гарантировать что она читая. Ну пожалуй за исключением готовых нарезанных салатов которые идут с пометкой «уже помыто/не надо мыть»
linuxover
этот гугл только жизнь людям портить умеет:
то взял текстовый http/1.x превратил в блобовый версии 2 (это ж чисто вражеское поведение, технически необоснованное),
то войну с http затеивает
итп
враги, одно слово ;)
dartraiden
Mozilla тоже планомерно урезает возможности сайтов, открываемых по незащищённому HTTP.
interprise
войну с http давно нужно было затеять. Захочешь через wifi на сайта по http, а там скрипт встроенный в страницу, который ворует куки со всех сайтов которые работают по http. Многие думаю, что для «бложиков» https не нужен и они в корне не правы. Любой сайт по http на который вы зашли не через wifi, это потенциально выполненный у вас в браузере скрипт, оно вам надо?
linuxover
сейчас сайтов без скриптов почти не осталось. как переход на https уменьшает количество скриптов — не понимаю
x67
Оратор выше имел ввиду левые скрипты, передаваемые пользователю человеком или машиной между пользователем и сервером, но в целом с замечанием согласен
xcyberx
Речь видимо про то, что на WiFi arp spoofing не канает.
Goodkat
Как будто кто-то ещё пользуется публичным вайфаем без впн.
SanekPlus
Здрасти
janvarev
Войну надо не с http затевать, а с теми, кто модифицирует трафик. У нас вообще есть какая-то вроде даже статья в духе "… внесение проблем в средства коммуникации..." — почему бы (в идеале) её на практике не использовать?
А так вы боретесь скорее с обычными веб-мастерами — не теми, кто поддерживает крупные проекты, им как раз всё равно — а теми, кто занимается своим делом по-любительски, всякие локальные некоммерческие форумы поддерживает. Для них любое новое инфраструктурное дело — лишняя нагрузка, и, в общем-то, дополнительное желание бросить поддержание бесплатного ресурса.
Самое неприятное, что гугл уже начал лезть переопределять поведение стандартного протокола. Показать, что «сайт не безопасный» — ладно, ок, это личное дело каждого браузера, в общем-то. Переопределять поведение стандартного протокола (на куки, между прочим, в многих старых системах авторизация завязана) — вот это уже вредительство, похожее на то, что Майкрософт делало во времена господства ИЕ, когда неподдержка стандарта мотивировалась «удобством пользователя». Теперь вместо «удобства» — «безопасность»
Bonio
Эту войну уже не выиграть. Опасна не только модификация, но и прослушивание. Шифрование всего трафика в сети это логичный шаг на пути эволюции интернета и не стоит, наверное, этому противиться.
Другое дело, что такие вещи, как назойливые сообщения и органичения при работе с http, должны именть возможность отключатсья. Как минимум внутри корпоративной сети https не всегда нужен и подобное поведение браузеров может быть раздражающим.
linuxover
кстати вот еще что
например был (есть но уже сейчас можно говорить что был) такой прекрасный проект вырезания рекламы из http-трафика — privoxy и аналоги. Так же прозрачные прокси, позволявшие большим сетям экономить трафик и получать бОльшую скорость, антивирусы интегрировались с прозрачными прокси, и так далее
теперь из за чьей-то прихоти все эти прекрасные проекты придется или радикально переделывать в пользу уменьшения юзабилити или даже выкидывать на помойку.
при этом что дало шифрование среднему клиенту? ничего. я набрал в поиске "видеорегистратор" 4 месяца назад, купил его. Уже езжу с ним 4 месяца и мне теперь и почтовики и соцсети и прочие — всё долбают этими регистраторами. при том что они все используют шифрование.
Goron_Dekar
Но не ценой умышленного нарушения стандарта.
ZurgInq
Вы описали проблему не http, а проблему халявного wifi к которому подрубаетесь.
SagePtr
Мобильные операторы иногда грешат этим. И проводные тоже.