Настройка почтового SSL-сертификата | ISPserver

Как установить ssl-сертификат на почтовый домен?

2 securing the mail server in plesk

Ask your hosting provider if they have secured the Plesk mail server with a valid SSL/TLS certificate
(not with the self-signed SSL/TLS certificate that secures the mail server by default).
This encrypts the connection between the Plesk mail server and senders’ MTA
protecting emails you receive from being intercepted.

However, unless you are paying for a dedicated server, there is a shortcoming.
Each time you access your mailbox, you see a warning message about an untrusted SSL/TLS certificate.
It happens because the mail client detects a mismatch between the domain name to which the certificate is assigned
(the domain name of the Plesk server) and the domain name of mail.
As a result, most mail clients consider the mail server certificate not trusted.

If you use the Postfix and Dovecot mail clients (in Plesk for Linux) and MailEnable (in Plesk for Windows),
you can fix the certificates’ mismatch by assigning a SSL/TLS certificate to your individual mail for a domain.

For other mail clients (for example, qmail or Courier),
there is currently no ability to assign a separate SSL/TLS certificate for your individual mail for a domain.
Whether the connection to the mail server is secured or not depends on how your mail client handles untrusted certificates:

• The mail client connected to the mail server via SSL/TLS (even though a warning that a certificate is not trusted may be shown).
  In this case, the connection between your mail and a sender is encrypted and transferred emails are protected from being intercepted.
• The mail client refused to connect to the mail server via SSL/TLS and you had to use an unencrypted connection.
  In this case, your transferred emails become vulnerable to interception.
  We recommend that you change your mail client to one that allows connecting via SSL/TLS even if the certificate is not trusted.

3 assigning an ssl/tls certificate to mail for a domain

If you use the Postfix and Dovecot mail clients (in Plesk for Linux) and MailEnable (in Plesk for Windows),
you can secure mail for a domain with an individual SSL/TLS certificate.
We recommend that you do so if your mail client shows a warning that the SSL/TLS certificate securing the mail server cannot be verified.

Once you secure mail for a domain with an individual SSL/TLS certificate,
the mail server will return the certificate securing your mail instead of the server-wide certificate assigned by your hosting provider.
As the result, the warning will not be shown anymore.

Note: An SSL/TLS certificate securing mail for a domain encrypts the connection
only if the Plesk mail server is also secured with an SSL/TLS certificate.
Ask your hosting provider if they have secured the Plesk mail server with a valid SSL/TLS certificate.

To secure mail for a domain with an SSL/TLS certificate:

1. Get a wildcard SSL/TLS certificate or a SAN certificate that allows to configure mail.<domain> in SAN.
   You can do so by:

   Note: If you have already got a wildcard SSL/TLS certificate when securing webmail,
   go to step 2 to secure mail for your domain with this certificate.

   Note: We recommend getting a free wildcard SSL/TLS certificate from Let’s Encrypt
   because this certificate can single-handedly protect not only mail for a domain,
   but also webmail, the domain itself, and multiple subdomains (if necessary).

2. Go to Mail > the “Mail Settings” tab, click the domain name, select the SSL/TLS certificate for mail,
   and then click OK.

Аутентификация клиента (двусторонний TLS)

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

client-auth

, сообщив серверу о том, что ему нужно проверять клиентов.

Приведём файл сервера application.yml к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    client-auth: need

Если после этого запустить клиент, то он выдаст следующее сообщение об ошибке:

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

Это указывает на то, что клиент не обладает подходящим сертификатом. Точнее — у клиента пока вообще нет сертификата. Поэтому создадим сертификат следующей командой:

keytool -v -genkeypair -dname "CN=Suleyman,OU=Altindag,O=Altindag,C=NL" -keystore client/src/test/resources/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias client -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Нам ещё нужно создать TrustStore для сервера. Но, прежде чем создавать это хранилище, нужно иметь сертификат клиента. Экспортировать его можно так:

keytool -v -exportcert -file client/src/test/resources/client.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret -rfc

Теперь создадим TrustStore сервера, в котором будет сертификат клиента:

keytool -v -importcert -file client/src/test/resources/client.cer -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

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

Приведём файл application.yml клиента к такому виду:

