Доступен (http://mailman.nginx.org/pipermail/nginx-announce/2014/00014... новый выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.7.3 (http://nginx.org/), в котором продолжено развитие новых возможностей. В новой версии добавлена (http://nginx.org/en/CHANGES) директива ssl_password_file (http://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_p... для определения файла с паролями от секретных ключей. При возможности для ревалидации кэша теперь используется HTTP-заголовок If-None-Match. При изменении ответа слабые ETag (http://ru.wikipedia.org/wiki/HTTP_ETag) теперь сохраняются, а сильные ETag преобразуются в слабые.
URL: http://mailman.nginx.org/pipermail/nginx-announce/2014/00014...
Новость: http://www.opennet.me/opennews/art.shtml?num=40163
> При изменении ответа слабые ETag теперь сохраняются, а сильные ETag преобразуются в слабые.Можно подробнее, голова не варит как это .... ETag преобразуются в слабые short-tag?
Тот редкий случай когда по-английски понятней не становится.
>Feature: weak entity tags are now preserved on response modifications, and strong ones are changed to weak.Курить, вероятно, надо 13.3.3 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
Вик етаг, когда он вычисляется приложением на основе данных. Например есть страница новости, можно на уровне контроллера приложения сделать что-то типа:totaltimestamp = 0
@post.comments.each do { |comment| totaltimestamp += comment.updated_at.to_i }
weak_etag = Digest::SHA1.hexdigest( ( totaltimestamp + @post.updated_at.to_i ).to_s)соответственно Weak ETag вычисляется только на основе семантически значимого содержимого.
Рефакторинг :))
totaltimestamp = @post.updated_at.to_i
@post.comments.each { |comment| totaltimestamp += comment.updated_at.to_i }
weak_etag = Digest::SHA1.hexdigest(totaltimestamp.to_s)
Твои упражнения в кодерстве малоинтересны. Если ты хочешь поумничать - скажи что означает преобразование strong ETag -> Weak. Это как, например?
> Тот редкий случай когда по-английски понятней не становится.Родной язык основных разработчиков nginx - не английский. <offtopic> Кстати да, чего это они не захотели стартап в России забацать? </offtopoc>
Они что, сами себе враги?
> Родной язык основных разработчиков nginx - не английский. <offtopic> Кстати да, чего
> это они не захотели стартап в России забацать? </offtopoc>А вы знаете много примеров покупки платного nginx в России?
> Родной язык основных разработчиков nginx - не английский. <offtopic> Кстати да, чего
> это они не захотели стартап в России забацать? </offtopoc>потому что тут все хотят на халяву и все бесплатно. А в США платят хорошие деньги и дают заработать.
что не понятно.
Очевидно путем добавления "W/", указывающего, что они weak.
> В новой версии добавлена директива ssl_password_file для определения
> файла с паролями от секретных ключейРаньше, чтобы при старте вебсервер не останавливался для ввода пароля, люди сохраняли ключ без пароля, то теперь будут сохранять пароль в файл. ИМХО, с точки зрения безопасности это ничего не меняет.
Если есть другие мнения, интересно их послушать.
Для несанкционированного использования беспарольного ключа достаточно упереть сам ключ, в случае же файла с паролями нужно ещё и его умыкнуть. Т.е. усиление защиты есть, но [очень] незначительное по принципу "лучше, чем ничего".
>"лучше, чем ничего".ничего, которое ничем не лучше. //fixed
Если уперли приватный ключ, значить и файлик с паролями рядом, тоже самое и с уязвимостями типа хертблид
> Если уперли приватный ключ, значить и файлик с паролями рядом, тоже самое и с уязвимостями типа хертблидНу, смотря как софтину сделать. Можно, например, приватные ключи хранить в памяти шифрованными, а файлик с паролями при загрузке тоже шифровать случайным ключом, генерируемым при запуске, и расшифровывать всё это дело только при необходимости (расшифровали -> попользовались -> затёрли рашифрованные данные). Если при этом [постараться] сделать так, чтобы участки памяти с приватными ключами, паролями и ключом для паролей были подальше друг от друга, то вероятность успешной компрометации при аналоге heartbleed-а несколько снизится.
Но, опять же, такое усиление безопасности, где пароли хранятся открытым текстом в отдельном файле, весьма условно. Классическая проблема "безопасность vs. удобство".
опять таки приватный ключ с правами 777 лежать не будет - и нужен как минимум рут, систему рутать нуно, а если порутали то кранты ничего не спасёт.
> нуно, а если порутали то кранты ничего не спасёт.NSA спасает! Ну, то есть SElinux. B) Там, где включён. И настроен.
> Ну, смотря как софтину сделать. Можно, например, приватные ключи хранить в памяти
> шифрованными, а файлик с паролями при загрузке тоже шифровать случайным ключом,
> для паролей были подальше друг от друга, то вероятность успешной компрометации
> при аналоге heartbleed-а несколько снизится.Хацкеры из скайпа ещё, если правильно помню, широуют код, расшифровывая его перед исполнением, загружают куски корабля-ностителя (сервера хозяев), перемешивают это всё указателями на функции и повторением всего вышеперечисленного и взбалтыванием.
А ещё еcть волшебные буквы drm/tpm.
Какое это всё имеет отношение к безопасности? Примерно такое же, как покупка голограмы-наклейки. Никому ж нельзя верить.
лучше доступ к хранилищу ключей ldap, одноразовый токен..
> Если есть другие мнения, интересно их послушать.Можно подумать про подмонтировать папку по sshfs, а после запуска - отмонтировать.
Хотя куча ssl сертификатов с ключами - узкое применение.
Наверное это актуально всяким хостерам/cdn/anti ddos сервисам, у которых куча ssl сертификатов от клиентов.
"сделать клиентские сертификаты безпарольными" - это снижение безопасности, за которое а-та-та.
А "подставлять пароли из файла" - разумная альтернатива, особенно если папку с паролями монтировать только на время запуска.
>> Если есть другие мнения, интересно их послушать.
> Можно подумать про подмонтировать папку по sshfs, а после запуска - отмонтировать.
> Хотя куча ssl сертификатов с ключами - узкое применение.
> Наверное это актуально всяким хостерам/cdn/anti ddos сервисам, у которых куча ssl сертификатов
> от клиентов.
> "сделать клиентские сертификаты безпарольными" - это снижение безопасности, за которое
> а-та-та.
> А "подставлять пароли из файла" - разумная альтернатива, особенно если папку с
> паролями монтировать только на время запуска.Ну и берешь убиваешь процесс и ждешь када подмонтируется фс, а то и сам подмонтируй, конечно если рут
Зачем такие сложности, когда в случае рута ключ можно и из памяти nginx достать.
> Зачем такие сложности, когда в случае рута ключ можно и из памяти
> nginx достать.ну и смысл всего этого ? типа холивара - зачем хранить в файле пароли )))
а шо типа /etc/shadow не файл с хешами ?
> Ну и берешь убиваешь процесс и ждешь када подмонтируется фсНеобязательно автоматом, руками.
> , а то
> и сам подмонтируй, конечно если рутЯ про сетевую папку.
Можно примонтировать папку с отдельного сервера по sshfs, с авторизацией по паролю, или по ключу (с пробросом ключа с девелоперской машины, через ssh agent).Т.е. все заводится на группу лиц, у которых есть права на доступ к хранилищу паролей.
Практический смысл - представьте, у вас 100-1000 ssl сертификатов и каждый будет запрашивать пароль.
Во первых, веб сервер будет стартовать долго, пока все пароли введете.
Во вторых, эти пароли надо откуда-то копипастить - все равно дырка.
Лучше держать их в отдельном месте, куда имеют доступ по ключу нужные люди.
И логировать каждое подключение, или монтирование.
Это опять Systemd !!! :))в общем хотелки пользователя: