LINUX.ORG.RU

Шифрование в Web-е c помощью GPG.

 , , ,


1

4

Ненужное ненужно или все-таки имеет право на существование в свете последних событий с принятыми законами...

Имеется: Клиент (Browser) и сервер.

Требуется: Обеспечить защифрованную передачу данных между клиентом и сервером с помощью GPG.

Описание:
Пользователь открывает сайт и получает страничку с openpgp.js скриптом и публичным ключом сервера.
В фоновом режиме генерируется пара публичный/приватный ключ клиента и записывается в локальное хранилище браузера.
После генерации пары ключей, шифруем публичный ключ клиента и отсылаем на сервер.
Таким образом мы можем шифровать данные до отправки и рассшифровывать после получения.

Например:
1. Шифруем строку «Hello Server!» публичным ключом сервера в браузере пользователя и отправляем данные на сервер.
2. Получаем зашифрованное сообщение и расшифровываем его приватным ключом сервера.
3. Если данные успешно расшифрованы, готовим ответ «Hello Username» и шифруем публичным ключом пользователя.
4. Отправляем зашифрованное сообщение пользователю.
5. Пользователь получает сообщение и расшифровывает его приватным ключом из локального хранилища браузера.
Весь процесс происходит под капотом. Т.е. для пользователя все максимально прозрачно.

Вопрос остается с парольной фразой для приватного ключа.
Чтобы пользователю не нужно было постоянно вводить пароль.
Во избежание компроментации, можно создавать новую пару ключей каждые n-дней.
Или использовать GPG без пароля нельзя?

И еще вопрос относительно производительности.
Сильно ли скажется постоянная шифровка/расшифровка данных со стороны пользователя?
Хотя принимая во внимание современный веб и его потребности в ресурсах...

P.S. TLS никуда не девается. Просто доп. защита при передаче пакетов между клиентом и сервером.
Если не в том разделе (может веб-разработка?), перенесите пожалуйста.


Имеется: Клиент (Browser) и сервер.

Какой сервер, ваш?

vvn_black ★★★★★ ()
Ответ на: комментарий от vvn_black

Дык, во-первых это пример.
А во-вторых, я как-то не встречал сайтов, у которых передача данных шифровалась бы с помощью GPG.

Sorcus ()

Не проще забить хрен на обделавшиеся в штаны власти РФ и разместить VPS/хостинг в нормальной стране, которая даже письма из РФ рассматривать не будет?

anon-zune ()

получает страничку с
публичным ключом сервера

и сразу fail

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

Варианты по решению проблемы предложить можешь?
Или кроме «и сразу fail» других мыслей нету?...

Sorcus ()

Ау, https работает по этой схеме.

Deleted ()
Ответ на: комментарий от Sorcus

Если вы реализуете свою схему так, как задумали, то возникнет неприятная ситуация. Если TLS скомпрометирован, то GPG тоже является небезопасным (ключ могли подменить). Если же никакого mitm нет, то GPG бесполезен и только тратит ресурсы. Ключ клиенту должен доставляться каким-то другим, безопасным путем, а не вместе с содержимым страницы. Да и, как уже сказал Anakros, вы пытаетесь реализовать https внутри https.

Leupold_cat ★★ ()
Ответ на: комментарий от Leupold_cat

Ну как вариант, перед использованием сайта можно показать пользователю форму c полем для ввода email.
Пользователь заполняет форму и получает на почту hash-сумму для публичного ключа сервера.
Далее пользователь вводит hash-сумму и если она совпадает с hash-суммой полученного публичного ключа сервера, значит можно шифровать передачу данных.
По-идее форму достаточно один раз показывать пользователю.
А по поводу производительности... Разве доп. шифрование будет потреблять так много ресурсов? TLS по-сути ведь тоже тратит ресурсы на шифрование, но вроде как проблем с этим нет.

Sorcus ()
Ответ на: комментарий от Sorcus

Я встречал, штука бесполезная, но может зачем-то и нужна.
Работает не слишком медленно, жить можно.

Goury ★★★★ ()
Ответ на: комментарий от Sorcus

А в чём проблема-то?
Пока ты тут описать только велосипед ради велосипеда.
Никакой дополнительной безопасности или каких-либо удобств эта хреновина не принесёт.
Только геморрой разработчикам и пользователям без какой-либо цели.

Goury ★★★★ ()
Ответ на: комментарий от Sorcus

Ваша новая схема в сравнении с старой безопасней (хотя даже в этом случае просматриваются уязвимые места). Вот только теперь она сложная. Представьте себя на месте постороннего человека, который зашел к вам на сайт, а ему там предлагают зачем-то вводить email и сравнивать hash-суммы. Полагаю, этот пользователь вполне может отказаться от посещения вашего интернет-ресурса. Что касается производительности - речь шла о бесполезной трате ресурсов излишним PGP. Однако, если вы вдруг решите шифровать крупные файлы, то, как мне кажется, работа браузера действительно будет замедлена.

Leupold_cat ★★ ()
Ответ на: комментарий от Leupold_cat

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

Sorcus ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.