client:
  ssl:
    one-way-authentication-enabled: false
    two-way-authentication-enabled: true
    key-store: identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: truststore.jks
    trust-store-password: secret

Сервер тоже не знает о только что созданном для него TrustStore. Приведём его файл

application.yml

к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: classpath:truststore.jks
    trust-store-password: secret
    client-auth: need

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

Примите поздравления! Только что вы настроили двусторонний TLS!

Замена неподписанного сертификата подписанным

В хранилище идентификационных данных сервера и клиента всё ещё хранится неподписанный сертификат. Сейчас можно заменить его на подписанный. У инструмента

keytool

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

identity.jks

Экспортируем подписанный сертификат:

keytool -v -exportcert -file root-ca/root-ca.pem -alias root-ca -keystore root-ca/identity.jks -storepass secret -rfc

Выполним на клиенте следующие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret -noprompt
keytool -v -importcert -file client/src/test/resources/client-signed.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret
keytool -v -delete -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret

На сервере выполним такие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret -noprompt
keytool -v -importcert -file shared-server-resources/src/main/resources/server-signed.cer -alias server -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret
keytool -v -delete -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret

Включение ssl шифрования для dovecot

Настройка dovecot для шифрования схожа с postfix.

Вначале делаем самоподписанный сертификат с помощью openssl:

# openssl req -new -x509 -days 365 -nodes -out /etc/ssl/certs/dovecotcert.pem -keyout /etc/ssl/private/dovecotkey.pem

Эта команда затребует создание нового сертификата X.509, действительного 365 дней. -nodes это опция, которая говорит, что частный ключ не должен быть зашифрован. Файл сертификата будет сохранён как dovecotcert.pem, а файл ключа будет иметь имя dovecotkey.pem.

Заполняем данные для сертификата (можно писать что угодно, либо просто оставлять строки пустыми):

Country Name (2 letter code) [AU]:TH
State or Province Name (full name) [Some-State]:Chonburi
Locality Name (eg, city) []:Pattaya
Organization Name (eg, company) [Internet Widgits Pty Ltd]:codeby.net
Organizational Unit Name (eg, section) []:Example.tst
Common Name (e.g. server FQDN or YOUR name) []:mail.example.tst
Email Address []:[email protected]

Далее, прописываем пути к сертификатам в настройках dovecot.

[email protected]:~# vim /etc/dovecot/conf.d/10-ssl.conf

ssl = no
меняем на
ssl = yes
И добавляем следующие строки:
ssl_cert = </etc/ssl/certs/dovecotcert.pem
ssl_key = </etc/ssl/private/dovecotkey.pem

Наконец, перезапускаем dovecot для включения SSL с новыми сертификатами.

[email protected]:~# service dovecot restart

Проверяем открытые порты, теперь должен быть полный набор.

[email protected]:/etc/dovecot/conf.d# netstat -nat
tcp 0 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp 0 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp 0 0 0 0.0.0.0:995 0.0.0.0:* LISTEN

Включение tls шифрования для postfix

Самоподписанный сертификат может быть создан следующей командой.

# openssl req -new -x509 -days 365 -nodes -out /etc/ssl/certs/postfixcert.pem -keyout /etc/ssl/private/postfixkey.pem

Вышеприведённая команда затребует новый сертификат, тип которого X.509, и который будет валидным на протяжении 365 дней. Необязательный параметр -nodes определяет, что частный ключ не должен быть зашифрованным. Созданный файл сертификат будет сохранён как postfixcert.pem, а файл ключа как postfixkey.pem .

При создании сертификата будут запрошены данные:

Country Name (2 letter code) [AU]:TH
State or Province Name (full name) [Some-State]:Chonburi
Locality Name (eg, city) []:Pattaya
Organization Name (eg, company) [Internet Widgits Pty Ltd]:codeby.net
Organizational Unit Name (eg, section) []:Example.tst
Common Name (e.g. server FQDN or YOUR name) []:mail.example.tst
Email Address []:[email protected]

Можно всё красиво и правильно ввести, но правда жизни такова, что эти данные ни на что не влияют. Их не смотрят ни люди, ни программы. Вместо ввода данных можно просто каждый раз нажимать [Enter].

Теперь, когда сертификаты готовы, необходимы внести нужные настройки в файл конфигурации postfix.

