Достаточно ли практично шифрование электронной почты?


9

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

Есть ли кто-нибудь, кто имеет опыт работы с безопасностью электронной почты? Это легко настроить? И можете ли вы по-прежнему отправлять и получать электронную почту от всех своих друзей и знакомых?

Ответы:


12

Очень к сожалению: нет.

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

Чтобы шифрование почты было практичным, почтовый клиент должен иметь возможность:

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

Но большая проблема здесь - инфраструктура. Чтобы это произошло, должно быть:

  1. Широко используемый, стандартный способ публикации открытого ключа, связанного с адресом электронной почты (и этот метод должен быть защищен с помощью системы сертификатов, чтобы третье лицо не могло слишком легко с ним связываться).
  2. Широко используемый стандартный способ автоматического создания закрытого ключа для адреса электронной почты и его хранения на удаленном сервере, доступным стандартным способом. Предпочтительно, чтобы этот сервер был частью обычной службы от поставщика электронной почты. Адрес этого сервера будет затем вводиться как обычная процедура в настройках учетной записи почтового клиента, точно так же, как в настоящее время вводятся входящие и исходящие почтовые серверы, после чего клиент может обрабатывать все проблемы с ключами.

Другая проблема заключается в том, что большинству почтовых клиентов придется уметь обрабатывать расшифровку, а большинству поставщиков электронной почты придется предоставлять ключевую услугу, чтобы система была эффективной. Шифрование нуждается в полной поддержке на обоих концах связи. Но я не вижу в этом большой проблемы. Если на некоторых клиентах и ​​серверах появится простой и практичный стандарт , они могут объявить «мы поддерживаем стандарт безопасной электронной почты», а другие, вероятно, последуют его примеру.

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

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

Честно говоря, я действительно не знаю, почему этого еще не произошло. Это не так сложно. Получить с этим уже!


2
Отличный ответ; Я думаю, что вы в значительной степени понимаете причины, почему это сейчас не очень распространено. (Несколько лет назад я сильно увлекся PGP / GPG, и мне очень понравилось, например, встроенная поддержка KMail. Но даже у меня, будучи студентом CS, было очень мало людей, с которыми я мог бы зашифровать обмен электронной почтой. Как вы говорите, мы нужно, чтобы большинство людей пользовалось клиентами, которые полностью его поддерживают и т. д.)
Jonik

1
Хороший ответ! «Я действительно не знаю, почему этого еще не произошло»: потому что большинство людей не заботятся о конфиденциальности. Достаточно взглянуть на интернет, где люди публикуют каждую деталь своей жизни.
Дмитрий С.

@Dimitri: Да, к сожалению, вы, вероятно, правы. Но даже если пользователям все равно, я бы надеялся, что инфраструктура и люди, занимающиеся разработкой, будут. Система, которую я описал, была бы в значительной степени прозрачной для неосведомленного пользователя.
Илари Каясте

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

@salmonmoose: Да, электронная почта серьезно устарела, и передача SSL через все ссылки была бы хорошим дополнением. Тем не менее, это все же позволило бы почтовому серверу-посреднику читать электронные письма. С помощью системы, которую я описал, только провайдеры на обоих концах могли бы делать это, и даже это можно было бы предотвратить в одной и той же системе, если получатель прошел через настройку своего собственного файла / сервера закрытого ключа.
Илари Каясте

7

Да, это практично ( PGP не является тайной наукой), и это рекомендуется. И, конечно, вы все еще можете отправлять и получать незашифрованные письма.

И если вы ищете бесплатный безопасный веб-сервис электронной почты, зарегистрируйтесь с Hushmail .

Однако, если все это сделают, у некоторых агентств TLA очень скоро закончится финансирование :)


1
Мне нравится идея, однако ей нужна группа людей, которые на самом деле настроят PGP (например, какой смысл использовать видео-телефон, когда люди, которым я звоню, не имеют аппаратного обеспечения? Это меняется, но безопасная связь получит такую ​​популярность так быстро ?).
Ник

1
Я думаю, что идея PGP Signatures немного более практична, но она решает только проблему идентификации, а не решение проблемы конфиденциальности.
Ник

