<
  • Главная
Статьи

SSL-сертифікати Web-сайтів і їх застосування: Частина 3. Використання SSL-сертифікатів для захисту електронної пошти

  1. Серія контенту:
  2. Цей контент є частиною серії: SSL-сертифікати Web-сайтів і їх застосування
  3. Використання SSL-сертифікатів в sendmail
  4. Лістинг 1. Зміни в файлі конфігурації sendmail.cf для включення SSL
  5. Лістинг 2. Приклади умов для контролю доступу
  6. Підключення SSL-сертифікатів до IMAP-сервера dovecot
  7. Лістинг 3. Активація SSL-сертифікатів на сервері dovecot
  8. Лістинг 4. Повідомлення в журналі dovecot про успішну перевірку сертифіката
  9. Лістинг 5. Повідомлення про відмову в отриманні пошти
  10. Активація SSL-сертифікатів на стороні клієнта
  11. Малюнок 1. Імпорт сертифіката в Thunderbird
  12. Малюнок 2. Видавець сертифіката невідомий
  13. Малюнок 3. Зміна параметрів ключа корпоративного CA
  14. Малюнок 4. Налаштування безпечного з'єднання з сервером в Opera Mail
  15. висновок
  16. Ресурси для скачування

SSL-сертифікати Web-сайтів і їх застосування

Серія контенту:

Цей контент є частиною # з серії # статей: SSL-сертифікати Web-сайтів і їх застосування

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: SSL-сертифікати Web-сайтів і їх застосування

Слідкуйте за виходом нових статей цієї серії.

Захист інформації, що передається по протоколах SMTP / POP3 / IMAP, які зазвичай називають одним словом "електронна пошта", є однією з найважливіших задач при побудові безпечної корпоративної мережі. І хоча фактично тут вирішується кілька завдань - захист сервера електронної пошти, який працює по протоколу SMTP і захист клієнтів електронної пошти, що використовують протокол POP3 / IMAP, всі вони зводяться вони до однієї: як зробити так, щоб сторонні не могли прочитати передаються (приймаються) повідомлення . В даній статті розповідається, як організувати захист електронної пошти і як переконатися, що побудована система працює саме так, як потрібно.

Використання SSL-сертифікатів в sendmail

Часто використовувані скорочення.

  • SSL - рівень захищених сокетів (secure socket layer);
  • CA - засвідчує центр (center of authority);
  • CSR - запит на сертифікацію (certificate signing request);
  • CRL - список відкликаних сертифікатів (certificate revocation list);
  • PKCS - криптографічні стандарти з відкритим ключем (public-key cryptography standards);
  • CN - загальні дані (common name).

Припустимо, є якийсь віддалений клієнт, що працює на мобільному комп'ютері з різних точок підключення. Для даного клієнта потрібно забезпечити безпечний прийом повідомлень через порт 22000 і відправку пошти через порт 22001 з використанням протоколу SSL. Нестандартні значення портів вибираються для того, щоб не порушувалося функціонування серверів, що працюють на стандартних портах електронної пошти.

Для вирішення цього завдання спочатку потрібно згенерувати два CSR і підписати в корпоративному CA два сертифіката (розгортання CA обговорювалося в першій статті даного циклу) - один SSL-сертифікат для сервера і один SSL-сертифікат для клієнта. В Інтернет є безліч описів процесу настройки SSL для sendmail, але все автори повторюють одну і ту ж помилку, так як вважають, що достатнього одного сертифіката. Як показує практика - необхідно два сертифікати.

Після створення сертифікатів повинні з'явитися чотири файли: server.crt / server.key (сертифікат і ключ сервера) і client.crt / client.key (сертифікат і ключ клієнта). Передбачається, що всі артефакти, пов'язані з SSL, лежать в каталозі / etc / ssl, в тому числі сертифікати - в підкаталозі certs, кореневі сертифікати та інше - в підкаталозі rootca, а сертифікат самого CA знаходиться в файлі caserv.crt. Тоді в файл sendmail.cf слід додати рядки, наведені в лістингу 1.

Лістинг 1. Зміни в файлі конфігурації sendmail.cf для включення SSL