[email protected]:~# vim /etc/postfix/main.cf

### STARTTLS включён ###
smtpd_tls_security_level = may

smtpd_tls_received_header = yes
smtpd_tls_auth_only = yes

### loglevel 3 может быть использован для решения проблем ###
smtpd_tls_loglevel = 1

### путь до сертификата и ключевого файла
smtpd_tls_cert_file = /etc/ssl/certs/postfixcert.pem
smtpd_tls_key_file = /etc/ssl/private/postfixkey.pem
smtpd_use_tls=yes

Перезапускаем postfix для включения TLS.

[email protected]:~# service postfix restart

Уже сейчас postfix готов для шифрования данных при передачи их с/на сервер. Дополнительные подробности о поддержке Postfix TLS можно найти в официальном README.

Как импортировать и экспортировать сертификат (цифровой идентификатор) в outlook?

Какие виды ssl-сертификатов есть и кто их выдаёт?

Есть специальные центры сертификации или как ещё называют — удостоверяющие центры (УЦ). Вы могли встречать названия таких УЦ: Symantec, Comodo, GlobalSign, Thawte, GeoTrust, DigiCert. Они подтверждают подлинность ключей шифрования с помощью сертификатов электронной подписи.

Кроме того, есть проекты, CloudFlare или LetsEncrypt, где можно получить сертификат бесплатно и самостоятельно. Такой сертификат выпускается на 3 месяца и далее требует продления. Однако во время их установки и дальнейшей работы есть ряд нюансов, которые стоит учитывать.

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

Печать доверия — это особый знак, позволяющий посетителям видеть, что соединение с вашим сайтом и все передаваемые данные надёжно защищены.

Итак, существует несколько типов SSL-сертификатов по источнику подписи и типу проверки данных.

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

• Подписанные доверенным центром сертификации (валидные). Речь о тех самых авторитетных УЦ выше. Сертификат корректно отображается во всех браузерах. Данные сертификата проверены и подтверждены в сертифицирующем центре.

Так вот, разница между самоподписанными сертифкатами и, выданными УЦ, как раз и заключается в том, что браузер знаком с УЦ и доверяет ему, и при использовании такого сертификата ваш посетитель никогда не увидит огромное уведомление о небезопасности ресурса. Купить такой SSL-сертификат можно как напрямую в УЦ, так и через хостинг-провайдеров.

Подписанные доверенным центром сертификаты, в свою очередь, тоже подразделяются по типу проверки данных:

• DV (Domain Validation) — базовый уровень сертификата, который обеспечивает только шифрование данных, но не подтверждает существование организации. Такие бюджетные сертификаты подойдут физическим и юридическим лицам.
• OV (Organization Validation) — обеспечивает не только шифрование данных, но и подтверждает существование организации. Такие сертификаты доступны только для юридических лиц.
• EV (Extended Validation) — это эффективное решение с самым высоким классом защиты, которое активно применяется в онлайн-бизнесе. Для оформления требуется пройти процедуру расширенной проверки, подтвердить законность организации и право собственности на домен.

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

• WildCard — защищает соединение с доменом и всеми его поддоменами.
• SAN — защищает домены по списку, указанному при получении SSL-сертификата.

Настройка шифрования почты в the bat.

Как настроить шифрование почты (S/MIME) в The Bat . Это продолжение статьи Защита электронной почты. Шифрование почты. Получение сертификата.

The Bat поддерживает две технологии защиты информации: PGP и PKI (S/MIME). В этой статье речь пойдет только о технологии PKI (S/MIME).

Подразумевается, что сертификат для шифрования почты уже получен.

Загружаем Bat, открываем настройки шифрования в меню Свойства -> Настройки S/MIME и TLS… Здесь перед нами встает выбор: использовать внутреннюю реализацию S/MIME или Microsoft CryptoAPI. При выборе внутренней реализации сертификаты будут находиться в хранилище Bat.

Импорт/экспорт сертификатов будет осуществляться через интерфейс Bat. Также для корректной работы потребуется импорт корневых сертификатов и внесение их в список доверенных. При выборе Microsoft CryptoAPI используется хранилище сертификатов Windows.

