Comments 64
Отправлять экран тэгов вместо одного img и создавать 25 разных картинок вместо одной?
Сливать данные о размере окна браузера (которые нередко довольно уникальны и сильно упрощают идентификацию пользователя) и сетевом подключении уже не только через JS, не только через CSS, но и прям добровольно заголовками?
Так себе прогресс, как на мой взгляд… это скорее демонстрация того, что мы где-то по дороге свернули не туда, куда надо было.
Всё для удобства пользователя. А слежка за ним неотъемлемая часть веба с первого его дня, наверное. Ну как логи стали писать. Проблема не в слежке как таковой, а в людях, которые её результаты используют, а использовать их можно по разному.
Всё для удобства пользователя.
Ой ли? Если б было «для удобства пользователя», то почему бы, не обнаружив у пользователя хоть сколько-нибудь приличную систему (не смартфончик 15-летней давности) просто отгрузить ему клиентского JS, который будет работать у него максимально автономно, снижая нагрузку на сеть?
Но почему-то любители создать 25 разных картинок и подгонять их под экранчик пользователя, размер которого они только что узнали и запомнили — никогда так не делают. И видится мне, не делают именно потому, что девиз «для удобства пользователя» никогда не имеет никакого отношения к реальности. Для удобства разработки? Вероятно. Для удобства конторы? Очень возможно. Для удобства пользователя? Вы о чем вообще?
и HSTS
А можно внятно ответить чем это лучше редиректа с http на https?
Из минусов HSTS на своей шкуре почувствовал — сайт не будет доступен для тех кто его открывал, пока не наладишь SSL, «если что то пошло не так»
Т.е. тупо нет «запасного варианта» И пофиг, что SSL по факту нужен на одной страничке.
чем это лучше редиректа с http на https?
MitM перехватит запрос и порежет редирект — клиент так и останется сидеть на http. Именно поэтому нужен не просто HSTS, а именно preload, чтобы даже самый первый запрос от клиента пошёл по https и MitM не смог ничего порезать
С другой стороны все эти всплывашки в браузере на полях ввода. Хотя кто то может не обновляться, да. (секта мля)
PS. И кстати меня удивило, что HSTS это запоминание ЕСЛИ УЖЕ был по https. Т.е. редирект все равно нужен. А если нужен редирект и делает тоже самое, то зачем нужен HSTS.
Это собственно логическая цепочка которая привела к изначальному вопросу.
PSS. а именно preload не очень понял при чем тут это. Ты первый раз заходишь по http… Тут надо типа плага addons.mozilla.org/ru/firefox/addon/https-everywhere который НАВЕРНОЕ тычет в 443 порт если пытаешься по 80 войти.
И пофиг, что SSL по факту нужен на одной страничке.
SSL обязан быть на ВСЁМ сайте, иначе защиты никакой не получится, MitM без проблем порежет редирект для этой одной странички. Кроме того, сертификаты сейчас бесплатные — какой вообще смысл не использовать https в 2019 году?
пока не наладишь SSL
Дык надо в первую очередь наладить SSL, несколько недель/месяцев попроверять, что всё нормально работает, и только потом включать HSTS. Если вы делали наоборот, то ССЗБ
А потом выясняется (через 3 месяца или сколько там сейчас) что забыл прописать PATH в кроне для certbot или еще что нибудь. Но ведь «всё нормально работает», да?
certbot в норме запускается два раза в день, и «No renewals were attempted» в логах потрудится прочитать любой ответственный админ. Если не прочитал — что ж, опять ССЗБ.
Я себе вообще уведомления на почту прикрутил. Так и флудит, что ни один сертификат не обновлён
А если прочитал, но при обнове конфликты доменов и прочая ересь (с многозначительным digest does not match от LE)?
Сейчас то уже знаю что пуляй --dry-run если есть сомнения, но изначально где об этом сказано?
> Так и флудит, что ни один сертификат не обновлён
И какой смысл от таких уведомлений? В один прекрасный момент Вы удалите реальную проблему )
Опция --dry-run выдаётся первой ссылкой по запросу в гугле "how to test letsencrypt config". Так что если админ захочет проверить работоспособность — он найдёт, как это сделать, и проверит. А если его нужно постоянно тыкать носиком в "сделай то" и "проверь это" — что ж это за админ такой?
А как поисковиком пользоваться я знаю, сам учу.
Ну вот и отлично, гуглить — очень полезный навык не только для админа, но и вообще для любого человека!
У меня сейчас под котролем certbot'ы на четырёх разных серверах на несколько десятков доменов в течение трёх лет, с самого выхода Let's Encrypt из беты — и ни один из них никогда не сбоил.
> на несколько десятков
Ну ваще крут. А бывало такое что у тебя центос и поддомены в одном файле? )
И сертбот корёжит ssl составляющую?
PS. «Как» гуглить не наука. Важно «ЧТО» гуглить.
У меня как бы тоже поддомены в одном файле. Если у всех не корёжит, а у вас корёжит — подозреваю, дело вовсе не в сертботе.
Как это не в нем если он корежит? Т.е. если ты сейчас пизданешь в какой нибудь америке что черный это нигер — это преступление, а если мой конфиг «не правильный», то виноват не тот кто ударил чтоли? )
Баг явно в нем, но я свой конфиг поправил.
ЗЫ. И да, проблемы выявились не сразу.
Но вы так и продолжите играть в секретики и не расскажете, что за баг? И почему у меня его нет?
Возвращаясь к теме ошибок — опять же, крон шлёт на почту сообщения об ошибках. Если спустя три месяца админ забивает болт на почту и таким образом не узнаёт, что сертификаты не обновились — увольнять его незамедлительно.
Да не помню я подробности. Давно уже центос не обслуживаю. Замшелое г… пахнущее нафталином.
Там фишка в том что сертбот создает временный конфиг и включает его в текущий для проверки LE.
И там замут с регекспами (nginx конфиги), в итоге включался не туда и с вырезанными поддоменами. Хз может починили давно, но запомнилось (потому что пришлось разбираться).
В итоге переделал на webroot просто
> Если спустя три месяца админ забивает болт
Если настраивать уведомления как Вы — он так и сделает.
(nginx конфиги)
А, ну так nginx-конфиги в certbot всегда были нестабильными. Как ответственный админ (несмотря на то, что я вообще не админ) я следую принципу KISS, не доверяю всем этим «умным» конфигураторам (и вообще не переношу, когда что-то не под моим контролем), использую только certonly и пишу/генерирую плейбуком конфиги сам. Как я уже говорил выше, три года — полёт нормальный.
давно
Ну так «давно» nginx-конфиги были в бете. Если вы потащили бету на продакшен — вы опять ССЗБ.
Увы, пока по вашим комментам получается, что вы забили болт на все best practices ¯\_(ツ)_/¯
Раньше «подозреваю, дело вовсе не в сертботе», сейчас «А, ну так nginx-конфиги в certbot всегда были нестабильными.» — прогресс на лицо )
Да не было никакого продакшена
Ну тогда отлично. Значит вы как ответственный админ можете протестировать всё заранее, наткнуться на все значимые баги сертбота (если они есть) и собрать рабочую конфигурацию, и с обсуждавшимся в начале ветки включением HSTS никаких проблем не будет.
В конце концов, никто не запрещает подождать, пока certbot успешно обновит сертификаты хотя бы один раз, и только после этого включать HSTS. Если админ не забьёт болт, конечно.
И они даже могут уведомить. Но админ не прочитает.
Да, я тоже «верю» что этого не произойдет, но на всякий случай HSTS не включаю иногда…
PS. А как мы выяснили ранее, HSTS абсолютно бесполезен, если траффик изначально прослушивается/подменяется.
Кажется, в комментах выше я уже писал про админа, не читающего почту? Вы правда думаете, что изменения обязательно произойдут ВНЕЗАПНО, без нескольких предупреждений лично каждому админу за несколько месяцев/лет до поломки совместимости?
Да что далеко ходить.
habr.com/ru/post/451220
Дык это у Mozilla те самые безответственные админы, которых нужно незамедлительно уволить. Во-первых, подобные баги лечатся своевременными обновлениями и адекватным мониторингом, а во-вторых, это вообще никак не относится к Let's Encrypt. Ходите чуть дальше.
Дык это у Mozilla те самые безответственные админы
Ты в каком то идеальном мире живешь. Если ДАЖЕ у мозиллы есть такие админы, почему ты думаешь что не те же самые админы админять letsencrypt?
PS. Мозиловский реестр сертификатов считается самым доверенным BTW
Если бы мы жили в идеальном мире, то не существовало бы ни бэкапов, ни мониторинга.
И вновь мы возвращаемся к тому, что уже обсудили выше:
крон шлёт на почту сообщения об ошибках. Если спустя три месяца админ забивает болт на почту и таким образом не узнаёт, что сертификаты не обновились — увольнять его незамедлительно.
Если админ Let's Encrypt накосячит — вы об этом обязательно узнаете, потому что ваш мониторинг вас об этом уведомит. Если не уведомит — вас надо уволить.
Если вы хотите поиграть в конченого параноика и боитесь, что крон тоже ни о чём не уведомит, никто не мешает накатать какой-нибудь Python-скрипт, который раз в сутки будет проверять сроки годности сертификатов и уведомлять хоть на почту, хоть в телеграм, хоть в корпоративный Slack/Mattermost-чат. Было бы желание.
Пока вы лишь продолжаете строить из себя такого же безответственного админа, как админы мозиллы.
PS. А как мы выяснили ранее, HSTS абсолютно бесполезен, если траффик изначально прослушивается/подменяется.
Перечитайте пост ещё раз, особенно в тех местах, где упоминается слово «preload».
Пока вы лишь продолжаете строить из себя такого же безответственного админа, как админы мозиллы.
Всего лишь пытаюсь вернуть вас к реальности ;)
Перечитайте пост ещё раз, особенно в тех местах, где упоминается слово «preload».
preload нихрена не даст. Запрос уже ушел на 80 порт и ответ уже подменен )
Всего лишь пытаюсь вернуть вас к реальности ;)
Пока вы лишь строите из себя админа в манямирке без мониторинга.
preload нихрена не даст.
Перечитайте ещё раз.
Я даже процитирую ту часть, которую нужно перечитать:
Если вы хотите сделать всё возможное, чтобы браузер никогда не запрашивал ваш сайт по HTTP, можете также задать указатель preload и отправить ваш сайт в глобальный список. Если конфигурация HSTS вашего сайта соответствует минимальному max-age в один год и активна для поддоменов, он может быть включен во внутренний список браузер для сайтов, работающих только через HTTPS.
Пока вы лишь строите из себя админа в манямирке без мониторинга.
А на мой взгляд, Вы строите из себя НЕВЪЕБЕННОГО ОДМИНА. Который НИКОГДА НЕ ОШИБАЕТСЯ.
Я всего лишь пытаюсь доказать что ВСЕ ошибаются. Наверное Вы молоды, чтобы это осознать.
Я даже процитирую ту часть, которую нужно перечитать:
А мою часть прочитать про плаг для мозилы?
Что билять такое ваш «preload» (возможно я не понял и воспринял как одноименный аттрибут для script)?
Мое предложение хоть пример имеет :)
Который НИКОГДА НЕ ОШИБАЕТСЯ.
Если бы я не ошибался, у меня бы не было ни бэкапов, ни мониторинга. К сожалению или к счастью, я уже неоднократно ошибался, и бэкапы с мониторингом у меня давным-давно есть. И, разумеется, я периодически проверяю, что они работают как ожидается.
Что билять такое ваш «preload»
Раз вы за время нашей переписки так и не научились ни читать пост, ни википедией пользоваться, ни гуглить, то объясняю. В современных браузерах встроен оффлайновый список доменов, которые нужно открывать только по https, и для них первый запрос НИКОГДА не пойдёт по http.
Т.е. еще одна зависимость от каких то внешних сервисов.
> оффлайновый список доменов
Кто их будет обновлять? Гугл? Захочет гугл и писец?
Ты не правильный админ )
PS. Лучше распиздяй, чем кто то завязывающийся на чужих сервисах и продвигающий это.
Тогда уж надо мыслить ещё шире: центры сертификации продажные, и один известный кгбшник просто купит у них левый сертификат для вашего домена. А один известный владелец американских казино и без левых сертификатов всё прочитает благодаря закладкам в RSA и AES.
К сожалению, я пока не придумал, как жить так, чтобы не доверять прям вообще никому.
кто то завязывающийся на чужих сервисах
Я так понимаю, вы уже сделали свой центр сертификации, свой браузер, свой корневой DNS, свой интернет-провайдер, свою точку обмена трафиком в своём дата-центре со своим серверным железом и своими прошивками с полным аудитом всего этого кода и прилагающейся своей электростанцией с самостоятельной добычей ресурсов для неё?
Понятно что на 443 может быть обычный 80, но кто этим будет «заморачиваться»?
И это надежней чем какие то «списки».
Но ведь они не направятся, потому что чужой сервис в виде гугла в обязательном порядке захочет напакостить лично вам и не добавлять ваш сайт в свой список доменов. Нужно срочно делать свой собственный браузер со своим собственным списком, чтобы не завязываться на гугл! Почему я не вижу у вас хабрапост с описанием вашего собственного браузера с правильным импортозамещённым списком доменов?
Еще раз.
1. Делается запрос на http (80 порт)
2. Браузер «тыкает» тот же домен по https (443 порт)
3. Ответ получен, мы в шоколаде. Сертификаты и вот это вот все
4. Ответ НЕ получен. Продолжаем по лоховскому http
Зачем какой то свой браузер и т.п. если что то подобное уже реализовано?
- Делается запрос на http (80 порт)
Не делается, потому сайт находится в списке, который встроен в браузер, который запрещает делать запрос по http. Всё.
Вы не доверяете этому списку? Делайте свой браузер и не завязывайтесь на чужие сервисы.
Вы доверяете этому списку? Тогда в чём проблема?
Дальше продолжать?
Мой вариант не зависит от всяких «списков».
> Вы доверяете этому списку?
Не доверяю никому. А +1 кандидат в доверие не нравится.
Мой вариант
Какой вариант? Перечитал все ваши комментарии в этом посте — не увидел ничего похожего на рабочий вариант.
PSS. а именно preload не очень понял при чем тут это. Ты первый раз заходишь по http… Тут надо типа плага addons.mozilla.org/ru/firefox/addon/https-everywhere который НАВЕРНОЕ тычет в 443 порт если пытаешься по 80 войти.
Ну и
Еще раз.
1. Делается запрос на http (80 порт)
2. Браузер «тыкает» тот же домен по https (443 порт)
3. Ответ получен, мы в шоколаде. Сертификаты и вот это вот все
4. Ответ НЕ получен. Продолжаем по лоховскому http
А мы дальше думаем про «списки»…
https-everywhere
То есть вы доверяете стороннему плагину, но не доверяете браузеру? Ай-ай-ай, двоемыслие во все поля.
Ответ [по 443] НЕ получен. Продолжаем по лоховскому http
И злобный mitm-хакер, порезав доступ к 443 порту, радостно перехватывает все пароли. Вы сами-то осознаёте, что пишете?
И злобный mitm-хакер, порезав доступ к 443 порту, радостно перехватывает все пароли. Вы сами-то осознаёте, что пишете?
И чем в этом помогут списки? Вы хотя бы понимаете что «bla.com» есть «альяс» «bla.com:443»?
Вы сами-то осознаёте, что пишете?
То есть вы доверяете стороннему плагину, но не доверяете браузеру? Ай-ай-ай, двоемыслие во все поля.
Кто сказал, что я ему доверяю? Я объяснил как в «в идеале».
И чем в этом помогут списки?
Тем, что запрос по порту 80 не пойдёт вообще никогда ни при каких условиях, и злобный хакер ничего не сможет перехватить, даже если порежет порт 443. Вместо этого пользователь получит ошибку отключения. Неудобно, зато безопасно.
Кто сказал, что я ему доверяю?
Тогда не нужно его вообще упоминать. «В идеале» у нас и злобных хакеров не существует и шифровать ничего не надо.
Тем, что запрос по порту 80 не пойдёт
Даже если хозяин сервера захотел? Да бля тут списки никакие не нужны. Тупо на всех роутерах заблочить и все…
ЗЫ. Хорошо что тебя нет во всяких комиссиях принимающих решения.
Тупо на всех роутерах заблочить и все…
Было бы отлично, «в идеале». К сожалению, у нас существуют ленивые админы, которые не хотят переходить на https (и настраивать мониторинг для слежения за работой certbot). Приходится жить в реальном мире и костылять со списками.
Даже если хозяин сервера захотел?
Если хозяин сервера захотел — он просто не будет включать HSTS. И злобные хакеры неизбежно будут слушать пользователей сайта, ага. Если принцип Неуловимого Джо не сработает.
«В идеале» у нас и злобных хакеров не существует и шифровать ничего не надо.
Хакеры трафик не слушают (ресурсов нет, если не наняты государством). Это делают правительства. Для начала.
у нас существуют ленивые админы, которые не хотят переходить на https
Нет, не только. Есть еще кровавый Ынтерпрайз. Циски/оракл/HP и прочее. Пересадишь все инфраструктуры на https?
Если хозяин сервера захотел — он просто не будет включать HSTS
Дык я об этом с самого начала )
Хакеры трафик не слушают
И я слушал, и меня слушали. Вайфай — отличное место для мамкиных хакеров, чтобы слушать. Не обязательно слушать весь интернет сразу.
Это делают правительства.
Правительства подкупают центры сертификации и делают ослабленные алгоритмы шифрования, так что говорить тут вообще не о чем.
Есть еще кровавый Ынтерпрайз.
Его тоже нужно иногда обновлять. Сидеть по полвека на одном и том же оборудовании и ПО не выйдет, ибо решето. Если только это не полностью изолированная от интернета инфраструктура, но тогда и об https разговаривать вообще нет смысла.
Дык я об этом с самого начала )
Тогда надо было с самого начала чётко постулировать, что обсуждаемый админ класть хотел на безопасность. Я-то с точки зрения обеспечения безопасности рассуждаю
Вайфай — отличное место для мамкиных хакеров, чтобы слушать.
Построивший инфраструктуру предприятия на вайфае который можно прослушать разве не должен гореть в аду? )
Я-то с точки зрения обеспечения безопасности рассуждаю
А если за это не платят, а за простои «штрафуют» (а за дыры не штрафуют)?
Не все чернобелое )
Построивший инфраструктуру предприятия на вайфае который можно прослушать разве не должен гореть в аду? )
Обязательно должен. Но далеко не все верят в ад, и открытые вайфаи встречаются на каждом квадратном метре любого крупного города. А телефоны прохожих к ним автоматически подключаются.
А если за это не платят, а за простои «штрафуют» (а за дыры не штрафуют)?
Вот после такого отношения мои персданные и все мои болезни из медицинских карт свободно гуляют по интернетам. Всё чёрно-белое, и все ваши примеры — чёрные.
Но далеко не все верят в ад, и открытые вайфаи встречаются на каждом квадратном метре любого крупного города.
Мы про гипотетический «завод по обработке перс данных». Если «завод» не удосужился нанять админа который хотя бы знает про ВЛАНЫ, это проблема завода или админа?
Всё чёрно-белое, и все ваши примеры — чёрные.
И виноваты всегда админы, да? )
Не «нормативы» и прочая ересь?
Прекрасная статья, спасибо! Как говорится, век живи — век учись.
Вот только я что-то не догнал, в чем плюс Immutable, не могли бы вы пояснить на примере, как поведет себя браузер с этим параметром и без него
А, у вас там ссылка отличная приведена. Спасибо, уже все выяснил.
Без толку, на MDN пишут что immutable поддерживает только firefox и safari, а chrome даже не планирует добавлять поддержку — учитывая их доли рынка это мёртворожденная фича.
Чтобы избежать взлома вашего сайта, CSP также предоставляет режим только для отчетов.
И чешу репу… Что же это получается, есть шанс сделать сайт уязвимым при неправильной настройке CSP??? И тут я осознаю, это же перевод. Лезу в оригинал:
To avoid breaking your site, CSP also provides a report-only option.
Болд в обоих местах мой. Речь не о взломе, а нарушении функционирования.
Если первый запрос сделан через HTTP только для получения перенаправления, то пользователь может несколько секунд ничего не видеть на экране. А с помощью HSTS вы можете сэкономить эти секунды, и браузер автоматически будет использовать HTTPS.
Не совсем понятно. Первый http запрос для получения редиректа заменили на первый http запрос для получения заголовка HSTS. Так а где экономия по времени тогда?
Заголовки HSTS лучше кешируются, и обычная очистка кеша их не удаляет. Кроме того, для известных сайтов HSTS правила уже вшиты в исходники браузера, так что даже установленный с нуля браузер сразу пойдет на https версии этих сайтов. Вот пример такого файла в исходниках Chromium, осторожно, весит 76 Мб и может открываться долго.
HTTP-заголовки для ответственного разработчика