define ( `confCACERT ',` / etc / ssl / rootca / caserv.pem') define ( `confCACERT_PATH ',` / etc / ssl / rootca') define ( `confCLIENT_CERT ',` / etc / ssl / certs / Сlient. crt ') define ( `confCLIENT_KEY',` / etc / ssl / certs / client.key ') define ( `confSERVER_CERT',` / etc / ssl / certs / server.crt ') define ( `confSERVER_KEY',` / etc /ssl/certs/server.key ') define ( `confCRL',` / etc / ssl / rootca / cacrl.crl ') DAEMON_OPTIONS ( `Family = inet, Port = 22000, Name = TLS-MTA, M = asv' ) DAEMON_OPTIONS ( `Family = inet, Port = 25, Name = MTA, M = A ')

Параметри confCACERT і confCACERT_PATH визначають шлях до сертифіката СА і шлях до каталогу, який буде проглядатися при пошуку сертифікатів додаткових CA. Параметри confCLIENT_CERT і confCLIENT_KEY - це сертифікат і ключ, які будуть використовуватися sendmail, коли він буде виступати в якості клієнта. А значення параметрів confSERVER_CERT і confSERVER_KEY будуть використовуватися sendmail при роботі в режимі сервера. У параметрі confCRL визначається файл, який містить СRL. Рядки DAEMON_OPTIONS задають порти, на які будуть прийматися SSL-з'єднання і звичайні з'єднання. Визначення стандартного порту (25) необхідно, так як при оголошенні DAEMON_OPTIONS в sendmail повністю відключаються значення за замовчуванням, і прослуховуватися будуть тільки порти, описані в параметрах. Команда M в рядку DAEMON_OPTIONS встановлює різні настройки для sendmail. У першому рядку значення asv активує таких дій: пропонувати авторизацію, пропонувати STARTTLS і запитувати сертифікат клієнта, а другий варіант A не вимагає авторизації. Більш докладно параметри DAEMON_OPTIONS описуються в документації sendmail.

Власником файлів з сертифікатами і ключами обов'язково повинен виступати користувач root, а повноваження для них повинні бути встановлені в 0400, в іншому випадку sendmail почне виводити повідомлення про помилку при спробі використовувати дані файли.

Після перезапуску sendmail в ньому з'явиться можливість використовувати для перевірки подключающегося клієнта додаткові макроси, пов'язані з сертифікатами. Ця перевірка виконується шляхом занесення різних умов, пов'язаних з TLS_Srv або TLS_Clt (в залежності від того працює sendmail в режимі сервера або клієнта), в файл / etc / mail / access, як показано в лістингу 2.

Лістинг 2. Приклади умов для контролю доступу

TLS_Srv: one.box.com ENCR: 128 TLS_Clt: two.box.com VERIFY TLS_Srv: three.box.com PERM + VERIFY: 256

У першому випадку доступ буде надано, якщо між sendmail і підключаються клієнтом one.box.com може бути встановити безпечний зв'язок з довжиною ключа не менше 128 біт. У другому, якщо sendmail, що підключається до сервера two.box.com, пройде перевірку сертифікатів. У третьому, якщо між клієнтом three.box.com і сервером sendmail можна встановити захищене з'єднання з довжиною ключа не менше 256 біт, і клієнт пройде перевірку сертифікатів (якщо в ході перевірки виникає помилка - то виводиться постійна помилка, а без вказівки параметра PERM виводиться тимчасова помилка). Більш докладно умови перевірки описуються в документації sendmail.

Окремо слід сказати про перевірку сертифікатів. Перш ніж використовувати будь-які перевірочні вираження в файлі / etc / mail / access, необхідно переконатися, що сертифікат вдалося успішно перевірити. Це відбивається рядком verify = OK в журнальному файлі sendmail, як показано нижче:

Apr 12 2:08:28 mail sm-mta [39653]: STARTTLS = server, relay = plu-dc1.plu.int [192.168.111.4], version = TLSv1 / SSLv3, verify = OK, cipher = DHE-RSA- CAMELLIA256-SHA, bits = 256/256.

Якщо було надруковано verify = OK, значить, sendmail зміг перевірити сертифікат, переданий клієнтом. Для цього необхідно, щоб сертифікат клієнта був підписаний або файлом, зазначеним в параметрі confCACERT, або одним з файлів, що знаходяться в каталозі, визначеному в параметрі confCACERT_PATH. Якщо ж verify приймає інше значення (FAIL, NO, NONE і т.д., повний перелік значень і їх розшифровка наведені в документації sendmail), то використовувати перевірочні вираження, засновані на сертифікатах, у файлі / etc / mail / access не має сенсу , так як будь-яка перевірка буде блокувати доступ.

Підключення SSL-сертифікатів до IMAP-сервера dovecot

Після захисту процесу відправки повідомлень необхідно забезпечити безпечне отримання пошти. Для даної операції зазвичай використовується протокол IMAP / POP3. Як приклад у статті розглядається настройка одного з найбільш популярних серверів - dovecot.

Як завжди для реалізації політики безпеки потрібно сертифікат, при цьому створювати новий не обов'язково, можна використовувати вже наявний сертифікат, створений для sendmail. Також знадобиться сертифікат CA, Об'єднанням з CRL (то, що іноді називають "Об'єднання контрольний файл"), який повинен знаходитися в файлі camerged.pem. Налаштування dovecot потрібно змінити, як показано в лістингу 3.

Лістинг 3. Активація SSL-сертифікатів на сервері dovecot

/usr/local/etc/dovecot/conf.d/10-auth.conf auth_ssl_require_client_cert = yes /usr/local/etc/dovecot/conf.d/10-ssl.conf ssl = required ssl_cert = </ etc / ssl / certs / server.crt ssl_key = </etc/ssl/certs/server.key ssl_ca = </etc/ssl/rootca/camerged.pem ssl_verify_client_cert = yes ssl_cipher_list = HIGH: MEDIUM: EXP:! aNULL: + SHA1: + MD5 : + HIGH: + MEDIUM: + EXP /usr/local/etc/dovecot/conf.d/10-master.conf service imap-login {inet_listener imap {port = 143} inet_listener imaps {port = 22001 ssl = yes}

У лістингу 3 наведено настройки, які необхідно додати в конфігураційні файли dovecot. У файл 10-auth.conf додається єдина зміна - вимога сертифіката клієнта.

У файлі 10-ssl.conf вказується, що SSL обов'язковий для запуску служби (ssl = required), а також сертифікат і ключ сертифіката (ssl_cert, ssl_key) і сертифікат СА і CRL даного CA. Як правило, якщо в програмі відсутній окремий параметр для вказівки CRL, то програма очікує, що CRL знаходиться в файлі з сертифікатом СА. Також в файлі 10-ssl.conf активується обов'язкова перевірка клієнтського сертифіката (ssl_verify_client_cert) і перераховується перелік алгоритмів, які можна використовувати. Опис допустимих значень для параметра ssl_cipher_list можна переглянути в документації на модуль Apache mod_ssl, в якому використовується аналогічний формат.

У файлі 10-master.conf вказується порт, на якому dovecot братиме захищені з'єднання. Після вказівки всіх налаштувань процес отримання пошти клієнтом буде виглядати наступним чином:

  1. клієнт звертається на вказаний порт;
  2. сервер запитує сертифікат клієнта;
  3. клієнт передає сертифікат, сервер його перевіряє;
  4. якщо перевірка успішна, клієнт отримує пошту, якщо ж ні - отримує повідомлення про відмову.

Вся інформація про хід процесу отримання пошти вперше в журнал dovecot, як показано в лістингу 4:

Лістинг 4. Повідомлення в журналі dovecot про успішну перевірку сертифіката

Apr 12 00:13:12 mail dovecot: imap-login: Valid certificate: / C = RU / ST = Novosibirskaya / L = Novosibirsk / O = LLC "SheltonSoft Inc." / OU = IT department / CN = master.sheltonsoft. ru/[email protected] Apr 12 00:13:12 mail dovecot: imap-login: Valid certificate: / C = RU / ST = Novosibirskaya oblast '/ L = Novosibirsk / O = LLC "Horns and Foots "/ OU = IT department / CN = Rashid N. Achilov/[email protected] Apr 12 00:13:12 mail dovecot: auth: Debug: client in: AUTH 1 PLAIN service = imap secured valid-client-cert cert_username = Rashid N. Achilov lip = 192.168.100.100 rip = 192.168.111.4 lport = 143 rport = 4248

У першому рядку наводяться дані сертифіката СА, в другій - дані сертифіката клієнта. У лістингу 5 наведено повідомлення про спробу невдалого підключення.

Лістинг 5. Повідомлення про відмову в отриманні пошти

Apr 12 11:37:39 mail dovecot: auth: Debug: client in: AUTH 1 PLAIN service = imap secured lip = 192.168.100.100 rip = 192.168.111.4 lport = 143 rport = 4417 Apr 12 11:37:39 mail dovecot: auth: PLAIN (?, 192.168.111.4): Client did not present valid SSL certificate Apr 12 11:37:39 mail dovecot: auth: Debug: client out: FAIL 1 reason = Client did not present valid SSL certificate

В даному випадку була спроба підключення без пред'явлення сертифіката, що неприпустимо.

Активація SSL-сертифікатів на стороні клієнта

На останньому етапі залишається налаштувати програми на стороні клієнта і переконатися в тому, що все працює саме так, як було задумано. У даній статті в якості поштової програми використовується Mozilla Thunderbird.

Як завжди, буде потрібно клієнтський сертіфкат, підписаний корпоративним CA. Поле Email в цьому сертифікаті має точно відповідати адресою електронної пошти, для захисту якого буде використовуватися даний сертифікат, в іншому випадку сертифікат не буде виявлений в процесі підключення або не пройде перевірку при відправці листа. Процес створення клієнтських сертифікатів описувався в першій статті циклу, тому передбачається, що вже є готовий файл з сертифікатом PKCS # 12 client_cert.p12. Так як Mozilla Thunderbird використовує окреме сховище сертифікатів, то сертифікат буде потрібно попередньо встановити в це сховище.

Для установки сертифіката слід вибрати меню Інструменти-> Параметри облікового запісі-> захист-> Перегляд сертифікатів і натиснути кнопку Імпортувати. Після стандартного діалогу вибору файлу і запиту пароля для обраного PKCS архіву з'явиться повідомлення про завершення імпорту, і сертифікат буде відображатися в списку, як показано на малюнку 1.

Малюнок 1. Імпорт сертифіката в Thunderbird
SSL-сертифікати Web-сайтів і їх застосування   Серія контенту:   Цей контент є частиною # з серії # статей: SSL-сертифікати Web-сайтів і їх застосування   https://www

Однак якщо відразу після імпортування сертифіката спробувати отримати пошту, то буде виведено повідомлення "Видавець сертіфката невідомий", зображене на малюнку 2.

Малюнок 2. Видавець сертифіката невідомий

Ця помилка пояснюється тим, що при установці ключа СА в Thunderbird не було вказано, якими правами володіє даний ключ, і тому ніяких прав у CA немає. В меню Інструменти-> Параметри облікового запісі-> захист-> Перегляд сертифікатів необхідно вибрати Центри сертифікації та змінити параметри імпортованого корпоративного СА, як показано на малюнку 3.

Малюнок 3. Зміна параметрів ключа корпоративного CA

Налагодження підключення до певного порту виконується через меню Інструменти-> Параметри облікового запісі-> Параметри сервера. Необхідно встановити дійсні значення для імені і порту сервера, імені користувача, а для захисту з'єднання вибрати SSL / TLS.

Налаштування порту для відправки пошти виконується через меню Параметри облікового запісі-> Сервер вихідної пошти. Також вказується ім'я сервера і порт, а спосіб захисту з'єднання встановлюється в STARTTLS. Якщо sendmail, що відправляє пошту на сервері, підтримує аутентифікацію, то буде потрібно ще вказати ім'я користувача, в іншому випадку можна вибрати метод аутентифікації - Без аутентифікації.

На відміну від Firefox, в Thunderbird ніяк не означає, що прийом і передача пошти відбувається по захищеному з'єднанню. Також можна використовувати і інші клієнти електронної пошти, наприклад Opera Mail. Попередньо необхідно буде встановити сертифікат корпоративного СА, так як інакше буде виводитися повідомлення про невідомого видавця сертифіката.

Як і у випадку з Thunderbird, потрібно додати сертифікат (при цьому додавання сертифіката корпоративного СА може і не знадобитися - це варто перевірити окремо), а потім налаштувати прийом і відправку пошти в захищеному режимі. В Opera Mail це робиться через меню Tools (Інструменти) -> Mail and Chat Accounts (Облікові записи електронної пошти та конференцій) -> Manage Accounts (Служба захисту) -> Edit (Редагування), де у властивостях облікового запису на закладці Servers ( сервери) вказуються параметри сервера. Opera Mail здатна сама визначити деякі параметри.

Малюнок 4. Налаштування безпечного з'єднання з сервером в Opera Mail

При установці персонального сертифіката слід врахувати, що Opera більш вимоглива до правильності складання сертифіката і, якщо поле Еmail, вказане в налаштуваннях властивостей облікового запису, не буде відповідати полю Email з сертифіката, то сертифікат просто не буде встановлено.

висновок

Захист корпоративної пошти - завдання непросте і, безперечно, одна з найбільш важливих для функціонування захищеної корпоративної мережі. Слід уважно ставитися до видачі сертифікатів, і там, де це можливо, використовувати додаткові перевірки - sendmail AUTH і обмеження за параметрами сертифіката, а також використовувати нестандартні номери портів і своєчасно оновлювати CRL, оскільки за замовчуванням сервера для обробки електронної пошти не володіють подібною функціональністю.

Ресурси для скачування

Схожі теми

  • SSL-сертифікати Web-сайтів і їх застосування. Частина 1 .
  • SSL-сертифікати Web-сайтів і їх застосування. Частина 2 .
  • SSL-сертифікати Web-сайтів і їх застосування. частина 3 .

Підпишіть мене на повідомлення до коментарів

Com/developerworks/ru/library/?


Новости
  • Виртуальный хостинг

    Виртуальный хостинг. Возможности сервера распределяются в равной мере между всеми... 
    Читать полностью

  • Редизайн сайта

    Редизайн сайта – это полное либо частичное обновление дизайна существующего сайта.... 
    Читать полностью

  • Консалтинг, услуги контент-менеджера

    Сопровождение любых интернет ресурсов;- Знание HTML и CSS- Поиск и обновление контента;-... 
    Читать полностью

  • Трафик из соцсетей

    Сравнительно дешевый способ по сравнению с поисковым и контекстным видами раскрутки... 
    Читать полностью

  • Поисковая оптимизация

    Поисковая оптимизация (англ. search engine optimization, SEO) — поднятие позиций сайта в результатах... 
    Читать полностью