Назад | Перейти на главную страницу

Проблема с получением прозрачного прокси-сервера Squid при работе с ssl

У меня есть среда, состоящая из четырех серверов, объединенных в сеть. Один сервер действует как сервер, а три других действуют как клиенты для запуска автоматических тестов и тестирования производительности Linux с использованием Phoromatic.

Все четыре системы защищены корпоративным межсетевым экраном. Если я устанавливаю переменные среды http_proxy и https_proxy на клиентах, они могут подключаться к внешнему миру и загружать тесты и т. Д., Однако они не будут подключаться к серверу, поскольку они пытаются подключиться к локальному серверу с помощью прокси. . Поскольку я хотел кэшировать загрузки пакетов, тесты и т. Д., Я установил прокси-сервер Squid в серверной системе и настроил его как прозрачный прокси, но он работает только с HTTP-запросами.

Я бы хотел, чтобы HTTP-запросы обрабатывались через кеш и при необходимости перенаправлялись на родительский прокси. Очевидно, я не могу расшифровать сеансы ssl, но я не могу понять, как заставить прокси-сервер Squid пересылать https-запросы родительскому прокси. Кроме того, прокси-сервер Squid работает на том же компьютере, что и сервер Phoromatic, который основан на Интернете, но использует настраиваемый пользователем нестандартный порт, но Squid любит блокировать запросы к указанному порту, даже если он добавлен в конфигурацию как разрешенный.

Я был бы в порядке, если бы клиенты использовали корпоративный брандмауэр напрямую для запросов https и ftp и либо просто использовали кеш Squid для HTTP-запросов, либо вообще отказались от прокси-сервера Squid и настроили клиентов, чтобы не использовать прокси для локальных хостов.

Это меня действительно расстраивает, так как большую часть времени я отлично ловлю информацию и заставляю все работать самостоятельно, без необходимости ломать голову над этим, но я думаю, что у меня довольно уникальная ситуация! И да, я пробовал форум Phoronix для Phoromatic безрезультатно.

Серверы представляют собой системы с двумя шасси SuperMicro X8DTT под управлением Fedora 24. Сетевая конфигурация состоит из подключения GbE к коммутатору (используется как соединение с внешним миром), а также двух 10 ГБ в каждой системе, также подключенных через коммутатор, но система 10 ГБ не подключен к внешнему миру - они используются для тестирования пропускной способности (драйверы для карт 10 ГБ - это то, что система настроена для тестирования)

Я буду краток (да, он вообще не выглядит коротким, но в противном случае он был бы намного длиннее и совершенно нечитабельным).

  • не похоже, что вам нужен прокси. вроде полностью.
  • в современной среде коэффициент кэширования может составлять от нуля до 40% (и я сужу на основе байтовых соотношений моих прокси), поэтому, если вы хотите сохранить этот объем данных, вы, конечно, можете использовать прокси. Но учтите следующее: в сегодняшней корпоративной среде роль прокси-сервера больше заключается в авторизации пользователей на пути к доступу к глобальной сети, чем в кэшировании данных. И это главная причина сомневаться в своем выборе.
  • если вам все еще нужен прокси, это не значит, что вы иметь для расшифровки HTTPS. просто позволь этому жить. он не будет кэширован, ну и что. Это в его дизайне.
  • если вы все еще настаиваете на расшифровке HTTPS - вы можете использовать sslBump техника. Но в некоторых странах это может быть незаконным, и, кроме того, это сильно усложняет ситуацию. подобно МНОГО. Советую не идти этим путем только в целях кеширования.
  • не обслуживайте локальный трафик через прокси: это увеличивает задержку, загружает прокси-сервер ненужным трафиком (поскольку он дешев, а каналы LAN намного шире, чем WAN), это усложняет отладку и добавляет паразитные сетевые зависимости, поэтому это неразумно.
  • поскольку я сомневаюсь, что вам нужен прокси, я еще больше сомневаюсь, что вам нужен родительский прокси. Похоже, у тебя просто такая штука .... ну знаешь, прокси. используйте один, если он вам нужен.
  • может быть вместо прокси вам просто нужен быстрый и достойный веб-сервер, строка nginx. Таким образом, в ситуации, когда ваши веб-серверы перегружены, он может действовать как балансировщик для фермы с l2-кешем.
  • squid не так хорошо масштабируется. для 10-гигабайтной полосы пропускания придется использовать SMP squid особенности, и у этого есть свои недостатки. Например, несбалансированная нагрузка на рабочих Squid, проблемы SMP во внутреннем устройстве Squid и так далее. Это может быть решено, если у вас есть предыдущий опыт работы с squid, но вряд ли, если вы настроили как впервые.
  • наконец, если вы решите придерживаться squid, он не должен быть прозрачным: вы можете настроить WPAD для клиентов и позволить серверам решать, как им подключаться к Интернету.

Я установил прокси-сервер Squid в серверной системе и настроил его как прозрачный прокси, но он работает только с HTTP-запросами.

Это ожидается, поскольку HTTP и HTTPS работают по-разному и не могут обрабатываться одинаково через прокси. Когда HTTPS-запрос перенаправляется на порт прокси-сервера прозрачно, прокси-сервер не может просматривать зашифрованный трафик и, следовательно, не может его обработать. А прозрачный proxy на самом деле работает больше как «человек посередине», который перехватывает http-трафик, не зная об этом пользователям, что возможно из-за отсутствия безопасности в http-протоколе.

