SSL vs TLS: Знай свої протоколи до 2020 року

Google порушує безпеку веб-сайту. Починаючи з версії 62 Chrome, для всіх веб-сайтів із полями для введення тексту знадобиться сертифікат SSL або Google позначить веб-сайт як незахищений червоним знаком обережності поруч із URL-адресою.


Зміни відбуваються і в цікавий час, враховуючи недавній поштовх браузерів та серверів для підтримки TLS. Однак, якщо ви новачок у грі створення веб-сайтів, усіх цих скорочень може бути достатньо, щоб голова крутилася.

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

SSL проти TLS

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

Дані, що подорожують між машинами, потім шифруються та фрагментуються до певного розміру, залежно від шифру, і надсилаються до мережевого транспортного рівня. Шифр стосується шифрування, а не рукостискання. Протоколи SSL та TLS просто використовуються для завершення рукостискання та узгодження моделі шифрування.

Що таке SSL & TLS?

SSL означає “Шар захищених сокетів”. Він був розроблений Netscape і вперше опублікований для публіки в 1995 році. Публічний реліз був другою версією, і хакери швидко знайшли способи пробити його. Через рік Netscape випустила версію три, яку вважали безпечною протягом восьми років.

Netscape

У 2014 році атака POODLE зробила SSL 3.0 незахищеною, але про це ніхто тоді не знав. TLS (Transport Layer Security), яка є більш захищеною версією SSL, була випущена в 1999 році і оснащена механізмом відкидання до SSL 3.0 для зворотної сумісності.

Ця сумісність була вбудована тому, що атака POODLE, експедиція людини в середині, зловживала цією зворотною сумісністю (щоб прочитати більше про атаки MitM, ознайомтеся з нашою статтею про небезпеку публічного WiFi).

TLS 1.1 з’явився у 2006 році, а 1.2 – у 2008 році. TLS 1.2 – це поточний та найбезпечніший протокол, хоча 1.3 був затверджений на початку цього року. Ми очікуємо, що браузери та сервери незабаром підтримають його.

Протоколи відрізняються, але не більше, ніж різні версії SSL. Відбувається той самий процес, рукостискання між двома машинами, але версія протоколу визначає, як це відбувається.

Проблема сумісності назад

Плутанина навколо SSL та TLS походить від зворотної сумісності. TLS 1.2 має залишки більш ранніх версій SSL, щоб зробити його сумісним із застарілими браузерами. Таким чином, багато веб-сайтів не вимкнули функції, які роблять такий протокол, як TLS 1.2, незахищеним.

Тут використовується TLS 1.3. Він створений для відключення застарілих функцій та прискорення продуктивності під час безпечного з’єднання. Замість того, щоб узгодити модель шифрування, сервер надає ключ шифрування з TLS 1.3. Теоретично це робить кілька анотацій пониження, які змушують сервер використовувати старіший протокол, застарілим.

Останнє оновлення – це поштовх до сучасного Інтернету, відмовившись від застарілої моделі, встановленої ранніми версіями SSL. Сподіваємось, протягом декількох років напади типу POODLE не будуть викликати такого ступеня, як сьогодні.

Використання TLS на вашому веб-сайті

Протокол TLS, який використовується для вашого веб-сайту, залежить від сервера, на якому ви розміщені. Найкращі провайдери веб-хостингу використовують виключно TLS 1.1 та 1.2, 1,0 загалом зарезервовано для розробників веб-сайтів, які не включають електронну комерцію.

Остаточна версія TLS 1.3 була опублікована лише кілька тижнів тому, тому пройде час, перш ніж веб-хости підтримують її. Наприклад, Kinsta вже звернувся до випуску TLS 1.3 і вживає заходів для його впровадження (читайте наш огляд Kinsta).

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

Сертифікати просто використовуються як метод підтвердження. Різні форми сертифікатів SSL та TLS показують рівень довіри, який має браузер до вашого домену. Ми переглянемо їх у наступному розділі.

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

Є кілька способів це перевірити. Перша – через базу знань веб-хостингу. Наприклад, GoDaddy має невелику таблицю, на якій відображається версія TLS, яку підтримує ваш сервер, залежно від плану хостингу, який ви перебуваєте (читайте наш огляд GoDaddy).

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

Типи сертифікатів SSL та TLS

Ще раз, сертифікати SSL краще визначати як “сертифікати, які можуть використовувати SSL та TLS”, тому ми їх називатимемо SSL-сертифікатами, щоб уникнути плутанини для цього розділу. Де б ви не читали SSL або TLS без версії протоколу, вони будуть тим самим.

Сертифікати, підтверджені доменом

Найбільш основна форма сертифіката SSL – це підтверджений доменний сертифікат, який перевіряє реєстр домену. По суті, він перевіряє, що домен користувач намагається отримати точки доступу до правильного сервера DNS.

Це найдешевший сертифікат, який часто отримують безкоштовно. Jimdo, один із найкращих наших розробників веб-сайтів, безкоштовно включає сертифікат Let’s Encrypt DV, як і багато будівельників веб-сайтів та веб-хостів (читайте наш огляд Jimdo).

Однак сертифікати DV мають високий ризик, оскільки веб-переглядачі часто не можуть перевірити, чи закон на веб-сайті законний. У Chrome зазвичай ви бачите протокол https з червоним замком з косою рисою ліворуч.

Сертифікат DV

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

Сертифіковані сертифікати організації

Перевірені сертифікати організації перевіряють бізнес чи організацію. Агенти з Сертифікаційного органу перевірять урядові бази даних реєстру, щоб переконатися, що сайт справжній. Усі дані всередині сертифіката OV є законними.

Якщо ви здійснюєте комерційний бізнес в Інтернеті, це сертифікат, який потрібно використовувати. У вашій URL-адресі все ще використовується https, але поруч із адресним рядком буде блокування. У Chrome зелений, праворуч слово “безпечно”.

Сертифікат OV

Розширений сертифікат валідації

Сертифікати OV хороші, але сертифікати розширеної перевірки – кращі. Сертифікати OV вимагають одноразової перевірки з КА, тоді як сертифікати EV вимагають постійного моніторингу на основі вказівок для розширеної перевірки.

Процес перевірки набагато суворіший, а ціна значно вища. Однак для великих інтернет-магазинів сертифікат EV може покращити довіру споживачів та збільшити продажі в Інтернеті.

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

Сертифікат EV

Фінальні думки

Немає дефіциту заплутаних абревіатур, що стосується кібербезпеки, і перехід від SSL на TLS не допомагає цьому. Хоча протоколи різні, вони досягають однієї і тієї ж мети: безпечне з’єднання між сервером і користувачем.

Що стосується сертифікатів, умови є взаємозамінними, тому не переживайте за оновлення сертифіката SSL до сертифіката TLS. Вони те саме.

Якщо ви шукаєте постачальників веб-хостингів, які можуть вас провести через процес, ознайомтеся з найкращим дешевим веб-хостингом, щоб дізнатися, як це зробити без особливої ​​монети.

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

Kim Martin
Kim Martin Administrator
Sorry! The Author has not filled his profile.
follow me