Импорт/экспорт осуществляется через стандартные процедуры операционной системы. Лично я считаю этот вариант более удобным. Однако, если вы работаете в Windows XP, и вам нужен максимальный уровень безопасности, в этом случае следует использовать криптопровайдер Bat.

Он обеспечивает лучший набор алгоритмов шифрования по сравнению с стандартным Microsoft Enhanced Cryptographic Provider v1.0 (доступны алгоритмы AES 128 и 256-бит). В Vista добавлена встроенная поддержка AES, поэтому данная рекомендация относиться только к XP.

Для начала рассмотрим настройку с помощью Microsoft CryptoAPI (Win XP).

Использование Microsoft CryptoAPI

В списке криптопровайдеров выбираем Microsoft Enhanced Cryptographic Provider v1.0 (как обеспечивающий наилучшее шифрование). В списке также присутствует Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype), однако, с его помощью зашифровать письмо у меня не получилось (вместо AES 256-бит, письмо зашифровывалось алгоритмом RC2).

Использовать это криптопровайдер не рекомендую. Алгоритм шифрования: 3DES. Хеш-алгоритм подписи: SHA-1. Отмечаем опции “Помнить связи e-mail адресов с сертификатами для подписи” и “Помнить связи e-mail адресов с сертификатами для шифрования”.

Импорт сертификата из подписанного письма. Выделяем письмо, далее в меню Инструменты -> Криптография и безопасность -> Импортировать ключ (сертификат). Откроется мастер импорта сертификатов. Нажимаем Далее. В следующем окне оставляем выбранной опцию “Автоматически выбрать хранилище на основе типа сертификата” и Далее.

Настройка шифрования с помощью внутреннего криптопровайдера Bat.

Использование внутреннего криптопровайдера Bat

Алгоритм шифрования выбираем: AES (256-бит). Хеш-алгоритм подписи: SHA-1.

Следующий этап – импорт сертификата вашего почтового ящика в хранилище Bat. Если вы следовали предыдущей статье, то ваш сертификат находится в хранилище Windows из которого его надо предварительно экспортировать. Если же у вас уже есть файл сертификата в формате PKCS#12 (.PFX), то вы можете сразу перейти к разделу Импорт сертификата.

Экспорт сертификата Открываем Панель управления -> Свойства обозревателя -> вкладка Содержание -> кнопка Сертификаты Переходим на закладку Личные, выделяем нужный сертификат, нажимаем кнопку Экспорт. Откроется мастер экспорта сертификатов.

Нажимаем Далее. В следующем окне необходимо выбрать опцию “Да, экспортировать закрытый ключ”, нажимаем Далее. Выбор формата файла сертификата. Оставляем значения по умолчанию: файл обмена личной информацией – PKCS#12 (.PFX), опция “Усиленная защита” включена.

Нажимаем Далее. Вводим пароль закрытого ключа. Этот пароль будет запрашиваться каждый раз при доступе к закрытому ключу. Т.е. каждый раз при расшифровке/зашифровке письма (учтите это). Можно ввести пустой пароль, но это сильно понизит уровень безопасности. Далее выбираем имя и расположение экспортируемого файла. Нажимаем Далее и затем Готово.

Импорт сертификата Открываем Адресную книгу и создаем контакт для СВОЕГО адреса e-mail. Если включен внутренний криптопровайдер Bat, то в адресной книге будет доступна вкладка Сертификаты. Открываем ее и нажимаем кнопку Импортировать. Выбираем сохраненный сертификат. Появится окно для ввода пароля закрытого ключа:

Импорт сертификата в хранилище Bat

Вводим пароль. Появится похожее окно, в него опять вводим тот же пароль. После этого в списке сертификатов должен появится новый сертификат.

Теперь двойным щелчком открываем его. Если в сведениях о сертификате будет надпись – “Этот S/MIME сертификат недействителен”, в этом случае необходимо добавить корневой сертификат в список доверенных. Для этого открываем вкладку Путь сертификации:

Добавление корневого сертификата в список доверенных

Выделяем корневой сертификат (в примере AAA Certificate Services) и нажимаем кнопку Добавить к доверенным. На вопрос, действительно ли мы хотим это сделать, отвечаем Да. На этом импорт сертификата завершен.