https://en.wikipedia.org/wiki/HTTPS

HTTPS (также называемый HTTP через TLS, [1] [2] HTTP через SSL, [3] и HTTP Secure [4] [5]) - это протокол для безопасной связи по компьютерной сети, который широко используется в Интернете. HTTPS представляет собой обмен данными по протоколу передачи гипертекста (HTTP) в соединении, зашифрованном с помощью Transport Layer Security или его предшественника, Secure Sockets Layer. Основным мотивом использования HTTPS является аутентификация посещаемого веб-сайта и защита конфиденциальности и целостности передаваемых данных.

В своем популярном развертывании в Интернете HTTPS обеспечивает аутентификацию веб-сайта и связанного с ним веб-сервера, с которым он взаимодействует, что защищает от атак типа «злоумышленник в середине». Кроме того, он обеспечивает двунаправленное шифрование связи между клиентом и сервером, что защищает от подслушивания, взлома и / или подделки содержимого сообщения. [6] На практике это обеспечивает разумную гарантию того, что человек общается именно с тем веб-сайтом, с которым он намеревался общаться (в отличие от самозванца), а также гарантирует, что содержимое сообщений между пользователем и сайтом не может быть прочитано или подделано любая третья сторона.

Как видите, HTTPS должен защищать от человека в средней атаке и не допускать этого. Следующая страница Squid подробно объясняет все ваши вопросы и недоразумения.

http://wiki.squid-cache.org/Features/HTTPS

Когда браузер встречает URL https: //, он делает одно из двух:

  • открывает SSL / TLS-соединение напрямую с исходным сервером или

  • открывает TCP-туннель через Squid к исходному серверу, используя метод запроса CONNECT.

Взаимодействие Squid с этими двумя типами трафика обсуждается ниже.

CONNECT туннель

Метод CONNECT - это способ туннелирования любого типа соединения через HTTP-прокси. По умолчанию прокси устанавливает TCP-соединение с указанным сервером, отвечает ответом HTTP 200 (соединение установлено), а затем пересылает пакеты туда и обратно между клиентом и сервером, не понимая и не интерпретируя туннелированный трафик. Для получения подробных сведений о туннелировании и методе CONNECT см. RFC 2817 и черновик устаревших протоколов на основе TCP через веб-прокси.

ПОДКЛЮЧИТЬ туннель через Squid

Когда браузер устанавливает туннель CONNECT через Squid, средства контроля доступа могут управлять запросами CONNECT, но доступна только ограниченная информация. Например, многие общие части URL-адреса запроса не существуют в запросе CONNECT:

  • схема URL или протокол (например, http: //, https: //, ftp: //, voip: //, itunes: // или telnet: //),

  • путь URL (например, /index.html или / secure / images /),

  • и строка запроса (например,? a = b & c = d)

При использовании HTTPS вышеуказанные части присутствуют в инкапсулированных HTTP-запросах, которые проходят через туннель, но Squid не имеет доступа к этим зашифрованным сообщениям. Другие туннелированные протоколы могут даже не использовать HTTP-сообщения и URL-адреса (например, telnet).

Когда браузер настроен на использование прокси вручную, он использует метод CONNECT, упомянутый выше, и он работает. При этом есть способы настроить прозрачный прокси для перехвата трафика https (ssl-bump), что не является обычным, не рекомендуется и должно использоваться с осторожностью.

Пробираемся через туннели CONNECT

{X} ВНИМАНИЕ! {X} HTTPS был разработан, чтобы дать пользователям надежду на конфиденциальность и безопасность. Расшифровка туннелей HTTPS без согласия или ведома пользователя может нарушать этические нормы и может быть незаконной в вашей юрисдикции. Функции расшифровки Squid, описанные здесь и в других местах, предназначены для развертывания с согласия пользователя или, по крайней мере, в средах, где расшифровка без согласия является законной. Эти функции также демонстрируют, почему пользователям следует быть осторожными с доверием к HTTPS-соединениям и почему самое слабое звено в цепочке защиты HTTPS является довольно хрупким. Расшифровка туннелей HTTPS представляет собой атаку «злоумышленник посередине» с точки зрения общей сетевой безопасности. Инструменты атаки похожи на атомную бомбу в реальном мире: убедитесь, что вы понимаете, что делаете, и что лица, принимающие решения, обладают достаточной информацией, чтобы сделать разумный выбор.

Squid SslBump и связанные с ним функции могут использоваться для расшифровки туннелей HTTPS CONNECT, когда они проходят через прокси-сервер Squid. Это позволяет работать с туннелированными HTTP-сообщениями, как если бы они были обычными HTTP-сообщениями, в том числе применять подробный контроль доступа и выполнять адаптацию контента (например, проверять тела запросов на утечку информации и проверять ответы на вирусы). Ошибки конфигурации, ошибки Squid и злонамеренные атаки могут привести к выходу незашифрованных сообщений за пределы Squid.

С точки зрения браузера, инкапсулированные сообщения не отправляются на прокси. Таким образом, здесь также применяются общие ограничения перехвата, такие как невозможность аутентификации отдельных встроенных запросов.