[см. Исправление ниже]
Возможно безопасное взаимодействие с аутентифицированным сервером на движке приложений 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://..., чтобы указывать на что-то другое.
Вместо этого взгляните на wwwizer.com .