SSL + дополнительный уровень шифрования

Мне интересно, что делать, если клиент запрашивает второй уровень шифрования поверх SSL?

Например, у меня есть туннель SSL, и клиент хочет, чтобы я затем использовал шифрование с симметричным ключом для данных, проходящих через этот туннель. Симметричный ключ основан на сеансе и отправляется с сервера клиенту по исходному туннелю SSL.

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

Кто-нибудь может предложить разные точки зрения на эту ситуацию? Я уверен, что если бы заранее был установлен общий секрет (например, одноразовый пароль), это сделало бы вещи более безопасными, но поскольку секрет передается через сеанс через SSL, я не вижу как это дает нам дополнительную безопасность.

Что вы думаете, и был ли у вас подобный опыт?

Спасибо


person user146714    schedule 29.07.2011    source источник
comment
На самом деле такое требование не имеет смысла.   -  person Eugene Mayevski 'Callback    schedule 29.07.2011


Ответы (1)


Звучит как «следующая отличная идея» для клиентов, которые думают, что чтение «Моей первой криптовалюты» дает им возможность изобретать велосипед каким-то дьявольски остроумным способом :)

Обычно это ерунда, тем более что, как вы говорите, симметричный ключ отправляется.

Однако я могу придумать один сценарий, в котором это могло бы иметь смысл - многие крупные компании или учреждения имеют политики, запрещающие сквозные соединения SSL / TLS. В какой-то момент они завершают входящий TLS, чтобы иметь возможность сканировать текстовые данные на наличие вирусов и т. Д. В таком случае имеет смысл дополнительно зашифровать данные на уровне приложения, чтобы предотвратить внутреннее прослушивание.

Но опять же, вы, скорее всего, нарушите внутренние правила ...

person emboss    schedule 31.07.2011
comment
спасибо за двойную проверку. Я полагаю, что это могло бы сделать систему более безопасной, если бы симметричный ключ не отправлялся по каналу, а был жестко закодирован как общий секрет. или если он работал аналогично одноразовому паролю - person user146714; 01.08.2011
comment
@ user146714: вы можете использовать новый обмен ключами Диффи-Хеллмана по вашему каналу TLS, а затем зашифровать с помощью этого нового ключа (который никогда не отправляется). - person Paŭlo Ebermann; 08.08.2011
comment
Была такая же идея. Если есть несколько пользователей, которые имеют доступ к удаленному сокету, и вы хотите защитить свое сообщение от чтения некоторыми из них, для меня это имеет смысл. Как сказал user146714, я бы не отправил симметричный ключ с сообщением, а использовал бы его как свой секрет шифрования / дешифрования. - person bijan; 28.05.2013