LINUX.ORG.RU

Exim с поддержкой TLS и алгоритмов ГОСТ

 , ,


1

1

Уважаемые, прошу Вашего авторитетного мнения и совета.

Есть почтовый сервер exim-4.80.1 (НЕ в локальной сети, доступен всем в Интернете). Есть OpenSSL 1.0.1c.

Требование № 1

Что нужно: чтобы любой почтовый сервер, выступающий в роли клиента и устанавливающий SMTP-соединение с моим сервером exim всегда использовал шифрование. Только так и никак иначе. Клиенты без поддержки TLS и не имеющие сгенерированных пар ключей идут лесом.

Что сделал:

  1. Собрал exim с поддержкой TLS.
  2. В конфигурационном файле exim задал настройки
    tls_advertise_hosts = *
    tls_certificate = /etc/ssl/exim.crt
    tls_privatekey = /etc/ssl/exim.pem
    daemon_smtp_ports = 25 : 465
    tls_on_connect_ports = 465
    

Вопрос: достаточно ли этого и если нет, что ещё нужно сделать, чтобы принуждать клиентов шифровать соединение?

Требование № 2

Что нужно: чтобы абсолютно любой почтовый сервер, выступающий в роли клиента мог установить шифрованное соединение с сервером exim с использованием криптоалгоритмов AES и RSA и длиной ключей 512 бит и 1024 бита соответственно. Не важно, с кем устанавливается соединение, главное - чтобы оно было зашифрованным. Т.е. НЕ нужна двусторонняя аутентификация по сертификатам. Подлинность сертификата exim'а всё равно никто не сможет проверить (он будет самоподписанным), т.к. невозможно установить корневой (авторитативный) сертификат CA, которым мог быть подписан сертификат exim'а, на всех почтовых серверах Интернета в качестве доверенного.

Что сделал:

  1. Прочитал RFC 2246
  2. Прочитал, что такое гибридная криптосистема
  3. Прочитал, что такое криптоалгоритм RSA
  4. Прочитал, что такое криптоалгоритм AES

Нифига не понял.

Вопросы:

  1. Нужно ли (и как) настраивать openssl (или сам exim с поддержкой TLS) для реализации требования?
  2. Как заставить использовать симметричный алгоритм AES (а не 3DES, IDEA или любой другой) и асимметричный алгоритм RSA (а не Диффи-Хеллмана или любой другой)?
  3. Как установить длину 512 бит для сеансового ключа AES, который генерируется автоматически при каждом новом соединении?

Требование № 3

Что нужно: чтобы шифрование соединения осуществлялось по криптоалгоритмам ГОСТ 28147-89 (для симметричного шифрования - сеансовый ключ) и ГОСТ Р 34.10-2001 (для асимметричного шифрования с функцией хэширования по ГОСТ 34.11-94) - если клиенты это поддерживают. Если поддержки ГОСТ у клиентов нет, то шифровать алгоритмами, указанными в требовании № 2.

Что сделал:

  1. Включил поддержку ГОСТ в openssl
    openssl ciphers -v | grep GOST
    GOST2001-GOST89-GOST89  SSLv3 Kx=unknown  Au=unknown Enc=unknown   Mac=unknown
    GOST94-GOST89-GOST89    SSLv3 Kx=unknown  Au=unknown Enc=unknown   Mac=unknown
    
  2. Сгенерировал сертификат и закрытый ключ по алгоритмам ГОСТ.

Вопросы:

  1. Достаточно ли того, что сертификат и закрытый ключ сгенерированы по ГОСТ 34.10-2001, чтобы сеансовый симметричный ключ автоматически генерировался openssl по алгоритму ГОСТ 28147-89 (а не AES или любой другой) и если нет, что нужно для этого сделать?
  2. Как заставить exim определять, поддерживает ли клиент ГОСТ и на основании этого подсовывать клиенту тот или другой сертификат? В настройках exim, если я не ошибаюсь, возможно указание директивы tls_privatekey только один раз (а надо хотябы два!).

Благодарю, если дочитали до этого места! :-)



Последнее исправление: cetjs2 (всего исправлений: 2)

Подлинность сертификата exim'а всё равно никто не сможет проверить (он будет самоподписанным), т.к. невозможно установить корневой (авторитативный) сертификат CA, которым мог быть подписан сертификат exim'а, на всех почтовых серверах Интернета в качестве доверенного.

Какой тогда смысл в шифровании соединения?

Deleted
()

Т.е. НЕ нужна двусторонняя аутентификация по сертификатам. Подлинность сертификата exim'а всё равно никто не сможет проверить (он будет самоподписанным)

Можно просто отрубить шифрование, по сути безопасности мало что изменится: если кому-то надо будет прослушать трафик, то проблем не возникнет никаких вообще.

Как заставить использовать симметричный алгоритм AES (а не 3DES, IDEA или любой другой) и асимметричный алгоритм RSA (а не Диффи-Хеллмана или любой другой)?

Чтобы RSA работал, нужно сгенерить RSA private key нужного размера, сертификат на его основе, и последний раздавать клиентам.

