OpenSSL: прокси HTTPS

Question

До сих пор мой прокси-сервер обрабатывал только HTTP-соединения на порту 80: я хотел бы улучшить его и заставить управлять HTTPS-запросами. Вот как это работает:

Прокси прослушивает данный порт; Chrome может «видеть» прокси-сервер благодаря плагину SwitchyOmega и подключать трафик на данном порту. Прокси считывает заголовок пакета, получает запрос (я просматриваю только GET запросов до сих пор), например. GET http://www.google.it HTTP/1.1, получает имя хоста разборе www.google.it, находит IP-адрес, имя хоста разрешения с gethostbyname и предполагает, что порт сервера является номером 80.

Теперь прокси отправить на сервер, что он получил от клиента при открытии сокета: этот сокет открывается, привязывается, а затем подключается к IP-адресу, который я разрешил ранее с имени хоста.

Я прочитал here как превратить гнездо в гнездо SSL: после socket, bind, listen и accept системных вызовов, установить, что вам нужно, и передать дескриптор файла сокета для SSL_set_fd, так что я могу читать и писать данные через новый SSL файловый дескриптор.

Что (прежде всего) беспокоит меня - это создание контекста SSL: если SSLv23_server_method для серверов и SSLv23_client_method для клиентов, что я должен использовать для своего прокси-сервера?

Я не нашел конкретных прокси-серверов в OpenSSL documentation.

Заранее за вашу помощь.

Редактировать: более подробную информацию о том, как работает прокси-сервер.

Answer 1

SSL/TLS не имеет понятия прокси, только соединения точка-точка. Прокси-сервер имеет соединение с клиентом и отдельное подключение к целевому серверу, и он просто передает данные между двумя соединениями по мере необходимости. Таким образом, прокси должен защищать (или не) эти соединения независимо друг от друга, и как это должно быть, это зависит от того, как клиент запрашивает прокси-сервер для передачи HTTP.

Если клиент посылает и т.д. запрос GET/POST/к прокси-сервера, запрашивающего абсолютный HTTP URL, прокси должен подключиться к целевому серверу без использования SSL/TLS, а затем передать запрос HTTP клиента и ответ сервера обратно и далее. Клиент может или не может подключиться к вашему прокси, используя SSL/TLS. Если это так, этот сеанс находится только между клиентом и вашим прокси, а данные, считанные и отправленные клиенту, соответственно шифруются/дешифруются.

Если клиент отправляет запрос GET/POST/и т.д. для прокси-сервера, запрашивающей абсолютный URL HTTPS, прокси должен подключиться к целевому серверу и установить свою собственную SSL/TLS сессию с сервером, а затем ретранслировать клиент HTTP-запрос и ответ сервера взад и вперед. Прокси-сервер действует как клиент для сервера, поэтому используйте клиентский метод (sslv23_client_method() и т. Д.). Реальный клиент может или не может подключиться к вашему прокси с помощью SSL/TLS. Если это так, этот сеанс находится только между клиентом и вашим прокси, а данные, считанные и отправленные клиенту, шифруются/дешифруются соответственно, отдельно от шифрования, используемого при подключении к серверу.

Если клиент отправляет запрос на ваш прокси-сервер CONNECT, прокси-сервер должен подключиться к запрашиваемому хосту/порту, а затем передавать необработанные данные взад-вперед как есть. SSL/TLS не участвует в роли прокси.Если прокси-сервер обрабатывал данные SSL/TLS клиента или сервера, он будет действовать как злоумышленник MITM, что предотвратит использование SSL/TLS. Если соединение с сервером будет успешным, клиент и сервер (а не прокси) будут защищать свои конечные точки с помощью SSL/TLS, чтобы они разговаривали друг с другом напрямую (необходимо для обмена сертификатами и ключами и проверки идентификаторов). Согласование SSL/TLS и последующие зашифрованные данные запроса/ответа HTTP будут проходить через прокси-сервер как есть. Прокси-сервер мог бы видеть только необработанные зашифрованные данные, а не данные HTTP, так как только клиент и сервер имеют ключи, необходимые для дешифрования данных.