Як же все-таки працює HTTPS? Це питання, над яким я бився кілька днів у своєму робочому проекті.
Будучи Web-розробником, я розумів, що використання HTTPS для захисту даних - це дуже і дуже хороша ідея, але у мене ніколи не було кристального розуміння, як HTTPS насправді влаштований.
Як дані захищаються? Як клієнт і сервер можуть встановити безпечне з'єднання, якщо хтось уже прослуховує їх канал? Що таке сертифікат безпеки і чому я повинен комусь платити, щоб отримати його?
трубопровід
Перед тим як ми зануримося в те, як це працює, давайте коротко поговоримо про те, чому так важливо захищати Інтернет-з'єднання і від чого захищає HTTPS.
Коли браузер робить запит до Вашого улюбленого веб-сайту, цей запит повинен пройти через безліч різних мереж, кожна з яких може бути потенційно використана для прослуховування або для втручання у встановлений з'єднання.
З вашого власного комп'ютера на інші комп'ютери вашої локальної мережі, через роутери і свитчи, через вашого провайдера і через безліч інших проміжних провайдерів - величезна кількість організацій ретранслює ваші дані. Якщо зловмисник виявиться хоча б в одній з них - у нього є можливість подивитися, які дані передаються.
Як правило, запити передаються за допомогою звичайного HTTP, в якому і запит клієнта, і відповідь сервера передаються у відкритому вигляді. І є безліч вагомих аргументів, чому HTTP не використовує шифрування за умовчанням:
• Для цього потрібно більше обчислювальних потужностей
• Передається більше даних
• Не можна використовувати кешування
Але в деяких випадках, коли по каналу зв'язку передається виключно важлива інформація (така як, паролі або дані кредитних карт), необхідно забезпечити додаткові заходи, що запобігають прослуховування таких з'єднань.
Transport Layer Security (TLS)
Зараз ми збираємося зануритися в світ криптографії, але нам не буде потрібно для цього якогось особливого досвіду - ми розглянемо лише загальні питання. Отже, криптографія дозволяє захистити з'єднання від потенційних зловмисників, які хочуть впливати на з'єднання або просто прослуховувати його.
TLS - спадкоємець SSL - це такий протокол, найбільш часто вживаний для забезпечення безпечного HTTP з'єднання (так званого HTTPS). TLS розташований на рівень нижче протоколу HTTP в моделі OSI. Пояснюючи на пальцях, це означає, що в процесі виконання запиту спершу відбуваються все "речі", пов'язані з TLS-з'єднанням і вже потім, все що пов'язано з HTTP-з'єднанням.
TLS - гібридна криптографічний система. Це означає, що вона використовує кілька криптографічних підходів, які ми і розглянемо далі:
1) асиметричний шифрування (асиметричні алгоритми шифрування) для генерації загального секретного ключа і аутентифікації (тобто посвідчення в тому, що ви - той за кого себе видаєте).
2) Симетричне шифрування. використовує секретний ключ для подальшого шифрування запитів і відповідей.
Асиметричні алгоритми шифрування
Асиметричні алгоритми шифрування - це різновид криптографічного системи, коли у кожної сторони є і відкритий, і закритий ключ, математично пов'язані між собою. Відкритий ключ використовується для шифрування тексту повідомлення в "тарабарщину", в той час як закритий ключ використовується для дешифрування і отримання початкового тексту.
Це означає, що якщо хто-небудь знаходиться між клієнтом і сервером і спостерігає за з'єднанням - він все одно не зможе дізнатися ні закритий ключ клієнта, ні закритий ключ сервера, ні секретний ключ сесії.
Як це можливо? Математика!
Алгоритм Діффі - Хеллмана
Одним з найбільш поширених підходів є алгоритм обміну ключами Діффі - Хеллмана (DH). Цей алгоритм дозволяє клієнту і серверу домовитися з приводу загального секретного ключа, без необхідності передачі секретного ключа по з'єднанню. Таким чином, зловмисники, що прослуховують канал, не зможу визначити секретний ключ, навіть якщо вони будуть перехоплювати всі пакети даних без винятку.
Як тільки відбувся обмін ключами по DH-алгоритму, отриманий секретний ключ може використовуватися для шифрування подальшого з'єднання в рамках даної сесії, використовуючи набагато більш просте симетричне шифрування.
Трохи математики ...
Математичні функції, що лежать в основі цього алгоритму, маю важливу відмінну рису - вони відносно просто обчислюються в прямому напрямку, але практично не обчислюються в обратом. Це саме та область, де в гру вступають дуже великі прості числа.
Нехай Аліса і Боб - дві сторони, які здійснюють обмін ключами по DH-алгоритму. Спершу вони домовляються про деяке підставі root (зазвичай невеликій кількості, такому як 2,3 або 5) і про дуже великому простому числі prime (більше ніж 300 цифр). Обидва значення пересилаються в відкритому вигляді по каналу зв'язку, без загрози компрометувати з'єднання.
Нагадаємо, що і у Аліси, і у Боба є власні закриті ключі (з більш ніж 100 цифр), які ніколи не передаються по каналах зв'язку.
Каналом зв'язку же передається суміш mixture. отримана із закритих ключів, а також значень prime і root.
Таким чином:
Alice's mixture = (root ^ Alice's Secret)% prime
Bob's mixture = (root ^ Bob's Secret)% prime
де% - залишок від ділення
Таким чином, Аліса створює свою суміш mixture на основі затверджених значень констант (root і prime), Боб робить те ж саме. Як тільки вони отримали значення mixture один одного, вони виробляють додаткові математичні операції для отримання закритого ключа сесії. А саме:
обчислення Аліси
(Bob's mixture ^ Alice's Secret)% prime
обчислення Боба
(Alice's mixture ^ Bob's Secret)% prime
Результатом цих операцій є одне і те ж число, як для Аліси, так і для Боба, і це число і стає закритим ключем на дану сесію. Зверніть увагу, що жодна зі сторін не мала пересилати свій закритий ключ по каналу зв'язку, і отриманий секретний ключ так само не передавався по відкритому з'єднанню. Чудово!
Для тих, хто менше підкований в математичному плані, Wikipedia дає прекрасну картинку. пояснює цей процес на прикладі змішування кольорів:
Зверніть увагу як початковий колір (жовтий) в результаті перетворюється в один і той же "змішаний" колір і у Боба, і у Аліси. Єдине, що передається по відкритому каналу зв'язку так це наполовину змішані кольору, насправді безглузді для будь-якого прослуховуючого канал зв'язку.
симетричне шифрування
Обмін ключами відбувається за все один раз за сесію, під час встановлення з'єднання. Коли ж сторони вже домовилися про секретний ключі, клієнт-серверне взаємодія відбувається за допомогою симетричного шифрування, яке набагато ефективніше для передачі інформації, оскільки не потрібно додаткові витрати на підтвердження.
Використовуючи секретний ключ, отриманий раніше, а також домовившись з приводу режиму шифрування, клієнт і сервер можуть безпечно обмінюватися даними, шифруючи і дешіфруя повідомлення, одержані одна від одної з використанням секретного ключа. Зловмисник, який підключився каналу, буде бачити лише "сміття", який гуляє по мережі взад-вперед.
аутентифікація
Алгоритм Діффі-Хеллмана дозволяє двом сторонам отримати закритий секретний ключ. Але звідки обидві сторони можуть впевнені, що розмовляють дійсно один з одним? Ми ще не говорили про аутентифікації.
Що якщо я подзвоню своєму приятелеві, ми здійснимо DH-обмін ключами, але раптом виявиться, що мій дзвінок був перехоплений і насправді я спілкувався з кимось іншим. Я як і раніше зможу безпечно спілкуватися з цією людиною - ніхто більше не зможе нас прослухати - але це буде зовсім не той, з ким я думаю, що спілкуюся. Це не дуже безпечно!
Для вирішення проблеми аутентифікації, нам потрібна Інфраструктура відкритих ключів. що дозволяє бути впевненим, що суб'єкти є тими за кого себе видають. Ця інфраструктура створена для створення, управління, поширення та відкликання цифрових сертифікатів. Сертифікати - це ті дратівливі штуки, за які потрібно платити, щоб сайт працював по HTTPS.
Але, насправді, що це за сертифікат, і як він надає нам безпеку?
сертифікати
По суті, сертифікати пов'язують доменні імена з певним публічним ключем. Це запобігає можливості того, що зловмисник надасть свій публічний ключ, видаючи себе за сервер, до якого звертається клієнт.
Щоб сертифікату довіряв будь-який веб-браузер, він повинен бути підписаний акредитованим центром, що засвідчує (центром сертифікації, Certificate Authority, CA). CA - це компанії, що виконують ручну перевірку, того що особа, що намагається отримати сертифікат, задовольняє наступним двом умовам:
1. є реально існуючим;
2. має доступ до домену, сертифікат для якого воно намагається отримати.
Як тільки CA засвідчується в тому, що заявник - реальний і він реально контролює домен, CA підписує сертифікат для цього сайту, по суті, встановлюючи штамп підтвердження на тому факті, що публічний ключ сайту дійсно належить йому і йому можна довіряти.
У ваш браузер вже спочатку предзагружен список акредитованих CA. Якщо сервер повертає сертифікат, що не підписаний акредитованим CA, то з'явиться велике червоне попередження. В іншому випадку, кожен міг би підписувати фіктивні сертифікати.
Так що навіть якщо хакер взяв відкритий ключ свого сервера і згенерував цифровий сертифікат, який підтверджує що цей публічний ключ, асоційований з сайтом facebook.com, браузер не повірить в це, оскільки сертифікат не підписаний акредитованим CA.
Інші речі які потрібно знати про сертифікати
розширена валідація
На додаток до звичайних X.509 сертифікатів, існують Extended validation сертифікати, що забезпечують більш високий рівень довіри. Видаючи такий сертифікат, CA робить ще більше перевірок щодо особи, яка отримує сертифікат (зазвичай використовуючи паспортні дані або рахунку).
Обслуговування безлічі веб-сайтів на одному сервері
По цій темі багато даних є в вікіпедії, є курс на Coursera. Окреме спасибі хлопцям з чату на security.stackexchange.com. які відповідали на мої запитання сьогодні вранці.