HTTPS має безліч випадків використання, більшість з яких призначені для захисту від атак "Людина посередині". Той, хто має розум хакера, здригнеться, сказавши вам, що крім встановленого способу щось досягти не існує. Справа в тому, що те, що ви використовуєте TLS (стандарт, який використовує сучасний HTTPS), не означає, що ви використовуєте його добре. Крім того, просто використання TLS не заважає комусь використовувати відомі слабкі місця. Подібно до того, як ви можете знайти творчі способи захисту своїх даних, є люди, які знаходять творчі способи використовувати ваші заходи безпеки.
Отже, що робити?
Перш за все, якщо ви збираєтеся відмовитися від TLS, корисно зрозуміти, як це працює. І вся справа в рукостисканні.
Після того, як клієнт і сервер погодилися використовувати TLS, вони узгоджують з'єднання з використанням стану за допомогою процедури рукостискання. [7] Під час цього рукостискання клієнт і сервер узгоджують різні параметри, що використовуються для встановлення безпеки з'єднання:
- Рукостискання починається, коли клієнт підключається до сервера з підтримкою TLS, що вимагає безпечного з'єднання, і представляє список підтримуваних наборів шифрів (шифри та хеш-функції).
- З цього списку сервер вибирає шифр і хеш-функцію, яку він також підтримує, і повідомляє клієнта про рішення.
- Сервер надсилає свою ідентифікацію у вигляді цифрового сертифіката. [Суперечність] Сертифікат зазвичай містить ім'я сервера, довірений центр сертифікації (CA) та відкритий ключ шифрування сервера.
- Клієнт може зв’язатися із сервером, який видав сертифікат (довіреним центром сертифікації, як зазначено вище), і підтвердити дійсність сертифіката перед тим, як продовжити.
- Для того, щоб згенерувати сеансові ключі, що використовуються для безпечного з'єднання, клієнт шифрує випадкове число за допомогою відкритого ключа сервера і надсилає результат серверу. Лише сервер повинен мати можливість розшифрувати його за допомогою приватного ключа.
- Із випадкового числа обидві сторони генерують ключовий матеріал для шифрування та дешифрування. [Суперечність] На цьому завершується рукостискання та починається захищене з'єднання, яке зашифровується та розшифровується разом із ключовим матеріалом, поки з'єднання не закриється.
Якщо якийсь із вищевказаних кроків не вдається, рукостискання TLS не вдається, і підключення не створюється.
Джерело: Вікіпедія
Отже, чи можливо це? Так. Мене навчили, що все можливо. Це може коштувати дорого, але це завжди можливо.
Я хочу повністю сказати, що Я НЕ професіонал охорони, а просто ентузіаст. Я не рекомендую робити це для виробничого проекту чи чогось іншого, крім власного навчання. Ви БЕЗКОШТОВНО повинні перевірити цю публікацію SO, яка пропонує чудове пояснення щодо перешкод у створенні власного протоколу безпеки.
Однак, якщо ви хочете рухатися далі, ось кілька думок, які приходять вам на думку. Це реальності, які існуватимуть незалежно від того, на який напрямок ви пішли з цим проектом.
HTTPS підтримується усіма основними сучасними браузерами. Навіть за такої реальності час завантаження HTTPS є повільнішим, ніж звичайний HTTP. Без великого виробництва дуже ймовірно, що ваша альтернативна реалізація буде настільки ж безпечною, хоча і значно повільнішою. Це буде недоліком будь-якої власної реалізації, якщо ви не використовуєте функції браузера, що повертає нас повним колом до використання TLS, що використовує сучасний HTTPS.
Якщо вам вдається зашифрувати свій пароль без TLS на стороні браузера, використовуючи Javascript досить непередбачувано, що атака MiTM буде важкою, не відпочивайте там. Ви також повинні захищати дані, які ви надсилаєте туди-сюди. В іншому випадку зашифрований пароль дійсно не має значення. Звичайно, зловмисник може не знати пароля bobsmith109, але йому це не потрібно, оскільки він може нюхати кожну окрему діяльність у мережі. Він знає, коли раптом входить bobsmith109, можливо, може простежити його IP-адресу та будь-яку іншу конфіденційну інформацію, яку ви надсилаєте туди-сюди.
Незалежно від того, які заходи безпеки ви вживаєте, вони є глибокими. Тож одне, що ви можете зробити відразу, це переконайтесь, що ви зашифруєте свої дані в базі даних, а також вимагаєте надійних паролів.
Я повторюю, що я не є професіоналом охорони, і настійно не рекомендую це робити нічим, крім як задовольнити вашу цікавість. Астрономічно неймовірно, що ви можете створити життєздатну альтернативу TLS без надзвичайно великої групи професіоналів безпеки, які вносять вклад у проект роками, якщо не десятиліттями, чим може похвалитися SSL / TLS. З огляду на це, гарною відправною точкою, якщо ви вирішите піти вперед, є розглянути модель рукостискання вище і побачити, як ви можете реалізувати версію цього без TLS.
Мені б неприємно не ділитися у своєму дописі з тим, що з більшістю реальних бар'єрів на шляху використання HTTPS активно борються. Один з найбільших - за вартістю - дуже близький до того, щоб стати непроблемним. Безкоштовний орган сертифікації вийде у 2 кварталі 2015 року, підтримуючи деякі великі гармати, включаючи Mozilla та Akamai, щоб назвати декілька. Ось стаття .