Marmot писал(а):drain bamage писал(а):Marmot писал(а):
Ну ты посоветовал, ты хочешь сказать что они должны парсить HTML stream посылаемый с appservera и декриптить данные?
По-моему ты не понял их проблемы.
мармот, это ты не понял их проблемы. прочитай условие задачи еще раз
ни в бд, ни на аппсервере plaintext'a быть не должно. plaintext должен шифроваться где-то между аппсервером и клиентским браузером. ясный пень, что в/на чистом браузере хранить можно только certified asymmetric key (и то с боольшими оговорками), который столь же очевидным образом проблемы не решает, поскольку не может быть использован для шифрации <b>html</b> content'a. hense the вывод - нужен еще один hop ... который для простоты обозначения назовем модным словом proxy
see my point так сказать ?
Ок, читаем внимательно:
MarkM писал(а):Я пробовал датабазную част. Довольно быстро.
Повторяю, проблема только в том как хранить-манажить ето хозяйство ключей.
читаем там же -
В БД я хранить не хочу, т.к. я им потенциально могу воспользоваться.
Хранить в Апп, веб-сервере - сисадмины могут докопаться.
из чего видим, что ни к бд, ни к аппсерверу траста нет. соответсвенно plaintext'a там быть не может.
Marmot писал(а):
Plain data проходит через appserver и доходит до DB!
И это им подходит!
Им ключи надо спрятать, и всё.
похоже они сами не знают чего хотят
Marmot писал(а):
Ты мне объясни что твой прокси будет шифровать/расшифровывать?
HTTP?
HTML?
будет шифровать sensitive элементы (поля) протокола клиент-аппсервер. детали зависят от exact protocol layout .. может быть и html, может и http.
Marmot писал(а):
Тем более что у них HTTPS!
ну и ? в зависимости от положения прокси, будут либо две ssl сессии - клиент/прокси и прокси/backend, либо какая-то одна из них
