Использовать модуль шифрования JavaScript вместо SSL/HTTPS

Question

Стоит ли использовать некоторую библиотеку шифрования JS для безопасного обмена данными вместо SSL? Я спрашиваю об этом, потому что хочу защитить свое приложение, построенное на Google App Engine, и оно не позволяет вам использовать свой собственный домен для запросов SSL. Каковы хорошие способы безопасного общения с GAE? Благодарю.

Answer 1

[См. Исправление ниже]

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

Вот основные инструкции для Python, но вы можете изменить для Java. Будьте готовы потратить, по крайней мере, день или два на то, чтобы все заработало.

Предпосылки:

• Библиотека Python RSA и AES для сервера. pyCrypto хорошо работает на GAE.
• Javascript RSA и AES библиотека для запуска на клиенте. Я использовал Стэнфордскую библиотеку RSA и crypto-js для AES. Я не могу вспомнить, почему я не использовал только одну библиотеку.

Инструкции:

• Шаг 1: В автономном режиме создайте пару открытых и закрытых ключей RSA. Вот инструкции PyCrypto.

• Шаг 2: Сохраните сгенерированные открытые и закрытые ключи RSA в файле Python, убедитесь, что закрытый ключ не является общедоступным.

• Шаг 3: На сервере создайте запрос, который генерирует файл javascript. Файл javascript должен только передавать открытый ключ клиенту. Например, он будет возвращать только файл с этим:

  var public_key="[your public rsa key here]"

• Шаг 4: В вашем app.yaml файл, убедитесь, что созданный файл javascript обслуживается только через SSL (т.е. установлен secure: always). Смотрите инструкции здесь.

• Шаг 5: На клиенте загрузите файл javascript, используя ssl. Однако вместо использования своего пользовательского домена используйте домен appspot. Например, добавьте это в ваш HTML-файл:

  <script src="https://example.appspot.com/publicKey.js"></script>

  Теперь клиент будет иметь аутентифицированный открытый ключ RSA, предотвращающий атаки "человек посередине". Примечание: доступ к другим доменам обычно запрещен браузерами для предотвращения XSS, но есть лазейка, которая позволяет загружать файлы JavaScript.

• Шаг 6: На клиенте сгенерируйте случайный закрытый ключ. Используйте библиотеку javascript RSA и открытый ключ, полученный на шаге 4, для шифрования случайного закрытого ключа. Отправьте зашифрованный закрытый ключ на сервер.

• Шаг 7: На сервере расшифруйте случайный ключ, сгенерированный на клиенте, используя закрытый ключ RSA.

  На этом этапе и сервер, и клиент имеют один и тот же закрытый ключ. Более того, поскольку исходный открытый ключ был передан по протоколу SSL, мы можем подтвердить подлинность того, что сервер действительно является тем, кем, как мы считаем, (т. Е. Без посредника).

• Шаг 8: Теперь сервер и клиент могут шифровать и дешифровать любые данные, которые они хотят, используя случайно сгенерированный закрытый ключ и их соответствующие библиотеки AES.

- РЕДАКТИРОВАТЬ: ИСПРАВЛЕНИЕ -

Комментарий Бруно, приведенный ниже, является на 100% правильным, вышеуказанные шаги небезопасны. Несмотря на то, что описанные выше шаги действительно работают для настройки аутентифицированного сеанса между клиентом и сервером, единственный способ, которым пользователи действительно узнают, что он был аутентифицирован, - это если они проверили код, чтобы убедиться, что открытый ключ загружался с использованием https. Человек посередине может обслуживать начальную HTML-страницу, изменить <script src="https://... код для указания на что-то еще.

Вместо этого взгляните на http://www.wwwizer.com/.

Answer 2

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

РЕДАКТИРОВАТЬ: Вы не имеете в виду Java?

Answer 3

Нет, это того не стоит, потому что вы должны как-то отправить клиенту код Javascript. Злоумышленник может просто изменить Javascript, чтобы он мог прочитать (или изменить) все сообщения, сделав все ваши средства защиты бесполезными. SSL действительно единственный вариант.

Answer 4

Вы должны использовать https, но вы не можете использовать его на своем домене с appengine. Они говорят, что скоро добавят эту способность. Мы использовали раздражающий домен appspot https, предполагая, что они действительно добавят поддержку пользовательских доменов https, но в то же время никто из наших (~75) клиентов не жаловался на вещь appspot.

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