Почему Google уменьшает «время жизни» cookies, полученных с помощью HTTP

    Еще в начале года в компании Google сообщили, что с июля (когда выходит Chrome 68) все сайты, использующие HTTP, будут помечаться как небезопасные. В компании считают, что это позволит повысить конфиденциальность пользователей в сети.

    Однако на этом работа ИТ-гиганта с 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 предлагают рассмотреть следующие варианты:

    1. Все же перейти на HTTPS.
    2. Внедрить систему, похожую на ротацию ID в DoubleClick, значение которых повторно шифруется и обновляется каждый день. Это решение подойдет для тех, кто по каким-то причинам не может перейти на HTTPS.
    3. Отказаться от cookies как идентификаторов и использовать вместо них localStorage.


    / Flickr / Joi Ito / CC

    А что с другими браузерами?


    Разработчики других браузеров также пытались внедрить что-то подобное. Например, 2 года назад представители Mozilla предлагали превратить некоторые cookie браузера Firefox в сеансовые (1 и 2), но от этого предложения отказались.

    Идея была в том, чтобы устанавливать cookies на сессию, если они не имели флага secure. Однако тестирование инициативы показало, что слишком малое число сайтов выставляют этот флаг. Даже сайты, которые используют HTTPS (в том числе google.com), пренебрегали этим.

    Что касается предложения Google, то в компании надеются, что их решение сократить время жизни cookie подтолкнет сообщество к тому, чтобы сделать HTTPS «стандартом» в веб-среде.

    О чем еще мы пишем в корпоративном блоге 1cloud:

    1cloud.ru
    172.71
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Share post

    Comments 44

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

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

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

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

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

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

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

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

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

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

                          Где-то такое уже было, и называлось это ngrok.com
                          +4
                          Уже потихонечку внедряют — www.techdirt.com/articles/20180506/13013839781/more-copyright-holders-move-up-stack-more-they-put-everyone-risk.shtml — Comodo заставили отозвать сертификат SciHub'а (не потому что он скомпроментирован или так далее а потому что кто-то решил имеет право вот так типа интеллектуальную собственность защищать, то что процедура отзыва немного для других целей предназначена — а плевать).
                            +1
                            А я за такую борьбу. Это борьба между пользователями и веб-разработчиками, и Google выбрал сторону пользователей.

                            До сих пор из 20 основных закладок в моем браузере три не работают по https (это хоббийные форумы не IT тематики). Я бы очень сильно хотел, чтобы им пришлось использовать https, мне как пользователю это очень выгодно.
                            +2
                            Мне эта фраза понравилась:
                            Они убеждены, что так будет сложнее отследить действия пользователей в интернете на разных сайтах.
                            Я недавно гуглил моторные масла, а потом в одной игрушке Амазон предложил мне его купить. Я бы сказал, что ничего сложного — отследили ведь.
                              0

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

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

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

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

                                    +1

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

                                    +1

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

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

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

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

                                        Only users with full accounts can post comments. Log in, please.