Чи може Https працювати без сертифіката?

Нещодавно наша інфраструктурна команда сказала нашій команді розробників, що вам не потрібно сертифікат для https. Вони зазначили, що єдиною перевагою придбання сертифіката було надання споживачу спокою, що вони підключаються до правильного веб-сайту.

Це суперечить усім, що я припускав про https.

Я читаю wikipedia, і в ній згадується, що вам потрібен або довірений сертифікат, або самопідписаний сертифікат для налаштування https.

Чи можна настроїти IIS відповідати на https без будь-якого сертифіката?

Ні. Ви повинні мати сертифікат. Він може бути самостійно підписаний, але для обміну даними сеансу між сервером і клієнтом повинна бути пара публічних / приватних ключів.

Коротше кажучи, ні, але можуть бути тонкі випадки залежно від способу розгортання системи.

HTTPS - це HTTP через SSL / TLS, і ви можете використовувати SSL / TLS без сертифіката або з сертифікатами інших типів, ніж X.509 .

• Анонімні набори шифрів: вони можуть забезпечити шифрування, але без автентифікації. Щодо безкорисності, що стосується безпеки ... Цитуючи RFC 4346 : " анонімний Діффі-Хеллман сильно зневірився, оскільки він не може запобігти атакам " людиною в середині ".
• Попередньо розділені ключі : у нього є власний механізм перевірки віддаленої ідентичності, але спільний характер ключів приносить свій набір проблем (зокрема обмежене розгортання).
• Набір шифрів Kerberos : клієнт може перевірити особистість сервера щодо основного імені Kerberos.

Строго кажучи, специфікація HTTP over TLS говорить наступне:

Взагалі, HTTP / TLS-запити генеруються шляхом перенаправлення URI. Як наслідок, ім'я хоста для сервера відоме клієнту. Якщо ім'я хоста доступне, клієнт ОБОВ'ЯЗКОВО його перевіряє на предмет ідентичності сервера, як це представлено у повідомленні Сертифіката сервера, щоб запобігти атакам "посередника".

Якщо клієнт має зовнішню інформацію щодо очікуваної ідентичності сервера, перевірку імені хоста МОЖЕ бути пропущено. (Наприклад, клієнт, можливо, підключається до машини, адреса та ім'я хоста якої є динамічними, але клієнт знає сертифікат, який подасть сервер.) У таких випадках важливо максимально звузити область прийнятних сертифікатів у щоб запобігти людині в середині нападів. В особливих випадках клієнту може бути доречно просто ігнорувати особу сервера, але слід розуміти, що це залишає з'єднання відкритим для активної атаки.

Коротше кажучи, він чітко призначений для використання з сертифікатом X.509 (він чітко посилається на RFC 2459, пізніше замінений RFC 3280 та 5280: PKI з сертифікатами X.509).

Під час використання пакетів шифрів Kerberos може бути певний випадок. Можливо, має сенс ставитися до сервісного квитка Kerberos сервера, якщо він може вважати таким же призначенням, як сертифікат X.509 у звичайних HTTPS, для перевірки особи віддаленої сторони. Це не зовсім вписується в правила RFC 2818 (хоча може потрапити під " Якщо клієнт має зовнішню інформацію щодо очікуваної ідентичності сервера, перевірка імені хоста МОЖЕ бути пропущена "), але це не було б абсолютно абсурдно. З цього приводу я не думаю, що звичайні браузери взагалі підтримують шифрові набори TLS Kerberos (кількість може підтримувати Kerberos за допомогою аутентифікації SPNEGO, але це не пов'язано). Крім того, це також працює лише в умовах, коли використання Kerberos підходить.

" [Даючи] спокій споживачам, що вони підключаються до правильного веб-сайту " - це насправді одна з ключових вимог щодо забезпечення зв'язку між ними та вашим сервером. Використовуйте сертифікат, який вони можуть підтвердити, за допомогою відповідних умов іменування (RFC 2818 або останнім часом RFC 6125).

Ви не можете використовувати https без будь-якого сертифіката. Вам потрібно або придбати довірений сертифікат, або створити сертифікат, який підписав власноруч. Частина налаштування вашого веб-сервера для використання https - це вказівка ​​його на правильні файли ключів. Звичайно, це стосується всіх веб-серверів не лише iis.