Чому скасували SSL сертифікати для IP і локальних доменів?
Рішення про припинення випуску SSL сертифікатів для доменів типу .local і для IP адрес було прийнято на Форумі авторизації та браузерів (CA / B Forum). Найголовніша мета центрів сертифікації при видачі SSL сертифікатів - забезпечити надійність і довіру шляхом прив'язування даних криптографічного публічного ключа до перевіреної особистості або компанії. SSL сертифікати ідентифікують комп'ютери в якості серверів, що пропонують один або кілька протоколів (зазвичай HTTP для веб трафіку, але також і SMTP, POP, IMAP, FTP, XMPP, RDP та інші) через SSL / TLS. Сервер може бути доступний по ряду імен або адрес. Сервер, підключений до мережі Інтернет, як правило, має власне ім'я в системі доменних імен DNS (від Domain Name System), що дозволяє будь-якій іншій системі в Інтернеті перетворити це ім'я в IP адреса і отримати доступ до сервера. Для прикладу візьмемо сервер з доменним ім'ям "server1234.emaro-ssl.ru". Ця система має маршрутизациї IP адреса в мережі Інтернет - IPv4 або IPv6, або ж обидва. Проте сервери можуть мати додаткові імена і адреси, які діють тільки в контексті локальної мережі, а не в усьому Інтернеті. Таким чином, той же сервер з прикладу вище може бути доступний іншим комп'ютерам в локальній мережі по іменах "mail" або "mail.local". Локальне ім'я домену може перетворюватися в маршрутизациї IP адреса в мережі Інтернет або в Ip адреса, доступний тільки по локальній мережі. Простір IP адрес "192.168. *. *", Які використовують багато домашні інтернет-шлюзи, можливо, є найбільш відомою серією особистих мережевих адрес. Але також існує безліч просторів IP адрес IPv4 і IPv6, зарезервованих для приватного або іншого використання. Ключовим відмінністю між цими двома типами доменних імен і IP адрес є їх унікальність. П олностью певний ім'я домену (FQDN), як, наприклад, "www.emaro-ssl.ru" являє собою унікальну і легко відрізнити від інших одиницю в Інтернеті (навіть якщо кілька серверів дадуть відповідь на це доменне ім'я, керувати ним може тільки одна особа ). У той же час, на невизначений ім'я домену "mail" можуть відповідати тисячі систем в публічних і приватних (локальних) мережах. В мережі Інтернет тільки один вузол зв'язку має IP адреса "5.63.155.56", в той час як десятки тисяч домашніх інтернет-шлюзів мають адресу "192.168.0.1". SSL сертифікати від довірених центрів сертифікації видаються з тією метою, щоб забезпечити безпеку і довіру для доменних імен по всій мережі Інтернет. Неунікальні доменні імена за самою своєю природою не можуть бути ідентифіковані поза свого локального контексту, тому SSL сертифікати, видані для локальних доменів, є потенційно небезпечними, так як можуть бути використані в шахрайських цілях. Саме з цієї причини центри сертифікації відмовляються від випуску SSL сертифікатів для неунікальний доменів і IP адрес, як "mail", "mail.local" або "192.168.0.1".Чому небезпечно використовувати SSL сертифікати для локальних доменів і IP адрес?
Для прикладу візьмемо компанію, яка розгорнула систему електронної пошти за адресою "https: // mail /". Система недоступна через всесвітню мережу Інтернет, а тільки по локальній корпоративної мережі або через VPN. Чи є вона безпечною? Не обов'язково, якщо є SSL сертифікат для доменного імені "mail" від довіреної центру сертифікації. Ім'я домену "mail" - унікальні, тому практично будь-хто може може отримати SSL сертифікат для "https: // mail /". Якщо зловмисник використовує такий сертифікат в корпоративної локальної мережі разом зі Спуфінга локального імені, він зможе без проблем підмінити справжній сервер корпоративної електронної пошти та отримати дані користувача для входу в систему та іншу конфіденційну інформацію. При цьому шахраєві навіть не обов'язково перебувати в корпоративній мережі, щоб успішно провести атаку. Якщо користувач підключить свій корпоративний ноутбук до публічної мережі WiFi, поштовий клієнт може автоматично спробувати підключитися до "https: // mail /" перш, ніж буде встановлено з'єднання через VPN. У цей момент зловмисник може зробити підміну і вкрасти дані користувача. Тут слід зауважити, що не має значення, чи використовувався SSL сертифікат від відомого довіреної центру сертифікації (як Comdo, Thawte, Symantec і інші), або ж самоподпісанний SSL сертифікат від приватного корпоративного центру сертифікації. Якщо між SSL сертифікатом, використовуваним шахраєм, буде встановлена ланцюжок з центром сертифікації в сховище браузера або операційної системи, сертифікат буде прийнятий усіма клієнтами, створюючи вразливість навіть на стороні користувачів приватної інфраструктури приватних ключів (PKI). Через те, що неможливо провести повноцінну перевірку локальних доменів і IP адрес, а також з-за високої можливості використання таких SSL сертифікатів в шахрайських цілях, Форум ЦС і Браузерів прийняв рішення про припинення їх видачі.Які є альтернативи?
1. Використовувати повністю певні доменні імена (FQDN) і пошук DNS суфікса домена. Багато сайтів, доступні по локальному імені домена, можуть також бути доступними і правильно визначатися по FQDN, так як програмне забезпечення DNS-клієнта використовує процес званий пошуком суфікса, при якому налаштовані суфікси додаються до локального імені та в результаті є повністю певний домен FQDN. Як правило, це відбувається автоматично для доменів, частиною яких є система. Наприклад, система з ім'ям "client.example.com" використовує "example.com" в якості суфікса для пошуку. Намагаючись встановити зв'язок з ім'ям "server", ця система буде автоматично пробувати знайти "server.example.com" через DNS пошук. Пошук DNS суфікса домена можна налаштувати самостійно. Якщо Ви використовуєте домен .local для внутрішньої мережі, цей спосіб Вам не підійде, рекомендуємо розглянути наступний. 2. Використовувати приватні або корпоративні центри сертифікації для підпису сертифікатів для IP адрес і локальних доменів. Другим можливим способом вирішення проблеми з випуском SSL сертифікатів для локальних доменів є створення власної системи PKI з локальним центром сертифікації. Створити його можна, наприклад, за допомогою OpenSSL, для якого існує безліч інструкцій в Інтернеті. У мережі Microsoft Windows Active Directory Network можна конфігурувати сервер Windows Server як корпоративний центр сертифікації і налаштувати автоматичне прийняття сертифікатів клієнтами. 3. Вручну підтверджувати довіру до самоподпісанного сертифікатами. У невеликих некерованих мережах можна приймати самоподпісанного сертифікати вручну. Той же OpenSSL дозволяє згенерувати SSL сертифікат самому. Якщо Ви користуєтеся сервером Microsoft IIS, Ви можете скористатися нашою інструкцією по створення SSL сертифікату . Якщо кількість користувачів сервісу з самоподпісанного сертифікатом невелика, вони можуть вручну приймати ці сертифікати, попередньо перевіривши міститься в них інформацію.Чому скасували SSL сертифікати для IP і локальних доменів?Які є альтернативи?
Чому скасували SSL сертифікати для IP і локальних доменів?
Чому небезпечно використовувати SSL сертифікати для локальних доменів і IP адрес?
Чи є вона безпечною?
Які є альтернативи?