о сертификации ЖЖ-страниц
Dec. 19th, 2003 08:27 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaВ связи с некоторыми недавними скандалами [предупреждение: всё, что следует далее, никакого отношения ни к какому конкретному скандалу не имеет, и никакой позиции ни в одном из них я для себя не заявляю. Просто эта тема подтолкнула меня на размышления, никак с ней не связанные. Прошу о "скандальных" поводах ничего мне не писать и в них меня не втягивать. Спасибо] подумал немного о возможности сертификации страниц ЖЖ. В принципе, я могу сейчас взять страницу ЖЖ, например, показывающую какую-то запись с комментами, сохранить её в файле, и как угодно отредактировать перед тем, как выставлю её в другом месте. Изменить текст, имена юзеров, что угодно. Могу, скажем, изменить текст записи на что-то предосудительное, и сказать, "что так и было", а сейчас в той же записи того же юзера (если она вообще открыта) другое, потому что он быстренько отредактировал, но я успех сохранить первоначальный вариант. И так далее — ясно, что возможностей куча. Кто-то в это поверит, кто-то не очень (зависит от многих факторов: от степени доверчивости зрителя, от его оценки моей репутации и моей готовности к манипуляциям, от моих технических способностях, если подделывать нужно не просто текст, а какой-нибудь HTML, итд. итп.).
Можно было бы в принципе убрать фактор неопределённости. Скажем, в каждой HTML-странице, которую он выдаёт, LJ включает в качестве HTML-комментария значение криптографического хэша (скажем, MD5) от содержимого страницы + секретный ключ, хранящийся внутри LiveJournal.com . Можно какие-то ещё данные в вычисление этого хэша включить (например, имя того юзера, который смотрит эту страницу, если он logged in; или ещё неплохая идея - текущее серверное время, которое тут же рядом со значением хэша добавляется в HTML-комментарий). Далее, добавляется сервис "проверьте аутентичность данной страницы": посылаем LJ обратно страницу (напр. в таком виде, в какоме её кто-то выложил в другом месте) и он вычисляет заново значение хэша и сравнивает. Если кто-то что-то менял, проверка это обнаружит. Конечно, злоумышленник может вычистить хэш из HTML-кода страницы, но это само по себе будет свидетельством того, что файл редактировали, и, следовательно, информации в нём нельзя доверять.
(почему MD5, а не подписывать с помощью PGP, скажем? Потому, что MD5 - легко, быстро и реально сделать для всех страниц просто в коде их отдачи. Ведь LJ — полностью динамический сайт, всё, кроме картинок, строится в Перле).
Вряд ли на это будет большой спрос, впрочем.
Это мне напомнило ещё одну мою старую идею: сертификацию ЖЖ-записей. Предположим, я хочу иметь возможность доказать, что в такое-то время в такой-то день в моём журнале была запись такого-то содержания. Сейчас это сделать невозможно. Не потому, что я могу написать позже запись нужного содержания и датировать её задним числом — эту проблему можно было бы обойти, используя записанное в базе данных ЖЖ время создания записи с точки зрения сервера (недоступное обычно юзеру, но мы рассматриваем гипотетическую ситуацию; главное, что эта информация есть и её в принципе можно вытащить). Так вот, не поэтому, а потому, что я могу эту запись впоследствии отредактировать и сказать, что так и было. Базы данных ЖЖ не сохраняют старые варианты. Правда, я сейчас вспомнил, что относительно недавно, где-то полгода назад, мы сделали так, что они теперь сохраняют количество редактирований каждой записи, так что даже без криптографических подписей можно будет доказать, что данную запись кто-то редактировал хотя бы один раз после отправки. Но это тоже не идеально, ведь нет доказательств того, что автор не отредактировал её несколько раз сразу после отправки, исправляя мелкие погрешности, и не занимаясь более поздним подделыванием. И всё же, если записано в базе данных, что не редактировалось ни разу, то мы точно знаем, что всё в порядке — уже неплохо. Но я отклонился от темы. Можно в принципе сделать такой же сервис сертификации определённой записи в определённый момент. В принципе, это можно получить как частный случай описанной выше сертификации любой страницы; а можно сделать чем-то отдельным, сертифицируя именно текст записи и более ничего, используя ещё более надёжные функции итп.
Конечно, надо не забыть упомянуть, что защищённость самого сайта livejournal.com и его баз данных остаётся слабым звеном во всех этих схемах. Это слабое звено в свою очередь можно укреплять — ротацией секретных ключей, использованием для их хранения другого уровня шифровки, или не находящиеся в Интернете компьютеры, итд. итп. — о таких вещах немало статей и диссертаций написано, куда более интересных и сложных, чем это примитивное перечисление, призванное всего лишь передать общую идею.
Можно было бы в принципе убрать фактор неопределённости. Скажем, в каждой HTML-странице, которую он выдаёт, LJ включает в качестве HTML-комментария значение криптографического хэша (скажем, MD5) от содержимого страницы + секретный ключ, хранящийся внутри LiveJournal.com . Можно какие-то ещё данные в вычисление этого хэша включить (например, имя того юзера, который смотрит эту страницу, если он logged in; или ещё неплохая идея - текущее серверное время, которое тут же рядом со значением хэша добавляется в HTML-комментарий). Далее, добавляется сервис "проверьте аутентичность данной страницы": посылаем LJ обратно страницу (напр. в таком виде, в какоме её кто-то выложил в другом месте) и он вычисляет заново значение хэша и сравнивает. Если кто-то что-то менял, проверка это обнаружит. Конечно, злоумышленник может вычистить хэш из HTML-кода страницы, но это само по себе будет свидетельством того, что файл редактировали, и, следовательно, информации в нём нельзя доверять.
(почему MD5, а не подписывать с помощью PGP, скажем? Потому, что MD5 - легко, быстро и реально сделать для всех страниц просто в коде их отдачи. Ведь LJ — полностью динамический сайт, всё, кроме картинок, строится в Перле).
Вряд ли на это будет большой спрос, впрочем.
Это мне напомнило ещё одну мою старую идею: сертификацию ЖЖ-записей. Предположим, я хочу иметь возможность доказать, что в такое-то время в такой-то день в моём журнале была запись такого-то содержания. Сейчас это сделать невозможно. Не потому, что я могу написать позже запись нужного содержания и датировать её задним числом — эту проблему можно было бы обойти, используя записанное в базе данных ЖЖ время создания записи с точки зрения сервера (недоступное обычно юзеру, но мы рассматриваем гипотетическую ситуацию; главное, что эта информация есть и её в принципе можно вытащить). Так вот, не поэтому, а потому, что я могу эту запись впоследствии отредактировать и сказать, что так и было. Базы данных ЖЖ не сохраняют старые варианты. Правда, я сейчас вспомнил, что относительно недавно, где-то полгода назад, мы сделали так, что они теперь сохраняют количество редактирований каждой записи, так что даже без криптографических подписей можно будет доказать, что данную запись кто-то редактировал хотя бы один раз после отправки. Но это тоже не идеально, ведь нет доказательств того, что автор не отредактировал её несколько раз сразу после отправки, исправляя мелкие погрешности, и не занимаясь более поздним подделыванием. И всё же, если записано в базе данных, что не редактировалось ни разу, то мы точно знаем, что всё в порядке — уже неплохо. Но я отклонился от темы. Можно в принципе сделать такой же сервис сертификации определённой записи в определённый момент. В принципе, это можно получить как частный случай описанной выше сертификации любой страницы; а можно сделать чем-то отдельным, сертифицируя именно текст записи и более ничего, используя ещё более надёжные функции итп.
Конечно, надо не забыть упомянуть, что защищённость самого сайта livejournal.com и его баз данных остаётся слабым звеном во всех этих схемах. Это слабое звено в свою очередь можно укреплять — ротацией секретных ключей, использованием для их хранения другого уровня шифровки, или не находящиеся в Интернете компьютеры, итд. итп. — о таких вещах немало статей и диссертаций написано, куда более интересных и сложных, чем это примитивное перечисление, призванное всего лишь передать общую идею.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re: Вопрос по теме
Date: 2003-12-19 05:53 am (UTC)