Назад HTTPS; Пользователь общается с ранее созданным закрытым ключом - PullRequest
3 голосов
/ 05 августа 2010

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

Я подумал о некоторых странных подходах JavaScript для реализации этого (С точки зрения клиента: отправка форм шифруется при их выходе, в то время как (по ответу ajax) веб-контент дешифруется. Я понимаю, что это ужасно, но вы можете ' Я не могу отрицать, что это было бы забавно, но мне было интересно, есть ли что-то уже там ... что-то обычно реализуемое в браузерах и серверах веб-приложений.

В первую очередь это относится к нарушенной безопасности, когда (по незнанию) обменивается данными через мошенническую точку доступа, которая может перехватывать соединения https и выдавать свои собственные сертификаты. Недавно (в моей собственной сети) я воссоздал это и (с ужасом) вскоре увидел мой пароль Gmail в виде обычного текста! У меня есть веб-приложение, которое используют только я и несколько других, но где безопасность (с точки зрения обучения) должна быть на высшем уровне.

Я должен добавить, решение не должно быть практичным

Кроме того, если в моем мыслительном процессе что-то не так, я был бы очень признателен, если бы кто-то поставил меня на правильный путь или направил меня к соответствующей литературе. Наука не о поиске лучших ответов; наука - это формирование лучших вопросов.

Спасибо за ваше время, O∴D

Ответы [ 4 ]

2 голосов
/ 05 августа 2010

Это уже сделано.Они называются клиентскими сертификатами TLS.SSL не должен быть односторонним;это может быть двусторонняя взаимная аутентификация.

То, что вы делаете, это заставляет клиента генерировать закрытый ключ.Затем клиент отправляет CSR (запрос на подпись сертификата) на сервер, который подписывает открытый ключ и возвращает его клиенту.Закрытый ключ никогда не отправляется по сети.Если точка доступа перехватывает и изменяет ключ, клиент узнает.

Однако это не не позволяет мошеннической точке доступа запрашивать сертификат от имени клиента.Вам нужен внеполосный канал для проверки личности. невозможно помешать человеку посередине выдать себя за клиента без какого-либо способа обойти этот MITM.

2 голосов
/ 05 августа 2010

Если мошенническая точка доступа может прослушивать пакеты, она также может изменять пакеты («активная» атака «человек посередине»).Таким образом, любая мера безопасности, которую может обеспечить сценарий на стороне клиента, может быть легко обойдена путем добавления самого сценария на пути к клиенту.

HTTPS - и предупреждения о несанкционированном сертификате, которое вы получаете, когда MitM пытаетсядурак ты - так же хорош, как он получает.

1 голос
/ 06 августа 2010

Я не понимаю, почему вы используете асимметричное шифрование здесь. Во-первых, он медленный, а во-вторых, он так или иначе уязвим для человека в середине.
Обычно вы используете асимметричное шифрование для обеспечения относительно безопасного согласования сеанса, включая обмен ключами для симметричного шифрования, действительного для сеанса.

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

Кроме того, как уже указала ладья, JavaScript - плохая идея. Вы должны писать все с нуля, начиная с основных арифметических операций, поскольку Number не продвинет вас слишком далеко, если вы захотите работать с ключами на порядок, что обеспечивает разумную безопасность.

Greetz
back2dos

1 голос
/ 05 августа 2010

SSL и там для HTTPS позволяет для клиентских сертификатов. на стороне сервера вы можете использовать эти переменные среды для проверки сертификата. Если у вас есть только 1 сервер и группа клиентов, тогда полная PKI не требуется. Вместо этого вы можете иметь список действительных клиентских сертификатов в базе данных. Здесь - дополнительная информация по теме.

Реализация чего-либо подобного в JavaScript - плохая идея.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...