Стандартный способ статической подписи веб-страницы - PullRequest
1 голос
/ 10 января 2011

Предположим, у меня есть действующий (то есть подписанный одним из доверенных лиц) криптографический сертификат на моем сервере. Я мог бы, очевидно, использовать его для установления сеансов https и доставки содержимого с соблюдением конфиденциальности (только конечные точки могут их прочитать), аутентификации (обе конечные точки знают, с кем они разговаривают) и надежности (сообщение не может быть подделано).

Теперь предположим, что я на самом деле не забочусь о первых двух, но вместо этого мне просто нужен последний. Например, допустим, у меня есть статический ресурс, который я хотел бы подписать (а-ля PGP), чтобы я мог передать его другим ненадежным хостам: если мой сертификат является общедоступным и ресурс подписан с ним, любой клиент должен быть в состоянии проверить, что ресурс не был подделан (например, ненадежным хостом).

Теперь возникает вопрос: существует ли стандартный способ статической подписи веб-страницы? (Я, очевидно, имею в виду что-то встроенное во все браузеры). Мне известно о ком-то ( Unhosted ), который пытается достичь чего-то подобного путем реализации большей части логики с помощью Javascript, но все же мне интересно, если более стандарт путь существует.

Ответы [ 2 ]

1 голос
/ 10 января 2011

Я не знаю ни одной такой стандартной реализации встроенного в браузере.

Даже в почтовой области, где такое поведение долгое время является «стандартным» (S / MIME), мы каждый день обнаруживаем проблемы с различными клиентами, реле и серверами.

Для загрузки вы можете вернуться к отправке контейнера PKCS # 7 и связать инструмент, который распаковывает и проверяет. По крайней мере, плагины и вспомогательные приложения доступны везде.

0 голосов
/ 11 января 2011

Я также не знаю ни о какой стандартной реализации в браузере.Но, для резервного копирования ... некоторые вещи, которые следует учитывать:

  1. Для исполняемого содержимого (например, загруженных EXE-файлов, элементов управления ActiveX, установщика Windows и т. Д.), Общий / стандартныйРешением является Microsoft Authenticode.См. http://www.tech -pro.net / code-signature-for-developers.html .Аналогичные решения для Java, Adobe и т. Д. Центр сертификации, у которого вы покупаете сертификат, подтвердит вашу личность.Когда вы подписываете EXE-файл сертификатом из доверенного центра сертификации, Internet Explorer отображает информацию о подписавшем / менее страшное предупреждение.То же самое касается запросов на повышение уровня контроля учетных записей в Windows Vista / 7.Вы, наверное, знакомы с этим?

  2. Но для ситуации со статическим контентом стандартным решением является SSL.Могу ли я спросить, почему SSL не является приемлемым решением в вашем приложении?

    Проблема, которую я вижу, состоит в том, что у пользователя нет способа проверить подлинность веб-страницы с помощью веб-браузера, кроме нажатия кнопкиSSL-значок «блокировка» в браузере для просмотра сертификата.Новые сертификаты SSL EV должны подтверждать, что вы контролируете рассматриваемый домен и что вы являетесь тем, кем себя называете (т.е. не сможете получить сертификат «PayPal» для www.paypal.com.hacker.cz).

Из вашего вопроса звучит, что вы ищете что-то вроде «Authenticode для веб-страниц»: сертификат с темой, не связанной с доменным именем, и куда может перейти веб-страница.в любом месте.К сожалению, я не знаю ничего подобного для стандартных файлов HTML.Я считаю, что вы можете подписывать такие вещи, как приложения Adobe AIR, которые могут быть основаны на HTML / Javascript / и т. Д., Хотя я не знаком с этой платформой.Разумеется, он размещает веб-страницу вне обычного веб-браузера пользователя.

...