Основи TLS

Безпека транспортного рівня (TLS) шифрує дані, надіслані через Інтернет, щоб гарантувати, що підслуховувачі та хакери не зможуть бачити те, що ви передаєте, що особливо корисно для приватної та конфіденційної інформації, такої як паролі, номери кредитних карток та особисте листування. Ця сторінка пояснює, що таке TLS, як він працює і чому його слід розгортати.

Що таке TLS?

TLS - це криптографічний протокол, який забезпечує наскрізну безпеку даних, що передаються між програмами через Інтернет. Користувачам це в основному знайоме завдяки використанню його в безпечному перегляді веб-сторінок, зокрема, значку замку, який з’являється у веб-браузерах при встановленні захищеного сеансу. Однак він може, і справді, також повинен використовуватися для інших програм, таких як електронна пошта, передача файлів, відео/аудіоконференції, обмін миттєвими повідомленнями та передача голосу за IP, а також для Інтернет-послуг, таких як DNS та NTP.

TLS перетворився на Secure Socket Layers (SSL), який спочатку був розроблений корпорацією Netscape Communications у 1994 році для захисту веб-сесій. SSL 1.0 так і не був публічно випущений, тоді як SSL 2.0 швидко був замінений на SSL 3.0, на якому базується TLS.

TLS вперше був зазначений у RFC 2246 у 1999 році як незалежний від програм протокол, і хоча він не був безпосередньо сумісним із SSL 3.0, пропонував резервний режим, якщо це необхідно. Однак SSL 3.0 зараз вважається небезпечним і був припинений RFC 7568 у червні 2015 року, з рекомендацією використовувати TLS 1.2. Наразі TLS 1.3 (станом на грудень 2015 р.) Розробляється і припинить підтримку менш безпечних алгоритмів.

Слід зазначити, що TLS не захищає дані в кінцевих системах. Це просто забезпечує безпечну доставку даних через Інтернет, уникаючи можливого прослуховування та/або зміни вмісту.

Зазвичай TLS реалізується поверх TCP для шифрування протоколів рівня додатків, таких як HTTP, FTP, SMTP та IMAP, хоча він також може бути реалізований на UDP, DCCP та SCTP (наприклад, для використання додатків на основі VPN та SIP) . Це відоме як захист транспортного рівня датаграм (DTLS) і зазначене в RFC 6347, 5238 та 6083.

Чому я повинен піклуватися про TLS?

Дані історично передавались в незашифрованому вигляді через Інтернет, і там, де застосовувалось шифрування, вони зазвичай використовувались поштучно для отримання конфіденційної інформації, такої як паролі або платіжні реквізити. Хоча ще в 1996 р. (RFC 1984) було визнано, що для зростання Інтернету потрібно буде захищати приватні дані, протягом проміжного періоду стає все більш очевидним, що можливості підслуховувачів та зловмисників є більшими та більш поширеними, ніж вважалося раніше . Тому IAB опублікував заяву в листопаді 2014 року, в якій закликав розробників протоколів, розробників та операторів зробити шифрування нормою для інтернет-трафіку, що, по суті, означає зробити його конфіденційним за замовчуванням.

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

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

Тому рекомендується, щоб усі клієнти та сервери наполягали на обов'язковому використанні TLS у своїх комунікаціях, і бажано останньої версії TLS 1.2. Для повної безпеки необхідно використовувати його разом із довіреною інфраструктурою відкритих ключів X.509 (PKI) і, бажано, DNSSEC, а також для автентифікації того, що система, до якої здійснюється з'єднання, справді є тим, на що вона претендує бути.

Як працює TLS?

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

За допомогою симетричної криптографії дані шифруються та розшифровуються за допомогою секретного ключа, відомого як відправнику, так і одержувачу; зазвичай 128, але бажано довжиною 256 біт (все, що менше 80 бітів, зараз вважається небезпечним). Симетрична криптографія є ефективною з точки зору обчислень, але наявність спільного секретного ключа означає, що нею слід безпечно ділитися.

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

Перевага асиметричної криптографії полягає в тому, що процес спільного використання ключів шифрування не повинен бути безпечним, але математичний зв’язок між відкритим та приватним ключами означає, що потрібні набагато більші розміри ключів. Рекомендована мінімальна довжина ключа становить 1024 біта, переважно 2048 біт, але це до тисячі разів більш обчислювально інтенсивно, ніж симетричні ключі еквівалентної міцності (наприклад, 2048-бітний асиметричний ключ приблизно еквівалентний 112-бітному симетричному ключу) і робить асиметричне шифрування занадто повільним для багатьох цілей.

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

Можуть бути використані різноманітні різні методи генерації та обміну ключами, включаючи RSA, Діффі-Хеллмана (DH), Ефемерну Діффі-Хеллмана (DHE), Еліптичну криву Діффі-Хеллмана (ECDH) та Ефемерну еліптичну криву Діффі-Хеллмана (ECDHE). DHE та ECDHE також пропонують пряму таємницю, завдяки якій ключ сеансу не буде порушений, якщо в майбутньому буде отриманий один із закритих ключів, хоча постулюється слабке генерація випадкових чисел та/або використання обмеженого діапазону простих чисел, що дозволяє зламати навіть 1024-бітові ключі DH з урахуванням обчислювальних ресурсів на рівні держави. Однак це можна розглядати як імплементацію, а не питання протоколу, і існують інструменти для перевірки на слабкіші набори шифрування.

