Цифрові підписи, сертифікати та TLS

Попереднє заняття залишило одне питання відкритим: асиметричне шифрування дозволяє надіслати секрет комусь, чий відкритий ключ у вас є, — але звідки ви знаєте, що цей відкритий ключ справді належить йому, а не зловмиснику посередині? Цифрові підписи й сертифікати відповідають на це, і разом вони роблять можливим TLS — протокол, що стоїть за кожною адресою https://.

Цифрові підписи: доказ походження, а не секретність

Цифровий підпис виконує асиметричне шифрування у зворотному напрямку. Замість шифрування повідомлення чиїмось відкритим ключем, щоб прочитати його міг лише він, відправник підписує повідомлення власним приватним ключем, а перевірити це може будь-хто за допомогою відкритого ключа відправника. Якщо перевірка успішна, вірні дві речі: повідомлення прийшло від того, хто тримає цей приватний ключ, і його не змінювали згодом — та сама властивість стійкості до колізій із обговорення хешування в попередньому занятті й робить втручання виявним. Підпис доводить автентичність і цілісність; сам по собі він не тримає повідомлення в таємниці.

Сертифікати: підпис, що ручається за відкритий ключ

Цифровий сертифікат вирішує проблему «чий насправді це відкритий ключ». Як пояснює Навчальний центр Cloudflare, сертифікат SSL/TLS — це «файл даних, що зберігається на початковому сервері сайту» і містить доменне ім’я, відкритий ключ, дату закінчення терміну дії і — критично важливо — «цифровий підпис центру сертифікації». Центр сертифікації (CA) — довірена третя сторона, що перевіряє, чи контролює сайт домен, для якого запитує сертифікат, а потім підписує цей сертифікат власним приватним ключем. Ваш браузер постачається з вбудованим списком CA, яким довіряє, тож коли він отримує сертифікат, підписаний одним із них, він може довіряти вкладеному відкритому ключу, ніколи не зустрічавшись з оператором сайту. Самопідписаний сертифікат — той, що сайт підписує сам, а не отримує від CA, — не має такого зовнішнього поручительства, тому браузери за замовчуванням вважають його ненадійним.

TLS: використання обох у справі

RFC 8446, специфікація TLS 1.3, описує рукостискання фазами: обмін ключами, під час якого обидві сторони встановлюють спільний секретний матеріал; потім автентифікація, де, за словами RFC, «серверна сторона каналу завжди автентифікується; клієнтська сторона автентифікується опційно» — зазвичай лише сайт доводить свою особу, а не відвідувач. Сервер доводить, хто він, за допомогою свого сертифіката й підпису, який тільки він міг створити своїм приватним ключем. Щойно обидві сторони довіряють з’єднанню, вони виводять швидкі симетричні ключі (зазвичай AES із попереднього заняття) для самих даних. RFC 8446 прямо стверджує, що це дає: конфіденційність і цілісність для обмінюваних даних, і автентифікацію сервера. Він так само прямо вказує й межу: «TLS не приховує довжину переданих даних», і метадані на кшталт того, до якого сервера ви під’єдналися і коли, залишаються видимими для будь-кого, хто спостерігає за з’єднанням.

Що означає і чого не означає іконка замка

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