Добрый день, можно ли в JSF (с использованием каких-либо фреймвёрков, и с небольшим гемором) реализовать шифрование данных между браузером и сервером (всех)?

(при том, что активно используется ajax)

поиск google 'jsf encrypt' ничего не дал

кроме ssl.

что-то вроде джаваскриптом перед сабмитом формы зашифровать всё, и на сервере вклиниться в цикл jsf'а, и расшифровать?

если да, то куда смотреть, в какую сторону?

Это сообщение отредактировал(а) L0ckD0g - 23.7.2010, 18:17

 Какой смысл, если эти данные можно будет легко расшифровать? Google правильно выдал, что нужно использовать SSL.

Единственно, в форме авторизации можно использовать JS имплементацию MD5 или SHA1 для создания хэша пароля клиентом и отправки его на сервер.

От решения HTTPs отказывается заказчик (банк), поэтому, видимо останемся на JSP :(

  

А почему?

а какая собственно разница, JSP или JSF в данном случае?

Желание заказчика закон - тем более он платит баблосы за ненужную (IMHO) разработку

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

Так что остается вариант:
а) с придумыванием собственного браузера (что слишком круто даже для банка   ) 
б) или же что более жизнеутверждающе написать что-то вроде HTTP прокси, который берет ответ клиента, шифрует и отсылает серверу, ну а сервер уже дешифрует. Для полноты картины связку клиент-прокси можно сделать на HTTPS, а связку прокси-сервер сбацать на каком-нибудь крутом алгоритме шифрования - да хоть 1024 бита.

Это сообщение отредактировал(а) ivanovpv - 28.7.2010, 15:23

Вообще ваш вопрос носит принципиальный характер.

1. Шифровать трафик надо от клиента к  серверу.
2. Шифровать и расшифровывать на сервере не проблема.
3. Как Вы изволили заметить - проблема на клиенте.
4. Не понятно, чем поможет прокси, раз он в целях  безопасности. должен стоять на клиенте?
5. Свой браузер - это просто приложение, работающее через HTTP протокол, которое шифрует весь трафик. Написать это не проблема. Проблема, на каком языке, для какой платформы и необходимость инсталляции.
6. То есть имеем альтернативу - либо шифровать все через TSL (HTTPS), либо писать и инсталлировать на клиенте приложение. Третьего не дано? Хотелось бы, чтобы более грамотные товарищи меня поправили.

По-моему третий возможный вариант - это Java-апплет. Других увы не припомню.

К сожалению и при использовании аплетов надо инсталлировать JVM.

По долгу службы имею дело с разработчиками разных банков, и насколько я понимаю, банки в основном просят клиентов инсталлировать свои приложения. Можно использовать WebStart, но это лишь облегчает дело и не меняет ситуацию кардинально. 
 

Ну да так оно и есть. Может я не совсем точно выразился по поводу прокси, но я предполагал, что клиент будет продолжать работать на стандартном браузере, в настройках браузера указываем прокси который находится в локальной сети. Прокси пишем сами, он тупо принимает запросы по HTTP/HTTPS и шифрует данные и пересылает по HTTP же на удаленный сервер. Плюс только в том, что прокси находится не на клиентской станции, а где-то рядом в локальной сети (плюс в том смысле, что не надо на клиентской машине ничего инсталлировать). В общем все сильно похоже на работу какого-нить анонимайзера.

Это сообщение отредактировал(а) ivanovpv - 28.7.2010, 17:52

Осталось выяснить у ТС чем же не подошел HTTPS?