Возможна ли прозрачная переадресация https ---> [http | https]?
Добрый день!
Интересует возможность переадресации запроса на 443 порт (https) на угодный мне ресурс, но с небольшими поправками.
Можно это делать при помощи firewall'а. Но при этом нужен самоподписанный сертификат, от которого будут воротить нос все браузеры. Генерировать и добавлять корневой сертификат не нужно.
Нужно при запросе на 443 порт максимально, на сколько это возможно, прозрачно (без ругани браузеров на сертификат, установки коневого сетификата и прочих вещей требующих какие либо манипуляции с клиентским устройством) для клиента завернуть его на портал авторизации. Iptables и [REDIRECT | DNAT] не подходят, если нет IntranetSSL (дорогое решение). Squid и SSL Bump насколько я понял, также требует установки корневого сертификата.
Прошу помощи у более опытных и знающих участников сообщества.
hloe0xff, это одно и тоже. Редирект вы можете отправить только в ответ на запрос, а значит вы уже увидели что именно запрашивал клиент. А это уже внедрение и прослушка.
Алексей Тен, Нет. Если мне не изменяет память шифроканал ни как не связан с http протоколом и как следствия с ответами сервера.
Сервер поднимает полноценный шифроканал и внутри онного в ответ на http-запрос ресурса отсылает код 301 http://подти_туда.ру/ то браузер не имеет права отказаться от такого перенаправления.
шифроканал гарантирует что в канал имеют доступ только ты и сервер и никаких третьих лиц проникнуть не может.
С какой тогда стати не верить команде сервера не редиректинг запроса ??
Алексей Тен, речи о подмене нет. Я хочу каким нибудь образом перебросить клиента на нужный мне адрес. Каким образом это можно сделать и можно ли вообще, я и спрашиваю. Я вроде всё описал в вопросе. Может есть какие то неявные моменты в нем? Скажите, я поправлю. Но изначально не было и нет цели подмены. Только redirect (как вариант на доменное имя). На уровне веб сервера (301 и 302), на уровне iptables (REDIRECT и DNAT) или прокси. Это все способы или кто то сталкивался с другими способами?
hloe0xff, я набрал в браузере адрес https://google.com и ожидаю ответ от гугла. Вы же хотите вместо этого куда-то меня средиректить. Это по определению подмена ответа гугла.
К счастью HTTPS этого не позволяет.
hloe0xff, я так понял вам нужна авторизация на сайте, в который авторизация не встроена ??
тогда такой вариант: на сервер, куда стучится клиент, ставите скрипт авторизации, который будет, к примеру, ослеживать авторизировацию клиентов по кукам. т.е. нет правильных куков - выдается окно авторизации, есть правильные куки - запрос клиента проксируется на сайт без авторизации ??
поищите такой скрипт, известная задача
перенаправление через iptables может прокатить если кроме dnat сделать еще snat, ну и сбанчить правильно сертификатами
pfg21, авторизация в wifi сети. Проверяю по mac адресу. Есть set с mac адресами авторизованных, их я пускаю в инет как есть. Те клиенты которых там нет, заворачиваю на авторизацию и добавляю в set. Если отсутствующий клиент пытается сделать запрос на 80 порт (http), заворачиваю на localhost тем же iptables и делаю http 302. С этим проблем нет. Есть момент когда не прошедший процедуру авторизации клиент делает запрос на 443 порт. Не используя установку корневого сертификата, гладко эта процедура не пройдет. Хочу с этим моментом разобраться. Могу ошибаться, но вроде в некоторых готовых продуктах такое есть.
hloe0xff, https сравнивает значение поля Common name полученного сертификата (в нем содержится имя сервера) с сервером в запросе.
у тебя естественно не будет нужных сертификатов.
это не изъян - это средство защиты от подмены адреса.
