Если вы используете HTTPS, ваши параметры URL будут безопасны от обнюхивания?
Предположим, что я устанавливаю простой веб-сервер php со страницей, к которой можно получить доступ через HTTPS. URL имеет простые параметры, например https://www.example.com/test?abc=123
.
Верно ли, что параметр здесь в этом случае будет безопасен для людей, обнюхивающих пакеты? И будет ли это верно, если сервер не использует SSL-сертификат?
Ответы
Ответ 1
Да, ваш URL-адрес будет безопасным от обнюхивания; однако одно отверстие, которое легко упускать, - это если ваша страница ссылается на любые сторонние ресурсы, такие как Google Analytics, "Добавить контент", весь URL будет отправлен третьей стороне в реферере. Если он действительно чувствителен, он не входит в строку запроса.
Что касается вашей второй части вопроса, вы не можете использовать SSL, если у вас нет сертификата на сервере.
Ответ 2
http://answers.google.com/answers/threadview/id/758002.html
HTTPS Устанавливает базовый SSL coninction, прежде чем любые данные HTTP будут переданы. Это гарантирует, что все URL-адреса данные (за исключением имени хоста, который используется для соединение) осуществляется исключительно внутри это зашифрованное соединение и защищен от человека в середине атаки так же, как любой HTTPS данные.
Все транзакции на уровне HTTP в пределах Соединение HTTPS осуществляется внутри установленной SSL-сессии, и нет данные запроса передаются до установлено безопасное соединение.
Извне единственные данные, которые видимый миру, это имя хоста и порт, к которому вы подключаетесь. Все остальное - это просто поток двоичные данные, которые шифруются с использованием закрытый ключ, разделяемый только между вами и сервер.
В примере, который вы предоставили браузер сделает это:
- Выведите имя хоста (и порт, если присутствует) из от URL.
- Подключиться к хосту.
- Проверить сертификат (он должен быть "подписан" по известным полномочиям, применять конкретно для исправления IP-адреса и порта и текущий).
- Браузер и сервер обмена криптографическими данными и браузер получает закрытый ключ.
- Выполняется HTTP-запрос, зашифрованный с помощью установленной криптографии.
- Получен ответ HTTP. Также зашифрован.
HTTP - это "уровень приложения", протокола, он переносится поверх защищенный слой. Согласно SSL спецификация, составленная Netscape, диктует, что ни один прикладной уровень данные могут передаваться до тех пор, пока соединение установлено - как изложенные в следующем абзаце:
"На данный момент спецификация шифрования изменений сообщение отправляется клиентом, а клиент копирует ожидающий Cipher Spec в текущую спецификацию Cipher. клиент немедленно отправляет готовое сообщение под новым алгоритмы, ключи и секреты. В ответ, сервер отправит свои изменить сообщение спецификации шифрования, передать ожидающий текущий шифр Spec и отправить свое завершенное сообщение в соответствии с новой спецификацией Cipher. В этот точка, рукопожатие завершено и клиент и сервер могут начать обмениваться данными уровня приложения". http://wp.netscape.com/eng/ssl3/draft302.txt
Так что да. Данные, содержащиеся в URL-адресе запроса по соединению HTTPS зашифрованы. Однако он очень плохойпрактика включает такие чувствительные данные как пароль в поле 'GET' запрос. Хотя это не может быть перехваченные данные будут регистрироваться в журналах с открытым текстом на прием HTTPS-сервера, и вполне возможно, также в истории браузера. Это возможно, , также доступный браузеру плагины и, возможно, даже другие приложений на клиентском компьютере. Не более HTTPS-URL может быть разумно разрешено включать идентификатор сеанса или аналогичные нерегуляционные переменная. Он НИКОГДА не должен содержать статические маркеры аутентификации.
Концепция HTTP-соединения больше всего ясно объяснено здесь: http://www.ourshop.com/resources/ssl_step1.html
Ответ 3
Запрошенный URI (/test? abc = 123) отправляется на веб-сервер как часть заголовка HTTP-запроса и, таким образом, зашифровывается.
Однако URL-адреса могут протекать другими способами, как правило, панелями веб-браузера, закладками и отправкой ссылок друзьям. Данные POSTing могут быть более уместными в зависимости от контекста/чувствительности отправляемых данных.
Я считаю, что для подключения HTTPS требуется сертификат SSL, даже самогенерируемый, если вы не хотите его покупать.
Надеюсь, что это поможет!
Ответ 4
зависит от того, что вы подразумеваете под безопасным
SSL шифрует весь HTTP-запрос/ответ, поэтому URL-адрес в части GET будет зашифрован. Это не останавливает атаки MITM и повреждение целостности самой сессии SSL. Если используется неавторитарный сертификат, это делает потенциальные атаки более простыми.
Заголовки запросов REST, зашифрованные SSL?
Это аналогичный вопрос.
Ответ 5
URL-адрес: s будет храниться как в журналах сервера, так и в истории браузера, поэтому, даже если они не являются ненадежными, они далеки от безопасности.
Ответ 6
На проводе, да. В конечных точках (браузер и сервер) необязательно. SSL/TLS безопасность транспортного уровня. Он будет шифровать ваш трафик между браузером и сервером. На стороне браузера можно заглянуть в данные (например, уровень безопасности сообщений.
Ответ 7
SSL/TSL - это безопасность транспортного уровня, да, данные могут быть выбраны с помощью BHO (как написано @JP) или любого добавления, но также с "снифферами" HTTP-браузера. Они читают сообщения между winsock32 и приложением. Шифрование происходит в winsock32 не в браузере.
Взгляните (эта часть была отмечена со страницы IEinspector):
IEInspector HTTP Analyzer - это удобный инструмент, который позволяет отслеживать, отслеживать, отлаживать и анализировать HTTP/ HTTPS трафик в режиме реального времени.