За допомогою TLS також бажано, щоб клієнт, що підключається до сервера, міг перевірити право власності на відкритий ключ сервера. Зазвичай це відбувається за допомогою цифрового сертифіката X.509, виданого довіреною третьою стороною, відомою як Центр сертифікації (ЦС), яка підтверджує справжність відкритого ключа. У деяких випадках сервер може використовувати самопідписаний сертифікат, якому клієнт повинен чітко довіряти (браузери повинні відображати попередження при виявленні ненадійного сертифіката), але це може бути прийнятним у приватних мережах та/або там, де захищений сертифікат розподіл можливий. Однак настійно рекомендується використовувати сертифікати, видані публічно довіреними центрами сертифікації.

Що таке CA?

Центр сертифікації (ЦС) - це організація, яка видає цифрові сертифікати, що відповідають стандарту МСЕ-Т X.509 для інфраструктур із відкритими ключами (PKI). Цифрові сертифікати засвідчують відкритий ключ власника сертифіката (відомого як предмет), а також те, що власник контролює домен, захищений сертифікатом. Таким чином, ЦС діє як довірена третя сторона, яка надає клієнтам (відомим як надійні сторони) впевненість, що вони підключаються до сервера, яким керує перевірена організація.

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

Довіра до кореневих сертифікатів зазвичай встановлюється шляхом фізичного розподілу кореневих сертифікатів в операційних системах або браузерах. Основні програми сертифікації запускаються Microsoft (Windows і Windows Phone), Apple (OSX і iOS) та Mozilla (Firefox & Linux), і вони вимагають, щоб сертифікаційні центри відповідали суворим технічним вимогам та заповнювали WebTrust, ETSI EN 319 411-3 (раніше TS 102 042) або аудит ISO 21188: 2006 з метою включення до їх розподілу. WebTrust - це програма, розроблена Американським інститутом дипломованих бухгалтерів та Канадським інститутом дипломованих бухгалтерів, ETSI - це Європейський інститут телекомунікаційних стандартів, тоді як ISO - Міжнародна організація стандартів.

Кореневі сертифікати, що поширюються з основними операційними системами та браузерами, вважаються публічно або глобально довіреними, а технічні вимоги та вимоги до аудиту по суті означають, що видаючі ЦС є транснаціональними корпораціями чи урядами. В даний час існує близько п'ятдесяти публічно довірених центрів сертифікації, хоча більшість/усі мають більше одного кореневого сертифіката, а більшість з них також є членами CA/Browser Forum, який розробляє галузеві вказівки щодо видачі та управління сертифікатами.

Однак можливо також встановити приватні сертифікаційні центри та встановити довіру шляхом безпечного розповсюдження та встановлення кореневих сертифікатів на клієнтських системах. Прикладом можуть бути службові центри RPKI, що експлуатуються регіональними Інтернет-реєстрами (AfriNIC, APNIC, ARIN, LACNIC та RIPE NCC), які видають сертифікати місцевим Інтернет-реєстрам, що підтверджують IP-адреси та номери AS, які вони мають; а також Міжнародної федерації мережевих довіри (IGTF), яка забезпечує довірчий прив'язок для видачі серверних та клієнтських сертифікатів, що використовуються машинами в розподілених наукових обчисленнях. У цих випадках кореневі сертифікати можна надійно завантажити та встановити з веб-сайтів за допомогою сертифіката, виданого публічно довіреним ЦС.

Однією зі слабких сторін системи X.509 PKI є те, що треті сторони (ЦС) можуть видавати сертифікати для будь-якого домену, незалежно від того, власник запиту фактично є власником чи іншим контролем над ним. Перевірка зазвичай виконується за допомогою перевірки домену - а саме надсилання електронного листа із посиланням для автентифікації на адресу, про яку відомо, що адміністративно відповідає за домен. Це, як правило, одна зі стандартних контактних адрес, наприклад, "[захищений електронною поштою]" або технічний контакт із переліченою базою даних WHOIS, але це залишається відкритим для атак "посередника" на протоколи DNS або BGP, або простіше кажучи, користувачі, які реєструють адміністративні адреси в доменах, які не були зарезервовані. Можливо, що важливіше, сертифікати перевірки домену (DV) не стверджують, що домен має якісь стосунки з юридичною особою, навіть якщо домен може мати такий.

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

Звичайно, це все ще не заважає службовцям сертифікації випадково або обманним шляхом видавати неправильні сертифікати, а також траплялися випадки порушень безпеки, коли органи сертифікації обманювали видавати фальшиві сертифікати. Незважаючи на значне посилення процедур безпеки після кількох гучних інцидентів, система залишається залежною від довіри сторонніх розробників, що призвело до розробки протоколу автентифікації іменованих суб'єктів (DANE) на основі DNS, як зазначено в RFCs 6698, 7671, 7672 та 7673.

За допомогою DANE адміністратор домену може засвідчити свої відкриті ключі, зберігаючи їх у DNS, або ж вказавши, які сертифікати повинен приймати клієнт. Це вимагає використання DNSSEC, який криптографічно підтверджує дійсність записів DNS, хоча DNSSEC ще не має широкого розгортання, і в даний час основні браузери вимагають встановлення надбудови для підтримки DANE. Більше того, DNSSEC і DANE все одно потребуватимуть перевірки власників доменів, які, ймовірно, повинні проводити реєстри доменів та/або реєстратори замість ЦС.