Используется ли шифрование при передаче данных в HTTP/HTTPS
Что проверяют
Понимаете ли вы, что именно шифрует HTTPS и как устроено рукопожатие, а не только «S значит secure». Для Go-разработчика следом идёт практика: как поднять TLS-сервер на net/http, чем опасен InsecureSkipVerify и где лучше терминировать TLS.
Как отвечать
HTTP передаёт всё открытым текстом. HTTPS это тот же HTTP поверх TLS, SSL давно устарел и отключён. Актуальны TLS 1.2 и 1.3.
- рукопожатие TLS 1.3: стороны договариваются о шифре и обмениваются ключевым материалом по ECDHE, из него выводят общие симметричные ключи. Сертификат нужен для аутентификации: сервер подписывает рукопожатие закрытым ключом, клиент проверяет цепочку до доверенного центра и имя хоста;
- шифрование данных: данные шифруются симметрично (AES-GCM или ChaCha20-Poly1305), асимметрия работает только в рукопожатии;
- что скрыто: метод, путь, query, заголовки, куки, тело. Видны IP-адреса, порт, объём трафика и обычно домен в SNI, если не включён ECH;
- forward secrecy: из-за эфемерных ключей утечка закрытого ключа сервера не раскрывает ранее записанный трафик.
Практика в Go:
- сервер:
http.ListenAndServeTLS(":443", "cert.pem", "key.pem", handler)илиhttp.ServerсTLSConfig, HTTP/2 поверх TLS включается автоматически; - версии:
tls.Config{MinVersion: tls.VersionTLS12}явно фиксирует нижнюю планку; - сертификаты: Let’s Encrypt через
golang.org/x/crypto/acme/autocert; - mTLS между сервисами:
ClientAuth: tls.RequireAndVerifyClientCertи пулClientCAs.
В проде TLS часто терминируют на балансировщике или ingress, и внутри кластера трафик идёт по HTTP, если нет service mesh с mTLS.
Где спотыкаются
Пересказывают схему «клиент шифрует данные открытым ключом сервера». Так данные не шифруются никогда, а обмен ключом через RSA в TLS 1.3 вообще убран.
Ставят InsecureSkipVerify: true, чтобы «заработало» с самоподписанным сертификатом, и отключают защиту от MITM. Правильно добавить свой CA в RootCAs.
Считают, что HTTPS скрывает, на какой сайт вы ходите. Домен обычно виден в SNI и в DNS-запросах.