Отже, ряд базових моментів.
1. HTTPS - це HTTP, що працює по "захищеному каналу". Технології, що служать для створення такого каналу для HTTPS, називаються TLS (SSL). TLS використовується не тільки HTTPS. Зазвичай передбачається, що трафік, що передається по згаданому каналу, може бути доступний третій стороні, яка, однак, не повинна мати можливість розкрити самі дані, що передаються ( "захист від прослуховування", реалізується шифруванням; зауважте, втім, що HTTPS можна влаштувати без шифрування, але це буде помилкою).
3. SSL-сертифікати не пов'язані з власне шифруванням даних HTTPS. але вони дозволяють створити зашифрований канал. Однак такий канал може бути створений і без використання сертифіката. Функція SSL-сертифіката, стосовно HTTPS, складається лише в посвідченні зв'язки деякого імені ресурсу і деякого відкритого ключа. Як ім'я ресурсу зазвичай виступає доменне ім'я (приклад: dxdt.ru). Тобто, за допомогою серверного SSL-сертифіката, клієнт (зазвичай - браузер) може упевнитися, що з'єднується саме з володарем секретного ключа з пари, відкрита частина якої вказана в сертифікаті. Цей процес часто називають аутентификацией сервера. Якщо спеціально поставити собі за мету, то нескладно реалізувати TLS-з'єднання з перевіркою SSL-сертифіката, але взагалі без шифрування.
4. Зашифрований канал зв'язку між клієнтом і сервером використовує сеансовий ключ, цей ключ - секретний і симетричний, тобто, його знає і клієнт, і сервер. Генерація загального сеансового ключа, в більшості випадків, відбувається з використанням відкритого ключа, зазначеного в серверному SSL-сертифікат. Залежно від використовуваного алгоритму, серверний ключ або служить для шифрування даних, необхідних для створення сеансового ключа, або для перевірки підпису на цих даних.
5. TLS (і, отже, HTTPS) використовує для реалізації захищеного каналу найрізноманітніші набори криптографічних алгоритмів (шифрів, підписів, кодів аутентифікації, дайджестів і так далі). Якщо будь-яка частина цього набору обрана невірно, то з'єднання буде вразливим, незалежно від того, які ключі і SSL-сертифікати використовувалися. Якщо набір обраний вірно, але генерується нестійкий сеансовий ключ, то, знову ж таки, з'єднання буде вразливим, незалежно від того, які шифри і SSL-сертифікати використовувалися.
6. Для великого класу добротних, стійких криптосистем, широко використовуваних зараз в TLS на практиці, можливо відновлення сеансового ключа з записаного трафіку, за умови, що атакуюча сторона має в своєму розпорядженні секретний серверний ключ (це ключ з тієї пари, відкрита частина якої вказується в сертифікаті сервера). Це означає, що одного разу отримавши секретний ключ сервера (НЕ сеансовий!), Хтось може розшифрувати накопичені раніше записи HTTPS-сеансів між клієнтом і сервером. Згаданий ключ може бути розкритий різними способами: наприклад, його можна скопіювати з сервера, якщо є доступ, або він може просто опинитися нестійким (таке трапляється не так рідко, як можна подумати).
7. Якщо генерація секретного сеансового ключа проводиться за алгоритмом Діффі-Хеллмана, то наявність серверного секретного ключа ніяк не допомагає відновити його з записаного трафіку. Однак на практиці далеко не всі TLS-сервери використовують відповідні алгоритми.
8. Якщо атакуюча сторона отримала відповідний сеансовий ключ, то вона може розкрити HTTPS-трафік. Секретний серверний ключ або SSL-сертифікат для цього не потрібні.
9. Можливість випустити SSL-сертифікат для атакується домену ніяк не допомагає розшифрувати HTTPS-трафік. що йде в цей домен, навіть якщо трафік записується. Це так тому, що SSL-сертифікат не містить секретного серверного ключа (і, очевидно, сеансових ключів). Більш того, процедура випуску сертифіката не вимагає передачі секретного ключа в засвідчує центр (передається тільки відкритий ключ), тому у засвідчувального центру секретного ключа немає.
10. Проте, валідний SSL-сертифікат, випущений для атакується домену, дозволяє провести непомітну для користувача атаку типу "людина посередині". Для цього потрібно, щоб між атакується користувачем і сервером існував керований атакуючим вузол, активно перехоплює трафік. Цей вузол видає себе користувачеві за легітимний сервер, пред'являючи той самий валідний сертифікат. Пасивне прослуховування каналу не дозволяє розкрити HTTPS-трафік подібним чином - наявність сертифіката або секретних ключів УЦ ніяк тут не допомагає.
11. Перехоплення HTTPS-з'єднання може бути автоматизований - існують спеціальні вузли-проксі (SSL-проксі), які виконують такий перехоплення на льоту, в тому числі, генеруючи потрібні сертифікати. У такій проксі повинен бути завантажений сертифікат і секретний ключ, що дозволяють підписувати інші сертифікати (наприклад, годиться так званий проміжний сертифікат УЦ, випущений для цих цілей).
12. Атаку "людина посередині" неможливо проводити по відношенню до тих серверів (і сервісів), трафік в напрямку яких не проходить через перехоплює вузол. Тобто, атака, за визначенням, активна і індивідуальна.
13. "Людина посередині" не працює для HTTPS за наявності деяких додаткових заходів: наприклад, встановлення TLS-з'єднання вимагає взаємної аутентифікації, і перехоплює вузлу недоступний клієнтський секретний ключ (або ключі УЦ, який засвідчує клієнтський ключ); або - призначений для користувача браузер веде реєстр відбитків відкритих ключів сервера, яким він довіряє; або - користувач застосовує додаткові джерела відомостей про дозволених ключах і сертифікатах, які недоступні для підміни на перехоплює вузлі (таким джерелом може служити DNS, або інша база даних).
14. Всі (добре - переважна більшість) скільки-небудь масові сервіси використовують так званий SSL termination: тобто, призначений для користувача HTTPS-трафік в зашифрованому вигляді доходить тільки до прикордонного проксі, де благополучно транслюється в HTTP, який далі ходить по внутрішнім (в логічному , а не технічному сенсі) мереж сервісу в відкритому вигляді. Це стандартна практика, так як тотальний HTTPS, з ростом числа клієнтів, швидко перетворюється в непідйомну, погано масштабується технологію. Якщо система інспекції трафіку знаходиться всередині мереж сервісу, за таким прикордонним SSL-проксі, то ніякої HTTPS їй не заважає. Внутрішній трафік розподілених сервісів з легкістю ходить між вузлами і дата-центрами по орендованим у великих операторів каналах зв'язку у відкритому вигляді. такий трафік може прослуховуватися, хоча для користувача він виглядає як HTTPS-з'єднання.
15. Якщо на комп'ютері користувача присутній троянська програма, що має доступ до браузеру, то HTTPS також виявляється марним, так як дані можуть копіюватися зовні до того, як потраплять в зашифрований канал.