Импорт сертификата из подписанного письма. Выделяем письмо, далее в меню Инструменты -> Криптография и безопасность -> Импортировать ключ (сертификат). После этого появится сообщение о количестве импортированных сертификатов (может быть более одного, если импортируются отсутствующие вышестоящие сертификаты).

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

Теперь мы готовы к отправке подписанных и/или зашифрованных сообщений.

Зашифровать/подписать письмо можно с помощью соответствующих кнопок на панели инструментов в окне создания письма. Расшифровка письма/проверка подлинности подписи выполняется с помощью значка в виде письма в правом верхнем углу окна просмотра сообщения.

Странность Bat. Я так и не нашел где можно узнать с помощью какого алгоритма зашифровано письмо… Непонятно…

источник

Планирование сертификата для exchange

Угрозы и средства защиты

Далее мы рассмотрим матрицу угроз (табл. 2), но сначала предлагаем вам ознакомиться с общей таблицей преимуществ и недостатков каждого средства защиты электронной почты.

Таблица 1. Сравнительная таблица средств защиты почты

При построении таблицы 2 мы взяли за основу матрицу угроз проекта HushMail, дополнили ее и можем использовать для сравнения описанных в таблице средств защиты электронной почты. Номер средства в этой таблице соответствует номеру средства в таблице 1.

Таблица 2. Сравнение средств защиты электронной почты в разрезе матрицы угроз

Прокомментируем данную таблицу на примере средств защиты PGP Desktop и Huhsmail (колонки 1 и 3). Поскольку шифрование осуществляется на стороне клиента, то программа PGP Desktop защищает вашу переписку от прослушивания Интернет-соединения. Что же касается HushMail, приходится полагаться только на SSL.

Но такую защиту предлагает и gmail и если вас в первую очередь интересует именно защита от «прослушки» Интернет-соединения, то можно вообще не использовать какие-либо средства защиты. Однако на сайте HushMail указано, что сервис защищает от прослушки, поэтому в таблице указано «Да».

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

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

Чего не скажешь о HushMail. Да, от прослушки спасает протокол SSL, а «внутри него» данные передаются в открытом виде, пока не происходит шифрование на самом сервере. Поэтому веб-сервер обладает полным доступом к данным. Это и есть ответ на вопрос, как администрация HushMail смогла предоставить доступ к переписке при судебном разбирательстве.

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

Зато оба средства защиты уязвимы при использовании keylogger. Если злоумышленник перехватит ваши пароли (в частности, от сертификатов), то вам уже ничто не поможет. Разве что переход на токены вместо ввода паролей. Все остальные средства защиты используют шифрование на стороне клиента, поэтому им не страшен ни перехват, ни доступ к вашему почтовому ящику — сообщения будут зашифрованы.

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

Кстати, нужно сделать важное замечание относительно S/MIME, а именно почему при правильном использовании S/MIME может не помочь даже «кейлоггер». Если ключ добавлен в хранилище, как не экспортируемый (что, кстати и делает CyberSafe Top Secret), то у злоумышленника ничего не выйдет. Именно поэтому на данный момент S/MIME можно считать самым надежным способом защиты электронной почты.

Общая информация о средствах защиты электронной почты приводится в таблице 3.

Таблица 3. Сводка по средствам защиты электронной почты

Шифрование почты в outlook 2021

Выводы

Самый простой способ защиты электронной почты — это использование симметричного шифрования. Для его реализации можно использовать плагины браузера SecureGmail и Encrypted Communication или вообще обойтись без них, а использовать программы, позволяющие создавать архивы, защищенные паролем (например, WinRAR, 7-Zip). Расчет прост: вы защищаете архивом файл, помещаете в него сообщение с возможными вложениями и отправляете другому человеку.

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

Более надежная система асимметричного шифрования. Она реализована множеством самых разных способов. Можно использовать стандарт S/MIME (что позволяет использовать асимметричную криптографию даже на мобильных устройствах), можно использовать PGP и производные продукты (OpenPGP, PGP Mail, GnuPG).

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

Универсальность заключается в том, что один раз создав свой сертификат, вы можете использовать его в любых почтовых клиентах (разумеется, с поддержкой S/MIME), а также в любых операционных системах, в которых работают эти почтовые клиенты. Например, вы можете сгенерировать сертификат Windows-программой, установить его в Outlook и в мобильном почтовом клиенте MailDroid.