Что имя хоста должно сертификат SSL для сервера SMTP содержать?
И https и VPN создают туннель SSL, использование обоих избыточно. Используйте VPN, если необходимо предоставить доступ сотрудников к другим сетевым ресурсам, как доля файла.
На работе мы используем HTTPS с сертификатом, который стоит нам 30$ в год. Я настоятельно рекомендую использование CA, поскольку оно мешает нападениям на MITM.
На самом деле это нигде явно не определено, и то, должен ли сервер быть «доверенным», зависит от подключающегося к нему клиента (который, конечно, может быть другим почтовым сервером); цитата из соответствующего RFC ( RFC 2487 ):
Если клиент SMTP решает, что уровень аутентификации или
конфиденциальность недостаточно высока для продолжения работы, ДОЛЖЕН выдать
Команда SMTP QUIT сразу после завершения согласования TLS.
Если SMTP-сервер решит, что уровень аутентификации или
конфиденциальность недостаточно высока для продолжения, СЛЕДУЕТ ответить на
каждая команда SMTP от клиента (кроме команды QUIT) с
код ответа 554 (с возможной текстовой строкой, например «Команда
отказано из-за отсутствия безопасности »).Решение о том, следует ли верить подлинности
другая сторона в согласовании TLS - это вопрос местного значения. Однако некоторые
общие правила для решений:- SMTP-клиент, вероятно, захочет аутентифицировать только SMTP сервер, сертификат сервера которого имеет доменное имя, которое является доменное имя, к которому, по мнению клиента, он подключается.
В основном это означает, что когда сервер предлагает шифрование TLS с использованием данного сертификата, решение о его принятии или отказе полностью зависит от другой части, которая , вероятно, захочет, чтобы имя в сертификате было быть тем же самым, к чему он подключен, но вполне может принять это, даже если он не совпадает.
Но подождите, это еще не все. Цитирую снова из того же RFC:
По завершении подтверждения TLS протокол SMTP сбрасывается на
начальное состояние (состояние в SMTP после того, как сервер выдает 220
готовое приветствие). Сервер ДОЛЖЕН отказаться от любых знаний
полученный от клиента, такой как аргумент команды EHLO,
который не был получен из самого согласования TLS. Клиент
ДОЛЖЕН отказаться от любых сведений, полученных с сервера, например от списка
расширений службы SMTP, которые не были получены от TLS
сами переговоры. Клиенту СЛЕДУЕТ отправить команду EHLO как
первая команда после успешного согласования TLS.
Итак, то, что сервер говорит в ответ на HELO / EHLO до рукопожатия TLS, похоже, вообще не имеет значения.
По моему опыту , самозаверяющие сертификаты довольно хорошо работают на почтовых серверах, выходящих в Интернет, а это означает, что другие почтовые серверы даже не утруждают себя проверкой их, они просто с радостью принимают все, что может обеспечить шифрование TLS, независимо от органа выдачи или имени субъекта.
MTA, доставляющий почту в ваш домен, будет искать запись MX (которая даст имя хоста), а затем искать запись A для этого имени хоста. Таким образом, имя хоста, к которому он подключается, является именем хоста MX, и это то, что будет проверяться по общему имени сертификата SSL. Проверка имени хоста HELO не имеет смысла, потому что сервер может предоставить любое имя хоста HELO по своему усмотрению - это не обеспечивает дополнительной безопасности.
Тем не менее, строгая проверка сертификатов SSL при доставке почты в настоящее время не особенно полезна , поскольку MTA (почти всегда) откатываются к доставке без SSL, поскольку именно так работает SMTP в настоящий момент. Поэтому разумной конфигурацией является использование SSL, если сервер MX предлагает его, независимо от того, проверяет ли сертификат SSL или нет (поскольку шифрование без аутентификации лучше, чем без шифрования и без аутентификации). Поэтому для этой цели можно использовать самоподписанный сертификат.
Если вы хотите выполнять поиск DNS по короткому имени (то есть не только по полностью определенным доменным именам), тогда вы находитесь в области /etc/resolv.conf и параметра 'search' .
подробности ищите в chris
man 5 resolv.conf
Когда соединение SSL / TLS инициируется заранее (SMTPS), сервер не имеет возможности увидеть, что говорится в сообщении HELO, до того, как соединение будет установлено, поэтому он должен использовать то соединение, с которым он сделал запрос.
При использовании SSL / TLS после STARTTLS клиент по-прежнему намеревается взаимодействовать с сервером, с которым он был настроен, так что это все еще то, что он должен проверить. В противном случае возможны атаки MITM:
- C-> S: Привет, я Алиса, я хочу поговорить с Бобом.
- S-> C: Привет, я Чак, вот мой сертификат для Чак.
- C-> S: О да, ваш сертификат действительно действителен для Чака. Давайте продолжим.
- ... В этом, конечно, есть изъян, так как Алиса хотела поэтому он должен использовать тот, с которым был сделан запрос.
При использовании SSL / TLS после
STARTTLSклиент по-прежнему намеревается разговаривать с сервером, с которым он был настроен, так что это все еще то, что он следует проверить. В противном случае возможны атаки MITM:- C-> S: Привет, я Алиса, я хочу поговорить с Бобом.
- S-> C: Привет, я Чак, вот мой сертификат для Чак.
- C-> S: О, да, ваш сертификат действительно действителен для Чака. Давайте продолжим.
- ... В этом, конечно, есть изъян, так как Алиса хотела поэтому он должен использовать тот, с помощью которого был сделан запрос.
При использовании SSL / TLS после
STARTTLSклиент по-прежнему намеревается взаимодействовать с сервером, с которым он был настроен, так что это все еще то, что он следует проверить. В противном случае возможны атаки MITM:- C-> S: Привет, я Алиса, я хочу поговорить с Бобом.
- S-> C: Привет, я Чак, вот мой сертификат для Чак.
- C-> S: О, да, ваш сертификат действительно действителен для Чака. Давайте продолжим.
- ... Здесь, конечно, есть изъян, так как Алиса хотела
- S-> C: Привет, я Чак, вот мой сертификат для Чака.
- C-> S: О да, ваш сертификат действительно действителен для Чака. Давайте продолжим.
- ... В этом, конечно, есть изъян, так как Алиса хотела
- S-> C: Привет, я Чак, вот мой сертификат для Чака.
- C-> S: О да, ваш сертификат действительно действителен для Чака. Давайте продолжим.
- ... В этом, конечно, есть изъян, так как Алиса хотела связь с Бобом.
В обоих случаях должен использоваться MX-адрес.
Правила сопоставления имен хостов недавно были собраны по протоколам в RFC 6125 , но лишь немногие клиенты реализуют их полностью (это скорее RFC передовой практики, чем полное изменение, и оно все еще совсем недавно).
В его приложении он суммирует то, что существовало до SMTP (взято из RFC 3207 ] и RFC 4954 ). В частности, « Клиент НЕ ДОЛЖЕН использовать любую форму имени хоста сервера, полученную из незащищенного удаленного источника (например, небезопасный поиск в DNS). » (что, конечно, относится к баннеру сервера). Помимо этого, устаревшие правила SMTP были немного более мягкими, чем HTTPS, в отношении альтернативных имен субъектов ( следует использовать вместо , необходимо использовать ).
Современный способ определенно состоит в том, чтобы поставить имя хоста в DNS-записи альтернативного имени субъекта. Использование подстановочных знаков также не рекомендуется .
При использовании шифрования SSL / TLS клиент всегда проверяет соответствие между "реальным" / "объявленным" именем хоста на удаленном компьютере и информацией, содержащейся в сертификате.
Так что вам, вероятно, следует установите foo.example.com или создайте сертификат с подстановочным знаком; -)
Думаю, что лучше всего будет скопировать то, что делается на практике. Я проверил адрес электронной почты yahoo.com, используя http://checktls.com Надеюсь, в yahoo они использовали другой домен для своего имени хоста и для своего домена mx. Итак, их имя хоста - yahoo.com, а их домен mx оканчивается на yahoodns.net
dig mx yahoo.com gives mta6.am0.yahoodns.net. among others
Результат проверки: сертификат SSL CN = домен MX (* .yahoodns.net)
Я сделал то же самое с cisco и i имел тот же результат.