Відповіді:
Цікаве питання, це залежить від використання, на мою думку. Ви все ще захищені з точки зору сеансу зашифрованим, але у вас немає способу сказати, чи представлений вам правильний сервер SSL, якщо ви не поширите кореневий сертифікат CA для користувачів / клієнтів. Для внутрішнього тестування / розробок проектів це буде чудово, ви генеруєте кореневий сертифікат CA, який використовуєте для розповсюдження своїм користувачам (це можна зробити за допомогою групової політики в Windows та через командний рядок openssl в Linux / BSD), а потім використовуєте цей кореневий сертифікат для підписання ваших КСВ. Користувачі не побачать попередження чи нічого, і ви знаєте, що сертифікат підписаний вашим внутрішнім адміністратором.
Для зовнішніх сайтів, на яких ви не можете цього запевнити, я все-таки кажу, що самопідписаний сертифікат краще, ніж взагалі немає SSL, якщо ви надсилаєте паролі або іншу конфіденційну інформацію через з'єднання.
Однак на плюсі є дуже багато дешевих "комерційних" емітентів сертифікатів, GoDaddy - один з них. Ви можете отримати сертифікат приблизно за 40 євро на рік. GoDaddy навіть пропонує безкоштовні сертифікати для веб-сайтів проекту OpenSource.
Я збираюся не погоджуватися, раз на вузьких технічних підставах і один раз на загальних підставах.
Вузький технічний підґрунтя полягає в тому, що ОП запитала про самопідписані сертифікати, а кілька інших відповідей стосуються сертифікатів, підписаних приватними органами влади, що є дещо іншим питанням. Але не дуже різні, так що насправді лише примітка мимохідь.
Основне заперечення полягає в тому, що я вважаю, що поки сертифікати, що підписуються на комерційній основі, коштують більше, ніж банальні витрати - а 40 доларів на рік не є тривіальною витратою для багатьох людей на цій планеті - головну роль відіграють самопідписані сертифікати в галузі безпеки в Інтернеті за умови визнання їх обмежень .
Сертифікат, який підписав власноруч, - це як ключ ssh від мого known_hostsфайлу. Без незалежної перевірки це не може мене запевнити, що я розмовляю із системою, що я вважаю, що я є; але це може запевнити мене, що система, з якою я зараз розмовляю, - це та сама система, з якою я говорив минулого разу, я думав, що веду з нею розмову. Ми кешуємо ключі ssh весь час, і я ніколи ще не зустрічався із системним адміністратором, який незалежно підтвердив більш ніж частину відкритих ключів у своєму / її known_hostsфайлі.
Сертифікати з власним підписом (і, з цього приводу, сертифікати, підписані неіснуючими ЦС), набагато краще, ніж взагалі не діють SSL, доки люди розуміють, що, якщо вони не перевіряють їх, вони забезпечують безпеку зв'язку лише для себе, сервера на іншому кінці запису DNS, і будь-який чоловік, що знаходиться в середині, на даний момент на лінії. Якщо вони незалежно перевіряють сертифікат, то автентифікація та шифрування є щонайменше настільки ж сильними, як це передбачено сертифікатом, підписаним визнаним CA.
Крім того, тих , хто хоче представити використання сертифікатів , підписаних визнаний CA як одно-і тільки панацея безпеки Інтернет , можливо , доведеться серйозно подумати про такі питання, як включення CA підписання китайського уряду в стандартній Mozilla пачці , і шахрайські сертифікати SSL, підписані Comodo .
known_hostsте, на що посилається @MadHatter.
Для зовнішніх сайтів, на яких у користувачів не встановлено сертифікат CA (що найчастіший випадок), так, сертифікат, який підписує власний підпис, дає помилкове відчуття безпеки , і, отже, це гірше, ніж марно:
По-перше, без попередньо встановленого сертифіката CA, як користувач перевіряє, що сертифікат дійсно походить від вас, а не від зловмисника? Порівнюючи поля сертифікатів (CN, відбитки пальців тощо), звичайно - але проти чого? Отже, зараз вам потрібен бічний канал для підтвердження сертифіката - і в кількох випадках я бачив, що оператори лінії підтримки (які повинні були виконувати функцію бічного каналу для перевірки) не мають поняття, що це повинно означати; Крім того, керування таким бічним каналом на порядок дорожче, ніж отримання сертифіката, підписаного довіреною CA, тому користувач повинен сліпо вам довіряти.
По-друге, страхітливе сповіщення, яке отримує користувач, є страшним з поважної причини: оскільки користувач не може / не перевірить представлений сертифікат, вони можуть надійно передавати дані в Elbonian Haxx0r D00dz.
По-третє, і найгірше, що ти десенсибілізуєш користувачів : "ну, вони сказали мені, що я повинен ігнорувати це попередження на https://mysite.example.com/ , і коваля не впала на мою голову, і мою золота рибка теж не загинула; sooooo, це означає, що це просто ще одне поле попередження без будь-якого фактичного значення, тому я можу ігнорувати цю скриньку кожного разу, коли стикаюся з нею - я все одно отримую цей гарний значок блокування, і це важливо ".
Іншими словами, рівень захисту порівнянний із звичайним HTTP (за винятком прямого нюху: хоча дані шифруються під час транзиту, це досить анемічна особливість без перевірки кінцевої точки), але відчуття захисту невиправдано високе . Погана аналогія автомобіля: "У мене є ABS, тому тепер я можу їхати безпечніше в поганих умовах" - за винятком АБС, існує лише в брошурі з продажу автомобіля, фактично не присутній в машині.
Пропоноване читання: найкращі практики OWASP SSL
TL; DR: Використовуючи самопідписані сертифікати на публічно відкритих сайтах, ви робите Мережу гіршим місцем, одним неосвіченим користувачем одночасно.
Залежить. Якщо ви думаєте, що це робить вас більш захищеними, то це збільшує ризик, коли ви вирішите робити більш ризиковані речі зі своїм помилковим почуттям безпеки. Якщо ви ставитесь до нього функціонально еквівалентно HTTP, то я б сказав, що ви трохи захищеніші.
Без SSL / HTTPS кожен, хто має провідну мережу у вашій мережі (або локальну мережу будь-кого, хто входить у систему), може тривіально прослуховувати та захоплювати ім’я користувача / паролі, надіслані як звичайний текст.
За допомогою самопідписаного SSL вони не можуть просто слухати, але тепер повинні підробити ваш сайт, потенційно змінити DNS, щоб зробити людину посередньою (MITM) атакою. Це все ще є загрозою, але значно важче їх здійснити.
Інша проблема використання самопідписаного SSL полягає в тому, що багато браузерів розглядають самопідписані сертифікати як основну загрозу безпеці та попереджають вас перед входом (наприклад, хром) на гігантську червону сторінку. http://www.sslshopper.com/article-ssl-certificate-in-google-chrome.html Це може стати великою незручністю.
Отже, підсумок полягає в тому, що якщо ви запускаєте щось, що не повинно бути особливо захищеним (наприклад, відсутні дані кредитної картки, немає соціального страхування) і не можете дозволити собі відповідний сертифікат, сертифікат, який підписався самостійно, може мати певний сенс (скажімо, не дозволяйте іншим користувачам мережі легко нюхати інформацію про вхід).
Це залежить від того, що ви маєте на увазі під "безпекою", і яка міра.
Наприклад, у вашому браузері є набір CA, прийнятий за замовчуванням. Це означає, що будь-який сертифікат, виданий цим CA, приймається вашим браузером (поки він не збігається з іменем dns). Тепер, уявіть, якийсь злий уряд є власником ЦА, або може змусити ЦА видавати сертифікат для відвідуваного вами сайту. Тоді зробити MITM дуже просто: вони можуть проксі підключити ваше з'єднання, відправивши у ваш браузер сертифікат, який вони мають, і ваш браузер прийме його, оскільки він походить від "довіреного" CA. Поки вони не стануть прозорими для DNS (що є базою для MITM), це нормально.
Отже, "список прийнятих ЦА" є в основному великою діркою в безпеці, поки одна з цих ЦА не співпрацює з деяким злим урядом. Мати власний СА набагато краще.
Звичайно, ви можете це зробити у вашій компанії або на домашньому сервері, оскільки ви можете встановити власний сертифікат CA в клієнт, який ви також контролюєте. На загальнодоступному сервері ви не можете спілкуватися з будь-яким користувачем, попросивши його додати виняток або додати ваш сертифікат.
Отже, це залежить від того, що ви маєте на увазі під "безпекою" та сферою застосування. ЯКЩО ви володієте клієнтами, ЗА Впевненість, самопідписання є більш безпечним, поки ви не встановите на сам клієнт сертифікат власного CA.
Звичайно, ви не можете зробити це на загальнодоступному веб-сайті, оскільки у вас немає всіх клієнтів. Так ви отримаєте небезпеку різної поведінки, що не є безпечним.