Просто хочу проверить, когда вы делаете SSL-соединение (http post), чтобы сказать:
https://www.example.com/some/path?customer_key=123123123
Если вы не хотите, чтобы кто-либо знал о client_key, этот подход не будет работать, даже если я правильно установил https-соединение?
Все данные, которые я хочу сохранить, должны находиться в теле запроса правильно?
Цитирование HTTPS RFC:
Когда завершено квитирование TLS. Затем клиент может инициировать первый HTTP-запрос. Все HTTP-данные ДОЛЖНЫ быть отправлены как приложение TLS данные".
По существу, сначала устанавливается безопасный канал SSL/TLS. Только тогда используется HTTP-протокол. Это защитит весь HTTP-трафик с помощью SSL, включая заголовки HTTP (которые содержат URL-адрес и файлы cookie).
То, что может быть видно в рукопожатии, - это имя хоста, поскольку оно содержится в сертификате сервера, который будет видимым в рукопожатии (и часто бывает легко угадать имя хоста, все равно глядя на целевой IP-адрес).
При использовании имени имени сервера имя запрашиваемого хоста также должно быть видимым в расширении server_name в сообщении ClientHello.
В противном случае может быть немного двусмысленности (для подслушивающего устройства), чтобы угадать имя хоста из сертификата, если сертификат действителен для нескольких имен узлов (например, несколько объектов Alt. Имена или подстановочные знаки). В этом случае подслушивание запроса DNS от клиента может дать злоумышленнику ключ.
Читайте ответы других пользователей и комментарии, некоторые упоминают о проблемах Referer (потерял r в спецификации) и журналы.
Один из оставшихся потенциальных слабых мест - это то, как вы предоставляете эту ссылку пользователю. Если он встроен в веб-страницу, обслуживаемую простым HTTP, любой, кто может прочитать эту страницу, сможет ее увидеть. Вы также должны обслуживать такую страницу через HTTPS. Если вы отправляете эту ссылку по электронной почте, я бы сказал, что все ставки отключены, поскольку почтовые серверы редко шифруют соединения между собой и пользователями, а также часто получают доступ к своей учетной записи электронной почты без какого-либо шифрования.
EDIT:
Кроме того, если вы используете аутентификацию клиентского сертификата, сертификат клиента будет виден, если он будет согласован во время первоначального подтверждения. Это может привести к утечке имени пользователя, обратившегося к веб-сайту (часто Subject DN содержат имя пользователя). Сертификат клиента не будет отображаться, если он отправлен во время согласованного подтверждения.
Отслеживает только www.example.com. Раздел пути запроса защищен SSL/TLS.
Очевидно, что вам также необходимо отправить оригинальную гиперссылку HTTPS.
Данные запроса будут отправлены после установления безопасного соединения, поэтому не стоит беспокоиться об этом выше, но помните, что ваши данные не зашифрованы, только канал между сервером и клиентом зашифрован, если вы можете взломать этот канал, а затем можете четко видеть ваши данные,
SSL - это защищенный оболочкой канал поверх ваших данных. Если данные просты, любой, кто может взломать SSL, может четко видеть ваши данные.
Пересмотр моего ответа на НЕТ! По-видимому, только имя хоста отправляется в ясном тексте до того, как будет установлено SSL-соединение.
Что зависит...
Если вы используете пакетный сниффер, вы не можете видеть данные, отправленные по проводу. Основная проблема этого подхода заключается в том, что URL-адрес запроса часто сохраняется в журнале сервера в виде обычного текста, история браузера сохраняет URL-адрес, URL-адреса передаются в заголовках Referrer и, возможно, сохраняются сторонними службами (google analytics).