# TLS ## Що це таке TLS, Transport Layer Security, — це протокол, який клієнт і сервер виконують перед обміном даними застосунку, щоб усе подальше лишалося приватним, не змінювалося непомітно й потрапляло саме до тієї сторони, до якої звертався клієнт. У меню продуктів і в магазинах сертифікатів його досі часто називають SSL, за назвою Secure Sockets Layer, протоколу, на зміну якому прийшов TLS. RFC 7568 у червні 2015 року визнав останню версію SSL застарілою, тож усе, що сьогодні зветься SSL, усередині є TLS або принаймні має ним бути. TLS розташований між протоколом застосунку й транспортом під ним. HTTPS — це HTTP усередині TLS-з'єднання, а той самий шар захищає надсилання пошти, IMAP, з'єднання з базами даних і протокол Gemini. HTTP/3 іде далі: він працює поверх QUIC, що вбудовує рукостискання TLS 1.3 просто в транспорт, а не кладе його поверх TCP, як описує RFC 9001. Чинна версія — TLS 1.3 з RFC 8446, опублікованого в серпні 2018 року, який замінив специфікацію TLS 1.2. З'єднання починається з рукостискання. Клієнт надсилає ClientHello з переліком версій, наборів шифрів (cipher suites) і ключових часток, які він підтримує, а також Server Name Indication (SNI) — ім'я хоста, до якого він звертається, щоб одна адреса могла обслуговувати багато сайтів. Сервер обирає, відповідає власною ключовою часткою, і з цієї миті все шифрується, зокрема й сертифікат, який він показує. Ланцюжок сертифікатів пов'язує ключ сервера з центром сертифікації, якому клієнт уже довіряє. Клієнт перевіряє ланцюжок, ім'я та дати, а сервер доводить, що володіє відповідним закритим ключем, підписуючи рукостискання. Версію 1.3 від 1.2 відрізняють три речі. Повне рукостискання займає один обмін туди й назад замість двох. Кожен обмін ключами ефемерний, тож запис сьогоднішнього трафіку лишається закритим, навіть якщо закритий ключ сервера витече наступного року; ця властивість називається прямою секретністю (forward secrecy). І клієнт, що повертається, може надіслати «ранні дані» вже в першому повідомленні — це називають 0-RTT, — але RFC прямо називає ціну: такі дані не мають ні прямої секретності, ні захисту від повторного відтворення в іншому з'єднанні. ## Чому це важливо Чи використовувати TLS, давно вирішено. Відкритими лишаються два питання: які версії приймати і де закінчується зашифроване з'єднання. Спершу версії. RFC 8996 від березня 2021 року забороняє використовувати TLS 1.0 і 1.1. RFC 9325, чинна найкраща практика (BCP 195), вимагає підтримки 1.2, рекомендує 1.3 і велить віддавати перевагу 1.3, коли його мають обидві сторони. Вона ж каже, що 1.2, налаштований за її вказівками, такий самий безпечний, як 1.3: обмін ключами ECDHE заради прямої секретності, AES-GCM і жодного набору з режимом CBC. Тож реальний вибір — між «1.2 і 1.3» та «лише 1.3». Сервіс лише з 1.3 має меншу поверхню атаки й коротшу конфігурацію, але відсікає кожного клієнта, що вміє щонайбільше 1.2: старіший телефон, платіжний термінал, інтеграцію партнера на старому середовищі Java. Таке рішення легко ухвалити на фактах. Кілька тижнів журналюйте узгоджену версію, а тоді вирішуйте за цифрами, а не за тим, що звучить сучасно. Потім термінування. Там, де закінчується TLS, лежить закритий ключ, і трафік знову стає відкритим текстом. Є три поширені місця: - **CDN або хмарний балансувальник навантаження.** Постачальник тримає ключ або сертифікат, який сам випустив, бере на себе навантаження рукостискань і бачить кожен запит відкритим текстом. Ділянці від нього до вихідного сервера потрібен власний TLS, інакше вона йде мережею незашифрованою. - **Зворотний проксі на хості,** наприклад Nginx, Apache, HAProxy чи Caddy. Один процес тримає ключі всіх сайтів машини й передає запити без шифрування застосункам за ним через loopback або локальний сокет. - **Сам застосунок.** Кожен сервіс має власний ключ. Це пасує трафіку між сервісами та взаємному TLS (mutual TLS), де сертифікат показує й клієнт, і водночас множить місця, де сертифікат треба поновлювати. Більшість інфраструктур поєднує всі три. Важливо, щоб для кожної ділянки хтось міг сказати, де лежить відкритий текст і хто здатен його прочитати. ## Як це виглядає на практиці Власний робочий хост компанії показує, як мало потребує термінування TLS. Це хмарний примірник з одним ядром, 512 МБ пам'яті, з яких можна використати близько 464 МБ, і 10 ГБ диска. На ньому [один вебсервер термінує TLS для всіх семи доменів](/uk/portfolio/ran-the-whole-company-on-one-512mb-host-109/) поруч із хостингом git-репозиторіїв, onion-службою Tor, сервером Gemini, сервером Gopher, зашифрованими резервними копіями та блокуванням вторгнень. Це термінування на хості в найпростішому вигляді: один вебсервер відповідає за всі сім сайтів, і їхнє шифрування не вимагає ані окремої машини, ані окремого сервісу. Проєкт виходив із пам'яті як головного обмеження, і все з цього переліку, разом із термінуванням, вміщується в ті 464 МБ. Правило, за яким працює компанія, записане на її [сторінці безпеки](/uk/security/): шифрування під час передавання всюди, а сертифікати випускаються й поновлюються без участі людини, і моніторинг стежить за кожним поновленням. Пояснення там таке: найпоширеніша причина збоїв TLS — сертифікат, строк якого спливає непомітно. Нижче зібрано збої, що лишаються, коли поновлення вже працює саме. ## Де виникають проблеми **Частина клієнтів обривається з помилкою рукостискання, хоча браузери під'єднуються без проблем.** Сторони не мають спільної версії чи набору шифрів. Хтось звузив сервер до 1.3 або до короткого списку наборів, і старішому клієнту нема чого запропонувати; або сервер, що досі пропонує лише набори CBC, натрапляє на клієнта, який від них відмовився. Повідомлення звучить як «handshake failure» чи «protocol version» і майже нічого не пояснює. Перевірте кожну версію ззовні: ```sh openssl s_client -connect example.com:443 \ -servername example.com -tls1_2