🔐 Разница между HTTP и HTTPS 🔐

Это один из наиболее частых вопросов, которые я встречаю на занятиях про API от наших студентов. Его же спрашивают на собеседованиях. Поэтому давайте разберёмся, в чём же отличия.


HTTP - это протокол прикладного уровня.

Он включает в себя варианты использования:

👉 HTTP — данные идут «в открытом виде»
Любой, кто перехватил трафик, увидит весь запрос и ответ как текст.
Если трафик в HTTP (незащищённый), то перехватчик сможет видеть:
🔺 Полный URL (включая query-параметры)
🔺 Все HTTP-заголовки (включая Authorization, Cookie, User-Agent)
🔺 Тело запроса/ответа — JSON, формы, файлы.
❗️ То есть любые передаваемые пароли, токены, номера карт, персональные данные будут перехвачены.

👉 HTTPS — тот же HTTP поверх шифрованного канала TLS
Перехватчик трафика не увидит содержимого запросов и ответов - оно зашифровано, он увидит только:
🔺 линию связи: IP-адрес сервера, порт (обычно 443), объём и тайминги пакетов.
🔺 может увидеть SNI (Server Name Indication) - имя хоста, переданное открыто в TLS ClientHello (в большинстве реализаций)
🔺 НЕ видит содержимое заголовков и тела запросов - они зашифрованы. Токены/пароли/JSON недоступны.
❗️ При перехвате трафика все персональные данные будут защищены.



👉 Как перехватывают трафик?

⚪ Открытая Wi-Fi сеть (public hotspot)
Пользователь подключается к общему Wi-Fi, злоумышленник в той же сети запускает сниффер.
Без HTTPS — все данные видно.
С HTTPS — трафик зашифрован.

⚪ Компрометация роутера / провайдера
Подменённый DNS или перенаправление на прокси. Может потребоваться поддельный сертификат.

⚪ Браузерные расширения / вредоносное ПО
Может читать/перехватывать запросы на клиенте до шифрования (например, JS-обработчики, extensions).

⚪ Атакующий выдает себя за шлюз в локальной сети (ARP poisoning) и проксирует (перенаправляет) трафик через себя.

⚪ И другие способы атак.

Чтобы обеспечить работу HTTPS, на сервер должны установить сертификаты SSL/TLS

Без них HTTPS просто не сможет работать и будет просто HTTP.


#RestApiGA #АрхитектураGA

🔐 SSL/TLS-сертификаты для обеспечения HTTPS 🔐

Чтобы обеспечить безопасное HTTPS соединение и защититься от перехвата трафика, на сервере должны быть установлены SSL/TLS-сертификаты.


👉 SSL/TLS-сертификат - это цифровой документ, который:

▫️ подтверждает подлинность сервера (что api.company.com это действительно ваш сервер, а не подделка),

▫️ содержит публичный ключ для шифрования данных при установлении TLS-соединения.

Когда клиент заходит по https://.., он получает этот сертификат и проверяет его подлинность через цепочку доверенных центров сертификации (CA — Certificate Authority)


👉 Центр сертификации - это доверенная организация, которая подтверждает подлинность домена или компании и выдаёт цифровые сертификаты (SSL/TLS).

Каждая операционная система (Windows, macOS, Android и др) и каждый браузер имеет внутри себя список доверенных корневых сертификатов (Root CA).

Это десятки (иногда сотни) организаций:
+ DigiCert
+ GlobalSign
+ Let’s Encrypt
+ GoDaddy
и др.

📦 Этот список устанавливается вместе с системой и регулярно обновляется вместе с обновлением браузера или ОС.


👉 Что происходит, когда ты заходишь на HTTPS://getanalyst.ru, у которого есть SSL/TLS?
1️⃣ Клиент (Postman, браузер, моб. приложение) устанавливает TCP-соединение с сервером (порт 443)
2️⃣ Сервер отправляет свой сертификат (в нём: имя домена, срок действия, кто выдал и т.д.)
3️⃣ Клиент проверяет подпись этого сертификата

👉 Что происходит, когда ты заходишь на HTTP://getanalysts.com?
Браузер сообщает, что соединение небезопасно


📌 Что можно написать в ТЗ про проверку HTTPS (SSL/TLS), в задачах на интеграции по API:
✅ Все внешние и внутренние интеграции - только по HTTPS (TLS ≥ 1.2, желательно TLS 1.3)
✅ Валидировать сертификаты на стороне клиента; логировать certificate errors
✅ Использовать mTLS для сервер-серверных вызовов критичных API (для повышенной безопасности)
✅ Не передавать секреты или CVV в query-параметрах (в URL) - только в теле по HTTPS
✅ Логировать подозрительную активность авторизаций


#RestApiGA #АрхитектураGA