Я пытаюсь устранить проблему для пользователя моей службы https://jsonip.com.
На прошлой неделе я включил принудительное перенаправление 301 для всех соединений http на https.
Пользователь, которому я сейчас пытаюсь помочь, полагался на то, что его внутренний IP-адрес был добавлен в заголовок x-forward-for его корпоративным прокси. Теперь, когда все соединения принудительно устанавливаются на https, он предоставляет только его общедоступный IP-адрес.
Я думаю, что его корпоративный прокси не вставляет свой собственный сертификат в https-соединения, поэтому не может проверить соединение и вставить / обновить заголовок x-forward-for с IP-адресами прокси.
Если да, то это хорошо для индивидуальной конфиденциальности сотрудников (босс не может перехватывать веб-трафик), но в противном случае мешает тому, как пользователь использовал jsonip.com.
Может ли кто-нибудь подтвердить / опровергнуть, имеет ли мое предположение смысл?
Когда браузер использует прокси-сервер, он будет использовать метод CONNECT для создания прямого подключения к удаленному веб-сайту. Это соединение использует протокол SSL / TLS, и браузер будет связываться напрямую и без каких-либо изменений с удаленным веб-сайтом. Заголовки запросов и ответов или любая часть коммуникации не изменяются прокси.
Внутренние IP-адреса считаются конфиденциальной информацией, и прокси-сервер не должен их пересылать. По соображениям безопасности клиент, который жалуется, должен использовать локальную службу, аналогичную той, что предлагает ваш сервер.
С другой стороны, я не понимаю, почему вы не должны предлагать услугу в незашифрованном виде, если нет аутентификации или других конфиденциальных данных, которые ваша служба получает или отправляет.
Единственный способ иметь прокси, который расшифровывает и изменяет трафик, - это прокси, который создает по запросу сертификаты, подписанные центром сертификации, которому доверяет веб-браузер. Я ожидаю увидеть это в очень контролируемой среде. Видеть Эта статья и технический аналог для примера такого прокси.