Зашифрованный текст на сервере - PullRequest
2 голосов
/ 25 ноября 2011

Существуют ли какие-либо протоколы, которые позволили бы двум посетителям безопасно общаться через мой веб-сайт, не позволяя мне читать их сообщения?

Ответы [ 4 ]

3 голосов
/ 25 ноября 2011

Запросите у Google сквозное шифрование, например, PGP / GPG. Для клиентской реализации на основе браузера вы можете проверить шифрование GPG в JavaScript .

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

РЕДАКТИРОВАТЬ: Похоже, действительно отправляет закрытый ключ клиента на ваш сервер для выполнения шифрования на основе сервера. Это не , что вы хотите. Но я уверен, что реализация GPG на JavaScript возможна, хотя я не знаю, сделал ли это кто-то еще.

2 голосов
/ 25 ноября 2011

Если мы говорим о , невозможном , то вторая часть ответа С.Л.Барта достигнет этого, за исключением того, что обмен ключами должен быть выполнен другими способами.Это может быть телефон, электронная почта или даже другой веб-сайт, но если это происходит через ваш веб-сайт, то он открыт для атаки человек посередине .Вы можете сказать своим пользователям сделать это, но вы просто не можете помочь им сделать это.

Возможно, где-то есть библиотека javascript, которая будет реализовывать шифрование GPG, так что все, что вам нужно сделать, это убедиться, что каждыйсообщение зашифровано в браузере перед отправкой на ваш веб-сервер.Вы можете хранить сообщения сколько угодно, они зашифрованы.Только пользователь с правильным закрытым ключом сможет дешифровать его.

SSL и TLS, так как они используются веб-сайтами повсеместно, уязвимы для атак «человек посередине».Причина, по которой мы мало слышим об атаках такого рода, заключается в том, что большинство людей в центре заслуживают доверия, поэтому атаки просто не происходят.Недавний отзыв сертификатов CA DigiNotar и других произошел именно потому, что правительство Ирана было поймано на роли посредника и расшифровывании трафика SSL своего гражданина.

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

Еще одна вещь: безопасность - это сложно.

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

2 голосов
/ 25 ноября 2011

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

Участники также могут просто зашифровать свои сообщения открытым ключом предполагаемого получателя. Таким образом, только предполагаемый получатель может расшифровать сообщение. Это не очень продвинутая схема и, вероятно, уязвимая. (Среди прочего, если перехватчик может угадать в точности что отправлено, он может зашифровать это сообщение с помощью открытого ключа предполагаемого получателя и посмотреть, соответствует ли результат тому, что отправляется).

Существует множество литературы по криптографическим протоколам; для начала, вот статья в Википедии о протоколах соглашения о ключах .

0 голосов
/ 25 ноября 2011

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

Это может быть общий секрет (например, фраза-пароль) или открытый ключ, известный одному (или сертифицированный CA, известной одному), где другой имеет соответствующий закрытый ключ.

На этомможет создать безопасный протокол (используя обмен ключами и затем симметричное шифрование с MAC в обоих направлениях), как это делает TLS.(Другим способом, часто используемым для обмена мгновенными сообщениями, является OTR, протокол сообщений об отсутствии записи .)

Без способа определить другую конечную точку, вы получитеспособ разрешения атак «человек посередине».SSL / TLS без сертификатов или с сертификатами, в которых посредник знает соответствующий закрытый ключ, небезопасен, как и любая другая подобная схема шифрования.

Другая проблема заключается в том, что вы сказали посетители моего сайта .Похоже, что вы реализовали бы клиентскую криптографию в JavaScript, поставляемую с вашего сайта.Не делайте этого ... если посетители не доверяют вам не читать их данные, они также не должны доверять вам, чтобы они передавали им не злонамеренный JavaScript, который может реализовывать нечто иное, чем вы утверждаете, снова позволяяMITM, или даже прямая отправка вам копии данных.

Более подробная информация об этом обсуждается в Криптография Javascript Считается вредной (с несколько иной точки зрения).

...