что вы имеете в виду, что это не решает проблему конфиденциальности? уберите эту шляпу из фольги, в PGP-шифровании нет бэкдора. :)

Подписание электронной почты - это не то же самое, что шифрование. Подписание решает проблему идентификации (кто ее отправил), но не хранит содержимое в секрете.
Майкл Кохн

Ключи PGP можно использовать для подписи сообщения, шифрования сообщения или для того и другого. Чтобы подписать сообщение для Боба, Алиса использует свой закрытый ключ, и Боб может проверить его, используя открытый ключ Алисы. Чтобы зашифровать сообщение для Боба, Алиса зашифрует его с помощью открытого ключа Боба, а Боб использует его личный ключ для его расшифровки. Большинство сообщений pgp сначала подписывают сообщение, а затем шифруют его, обеспечивая разумную гарантию подлинности и конфиденциальности сообщения.
Кек

6

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

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


1
это действительно недостаток, вы никогда не можете быть на 100% уверены, что ваш ключ был скомпрометирован или нет, если вы не договорились о личном обмене, где это применимо.

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

1
достаточно верно с точки зрения безопасности существуют определенные методы, которые близки (но НИКОГДА не равны) личному обмену ключами.

@Mnementh: Если вы собираетесь проводить личные встречи, вы можете просто использовать их для обмена ключами. Тогда вам не нужен сервер ключей. Серверы ключей хороши, но в конечном итоге вам приходится как-то доверять чему-то другому, чтобы использовать их. Вот где я нервничаю.
Майкл Кохн

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

4

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

Это не сложно, но убедить других установить и использовать его может быть сложно. Я знаю, что пытался некоторое время назад, и никто бы не последовал.


1
Вам не нужна другая сторона для установки вещей, но вы можете отправлять только зашифрованные письма другим пользователям, которые также устанавливают PGP / GPG. По крайней мере, вы можете отправить им подписанные письма. Но с установкой PGP / GPG вы ничего не теряете, а другие уже шифруют свои письма, теперь вы можете отправлять и зашифрованные письма.
Mnementh

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

Мне кажется, я видел скрипт Greasemonkey, который можно использовать для шифрования поля ввода текста в веб-приложении электронной почты. Или это был плагин Firefox? Зайдите в Google, если вам интересно. :-)
удалено

2

На мой взгляд, на данный момент S / MIME более практичен, чем PGP, потому что его модель доверия более четко определена, потому что он уже поддерживается популярными почтовыми клиентами и потому что распределение ключей встроено в протокол.

У PGP такая слабо определенная модель доверия, что рядовой пользователь не потрудится подписать свой ключ (или проверить отпечатки клавиш), и он станет бесполезным для проверки личности. Понятие PGP о «цепочке доверия» также начинает разрушаться в больших сообществах (например, в мире ), если нет достаточного количества людей, которые проводят свои жизни, путешествуя от ключевой подписывающей стороны к ключевой подписывающей стороне, объединяющей окрестности.

S / MIME с X.509 более практичен, потому что, как только вы подтвердите свою личность в центральной организации, такой как Thawte или CACert , ваш ключ сразу же будет доверен всем.

Мне нравится CACert прямо сейчас, потому что это некоммерческая организация, которая предлагает ключи бесплатно, но ее корень в настоящее время не распространяется на большинство компьютеров и веб-браузеров. В любом случае, установка рута намного проще, чем настройка и поддержка установки PGP.

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


2

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

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

Точно так же, если ваш собственный компьютер скомпрометирован, каждое электронное письмо, которое вы отправляете и / или получаете, может быть общедоступным.


Для обеспечения безопасности электронной почты ее нельзя хранить локально на стороне клиента.
Surfasb

@surfasb, уверен, что он может храниться локально ... в зашифрованном виде
JoelFan

1

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


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

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

1

Другим вариантом является Voltage SecureMail. Он использует Voltage IBE (Identity Based Encryption), который считается PKI следующего поколения, для которого не требуются сертификаты для открытого ключа ... только адрес электронной почты.

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

Получатели не нуждаются в специальном программном обеспечении для расшифровки и чтения своих сообщений. Это намного проще в использовании, чем PGP или SMIME и так же безопасно.

Попробуйте это по адресу: www.voltage.com/vsn


0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.