| 1.1, Аноним (-), 23:43, 08/07/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> При изменении ответа слабые ETag теперь сохраняются, а сильные ETag преобразуются в слабые.
Можно подробнее, голова не варит как это .... ETag преобразуются в слабые short-tag?
| | |
| |
| |
| 3.3, Аноним (-), 02:49, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– | |
Вик етаг, когда он вычисляется приложением на основе данных. Например есть страница новости, можно на уровне контроллера приложения сделать что-то типа:
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 вычисляется только на основе семантически значимого содержимого.
| | |
| |
| 4.4, Аноним (-), 02:54, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Рефакторинг :))
totaltimestamp = @post.updated_at.to_i
@post.comments.each { |comment| totaltimestamp += comment.updated_at.to_i }
weak_etag = Digest::SHA1.hexdigest(totaltimestamp.to_s)
| | |
| |
| 5.5, Аноним (-), 08:01, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Твои упражнения в кодерстве малоинтересны. Если ты хочешь поумничать - скажи что означает преобразование strong ETag -> Weak. Это как, например?
| | |
|
|
| 3.6, Аноним (-), 08:03, 09/07/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Тот редкий случай когда по-английски понятней не становится.
Родной язык основных разработчиков nginx - не английский. <offtopic> Кстати да, чего это они не захотели стартап в России забацать? </offtopoc>
| | |
| |
| 4.11, XoRe (ok), 09:08, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > Родной язык основных разработчиков nginx - не английский. <offtopic> Кстати да, чего
> это они не захотели стартап в России забацать? </offtopoc>
А вы знаете много примеров покупки платного nginx в России?
| | |
| 4.14, Аноним (-), 10:06, 09/07/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Родной язык основных разработчиков nginx - не английский. <offtopic> Кстати да, чего
> это они не захотели стартап в России забацать? </offtopoc>
потому что тут все хотят на халяву и все бесплатно. А в США платят хорошие деньги и дают заработать.
что не понятно.
| | |
|
|
|
| 1.8, the joker (ok), 08:21, 09/07/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > В новой версии добавлена директива ssl_password_file для определения
> файла с паролями от секретных ключей
Раньше, чтобы при старте вебсервер не останавливался для ввода пароля, люди сохраняли ключ без пароля, то теперь будут сохранять пароль в файл. ИМХО, с точки зрения безопасности это ничего не меняет.
Если есть другие мнения, интересно их послушать.
| | |
| |
| 2.9, Аноним (-), 09:04, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Для несанкционированного использования беспарольного ключа достаточно упереть сам ключ, в случае же файла с паролями нужно ещё и его умыкнуть. Т.е. усиление защиты есть, но [очень] незначительное по принципу "лучше, чем ничего".
| | |
| |
| 3.15, Sw00p aka Jerom (?), 12:05, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если уперли приватный ключ, значить и файлик с паролями рядом, тоже самое и с уязвимостями типа хертблид
| | |
| |
| 4.19, Аноним (-), 14:22, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Если уперли приватный ключ, значить и файлик с паролями рядом, тоже самое и с уязвимостями типа хертблид
Ну, смотря как софтину сделать. Можно, например, приватные ключи хранить в памяти шифрованными, а файлик с паролями при загрузке тоже шифровать случайным ключом, генерируемым при запуске, и расшифровывать всё это дело только при необходимости (расшифровали -> попользовались -> затёрли рашифрованные данные). Если при этом [постараться] сделать так, чтобы участки памяти с приватными ключами, паролями и ключом для паролей были подальше друг от друга, то вероятность успешной компрометации при аналоге heartbleed-а несколько снизится.
Но, опять же, такое усиление безопасности, где пароли хранятся открытым текстом в отдельном файле, весьма условно. Классическая проблема "безопасность vs. удобство".
| | |
| |
| 5.20, Sw00p aka Jerom (?), 14:29, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
опять таки приватный ключ с правами 777 лежать не будет - и нужен как минимум рут, систему рутать нуно, а если порутали то кранты ничего не спасёт.
| | |
| |
| 6.22, Andrey Mitrofanov (?), 14:36, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> нуно, а если порутали то кранты ничего не спасёт.
NSA спасает! Ну, то есть SElinux. B) Там, где включён. И настроен.
| | |
|
| 5.21, Andrey Mitrofanov (?), 14:32, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Ну, смотря как софтину сделать. Можно, например, приватные ключи хранить в памяти
> шифрованными, а файлик с паролями при загрузке тоже шифровать случайным ключом,
> для паролей были подальше друг от друга, то вероятность успешной компрометации
> при аналоге heartbleed-а несколько снизится.
Хацкеры из скайпа ещё, если правильно помню, широуют код, расшифровывая его перед исполнением, загружают куски корабля-ностителя (сервера хозяев), перемешивают это всё указателями на функции и повторением всего вышеперечисленного и взбалтыванием.
А ещё еcть волшебные буквы drm/tpm.
Какое это всё имеет отношение к безопасности? Примерно такое же, как покупка голограмы-наклейки. Никому ж нельзя верить.
| | |
|
|
|
| 2.12, XoRe (ok), 09:15, 09/07/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Если есть другие мнения, интересно их послушать.
Можно подумать про подмонтировать папку по sshfs, а после запуска - отмонтировать.
Хотя куча ssl сертификатов с ключами - узкое применение.
Наверное это актуально всяким хостерам/cdn/anti ddos сервисам, у которых куча ssl сертификатов от клиентов.
"сделать клиентские сертификаты безпарольными" - это снижение безопасности, за которое а-та-та.
А "подставлять пароли из файла" - разумная альтернатива, особенно если папку с паролями монтировать только на время запуска.
| | |
| |
| 3.17, Sw00p aka Jerom (?), 12:23, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> Если есть другие мнения, интересно их послушать.
> Можно подумать про подмонтировать папку по sshfs, а после запуска - отмонтировать.
> Хотя куча ssl сертификатов с ключами - узкое применение.
> Наверное это актуально всяким хостерам/cdn/anti ddos сервисам, у которых куча ssl сертификатов
> от клиентов.
> "сделать клиентские сертификаты безпарольными" - это снижение безопасности, за которое
> а-та-та.
> А "подставлять пароли из файла" - разумная альтернатива, особенно если папку с
> паролями монтировать только на время запуска.
Ну и берешь убиваешь процесс и ждешь када подмонтируется фс, а то и сам подмонтируй, конечно если рут
| | |
| |
| 4.18, PyMonty (?), 12:46, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Зачем такие сложности, когда в случае рута ключ можно и из памяти nginx достать.
| | |
| |
| 5.23, Sw00p aka Jerom (?), 14:42, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Зачем такие сложности, когда в случае рута ключ можно и из памяти
> nginx достать.
ну и смысл всего этого ? типа холивара - зачем хранить в файле пароли )))
а шо типа /etc/shadow не файл с хешами ?
| | |
|
| 4.25, XoRe (ok), 18:00, 10/07/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну и берешь убиваешь процесс и ждешь када подмонтируется фс
Необязательно автоматом, руками.
> , а то
> и сам подмонтируй, конечно если рут
Я про сетевую папку.
Можно примонтировать папку с отдельного сервера по sshfs, с авторизацией по паролю, или по ключу (с пробросом ключа с девелоперской машины, через ssh agent).
Т.е. все заводится на группу лиц, у которых есть права на доступ к хранилищу паролей.
Практический смысл - представьте, у вас 100-1000 ssl сертификатов и каждый будет запрашивать пароль.
Во первых, веб сервер будет стартовать долго, пока все пароли введете.
Во вторых, эти пароли надо откуда-то копипастить - все равно дырка.
Лучше держать их в отдельном месте, куда имеют доступ по ключу нужные люди.
И логировать каждое подключение, или монтирование.
| | |
|
|
|
|