Как заставить exim определять, поддерживает ли клиент ГОСТ и на основании этого подсовывать клиенту тот или другой сертификат? В настройках exim, если я не ошибаюсь, возможно указание директивы tls_privatekey только один раз (а надо хотябы два!).

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

Судя по объему требуемых ssl-настроек и костылей имеет смысл использовать (написать) какой-то frontend ssl-сервер, специализируется на этом, а exim поднять на 127.0.0.1 порту без шифрования.

shahid ★★★★★
()
Последнее исправление: shahid (всего исправлений: 1)

Клиенты без поддержки TLS и не имеющие сгенерированных пар ключей идут лесом.

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

дальше не читал.

Spoofing ★★★★★
()
Ответ на: комментарий от Spoofing

тоже свой сервер, на локалхосте, на своем домене. из-за этой фигни я не смог получить письма от github и яндекса

Очевидно автору глубоко плевать на письма от каких-то там github и яндексов

af5 ★★★★★
()
Последнее исправление: af5 (всего исправлений: 1)

Благодарю всех за участие.

В пятничном (20.09.2013) вечернем выпуске Вестей (Россия 1), в, якобы, очередном разоблачении от Сноудена, озвучили то, что многи знали или предполагали: США сертифицировали средства криптографической защиты информации для мобильных платформ (читай для iOS и Android) с преднамеренно заложенными возможностями, позволяющими их спецслужбам расшифровать передаваемые данные. И это помимо того, что iOS и так по своей концепции является средством добровльно-принудительного контроля владельцев телефонов (теперь ещё и отпечатки пальцев собирает).

Какие мысли от всего этого и Ваших, уважаемые, комментариев появляются...

1. Из-за наличия недокументированных возможностей в сертифицированных в США программных реализациях американских криптоалгоритмов в конкретных продуктах с закрытым кодом (в мобильных платформах, в браузерах - IE, FF, Google Chrome на ОС Windows и т.д.), для криптографической защиты информации в личных (параноидальных) интересах имеет смысл использовать ПО с открытым исходным кодом (OpenSSL и GNU TLS). Конечно, желательно в этот код периодически заглядывать!
Интересная статья, пишут о способах внедрения недекларированных возможностей и немного о порядке сертификации СКЗИ в РФ.

2. Если исходить из того, что мы - НЕ криптоаналитики - доверяем опубликованной технической информации о криптостойкости американских алгоритмов шифрования (речь именно об алгоритмах, а не о сертифицированном ПО с реализованными в нём алгоритмами), вовсе не обязательно для обмена почтой использовать отечественный ГОСТ (но желательно из патриотических соображений).

3. Учитывая, что упомянутые крупные публичные сервисы github и яндекс (а также великое множество «релеев») не обременяют себя принудительным шифрованием SMTP-соединений, невозможно обеспечить конфиденциальность, целостность и доступность почтовых сообщений в процессе их передачи от сервера к серверу. Т.е. либо не шифруем соединение и обмениваемся почтой по всему Интернету без ограничений, либо шифруем соединение, но ограничиваемся лишь определённым числом доверенных почтовых серверов в корпоративной среде (и применяем аутентификацию по сертификатам).

Вопрос:
Имеет ли смысл организовывать сеть из частных почтовых серверов с перспективой её роста (яндекс, видимо, тоже наращивал свои мощности постепенно, начав с минимальных)?

roga_i_kopita
() автор топика
Ответ на: комментарий от roga_i_kopita

Как я это вижу:

Арендовать виртуальный или организовать собственный физический сервер.
На нём создать центр сертификации.
На нём подписывать запросы на выпуск сертификатов для частных почтовых серверов и выкладывать подписанные сертификаты для скачивания.
На нём хранить список FQDN частных почтовых серверов подключенных к сети, который постоянно обновляется и который доступен для скачивания держателям частных почтовых серверов через предварительно подключенный у них репозиторий.
На нём поднять web-сервер со страничкой, призывающей присоединяться к сети частных почтовых серверов, объясняющей, зачем это нужно, как настроить и как подать заявку на подпись сертификата.
На нём хранить сертификат CA, который также через репозиторий распространять на частные почтовые серверы в качестве доверенного корневого сертификата.
На нём хранить и постоянно обновлять список отзыва сертификатов, который также распространять через репозиторий.

Держатели частных почтовых серверов устанавливают у себя корневой сертификат CA.
Ежедневно скачивают через репозиторий обновлённый список отзыва сертификатов.
Генерируют пары ключей и запросы на подпись собственного сертификата.
Отправляют через форму на сайте сгенерированные запросы, там же скачивают уже подписанные сертификаты.
Ежедневно скачивают через репозиторий обновлённый список FQDN частных почтовых серверов и скармливают его своему серверу.
Для примера:
в конфигурационном файле exim есть параметр tls_advertise_hosts, который задаёт список хостов, которые надо принуждать к шифрованию соединения.
Вот этому параметру и нужно ежедневно передавать обновлённый список FQDN частных почтовых серверов.

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

roga_i_kopita
() автор топика
Ответ на: комментарий от roga_i_kopita

Что этим достигаем.

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

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

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

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

Что скажете? Только культурно, без матерщины! :-)

roga_i_kopita
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.