Яке ім'я хоста має містити сертифікат SSL для SMTP-сервера?

У мене є сервер foo.example.com за адресою 192.0.2.1

Він отримує електронну пошту для отримання декількох моїх доменів.

Кожен з моїх доменів має запис MX, що вказує на mx.example.com, який дорівнює 192.0.2.1

Якщо я хочу зробити exim пропозицію шифрування TLS для вхідних електронних повідомлень, яке ім'я хоста слід ввести у сертифікат SSL?

• foo.example.com, тому що сервер скаже у HELO?
• mx.example.com, оскільки це ім'я хоста, до якого будуть підключені клієнти?

http://www.checktls.com припускає, що остання правильна, але я не можу знайти остаточної відповіді.

Це насправді ніде не визначено чітко, і те, чи слід «довіряти» серверу, залежить від клієнта (який, звичайно, може бути іншим поштовим сервером), який підключається до нього; цитуючи відповідну RFC ( RFC 2487 ):

Якщо клієнт SMTP вирішить, що рівень аутентифікації та
конфіденційності недостатньо високий, щоб він міг продовжуватись, він повинен видавати
команду SMTP QUIT одразу після завершення узгодження TLS.
Якщо сервер SMTP вирішить, що рівень аутентифікації або
конфіденційності недостатньо високий, щоб він міг продовжуватися, він повинен відповідати на
кожну команду SMTP від ​​клієнта (крім команди QUIT) з
кодом відповіді 554 (з можливим текстовим рядком, таким як "Команда
відмовилася через відсутність безпеки").

Рішення про те, вірити чи ні в автентичність
іншої сторони в переговорах про TLS, є місцевим питанням. Однак деякі
загальні правила прийняття рішень:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

Що це в основному означає, що коли сервер пропонує шифрування 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 (оскільки шифрування без автентифікації краще, ніж без шифрування та без автентифікації). Тому ви можете також використовувати для цього підписаний сертифікат.

Завдання перевірки серверного сертифіката та відповідності йому імені хоста сервера є суто роллю клієнта для будь-якого протоколу, що використовує SSL / TLS.

Отже, ім'я хоста в сертифікаті повинно відповідати імені, до якого намагається отримати доступ клієнт.

Коли з'єднання SSL / TLS ініціюється вперед (SMTPS), сервер не може бачити, що говорить повідомлення HELO до встановлення з'єднання, тому він повинен використовувати той, з яким він зробив запит.

Під час використання SSL / TLS після STARTTLSцього клієнт все ще має намір поспілкуватися з сервером, на якому він був налаштований, тому це все ще слід перевірити. Якщо цього не вдалося зробити MITM-атаками:

• C-> S: Привіт, я Аліса, я хочу поговорити з Боб.
• S-> C: Привіт, я Чак, ось мій черт для Чака.
• C-> S: О так, ваш серт справді дійсний для Чака. Давайте продовжимо.
• ... Звичайно, тут є вада, оскільки Аліса хотіла безпечного спілкування з Боб.

В обох випадках слід використовувати MX-адресу.

Нещодавно правила узгодження імен хостів були зібрані в протоколах RFC 6125 , але мало клієнтів реалізують його повністю (це більше краща практика RFC, ніж повна зміна, і це все ще зовсім недавно).

У додатку він підсумовує те, що існувало про SMTP раніше (взято з RFC 3207 та RFC 4954 ). Зокрема, " Клієнт НЕ повинен використовувати будь-яку форму імені хоста сервера, отриману з незахищеного віддаленого джерела (наприклад, незахищений пошук DNS). " (Що, звичайно, стосується банера сервера). Крім цього, правила успадкованих SMTP були трохи більш розслабленим , ніж HTTPS щодо Subject Alternative Names ( слід замість повинні бути використані).

Сучасний спосіб, безумовно, вводити ім'я хоста у запис DNS з альтернативним іменем теми. Використання шаблонів також не рекомендується .

Я думаю, що найкраще було б скопіювати те, що робиться на практиці. Я перевірив адресу електронної пошти 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, і у мене був такий же результат.

Під час шифрування SSL / TLS клієнт завжди перевіряє відповідність між "реальним" / "оголошеним" іменем хоста на віддаленій машині та інформацією, що міститься в сертифікаті.

Отже, вам, мабуть, слід встановити foo.example.com або створити сертифікат підстановки ;-)