Author Topic: Требуется системный программист LINUX  (Read 4944 times)

0 Members and 1 Guest are viewing this topic.

Offline sergep

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
Требуется системный программист

Задача:

Разработка модуля фильтрации контента HTTP и HTTS трафика на прокси
Разработка модуля фильтрации контента от Instance Messsenger - ов (ICQ MSN )
Администрирование сервера.

Под фильтрацией контента следует понимать процедуру вычленения заранее заданныз слов из общего потока данных.

Проект разовый но возможно обсуждение занятости на полный рабочий день с официальным трудоустройством.

Стоимость проекта договорная

Заинтересованных просьба писать: [email protected]

Offline visual

  • Hero Member
  • *****
  • Posts: 714
  • Karma: +0/-0
    • http://
Требуется системный программист LINUX
« Reply #1 on: August 23, 2006, 14:44:06 »
Quote from: sergep
Разработка модуля фильтрации контента HTTP и HTTS трафика на прокси
м.б. я чего-то не понимаю, но вы уверены в том что HTTPS технически возможно анализировать на уровне прокси? ведь после запроса вида CONNECT hostname:443 HTTP/1.1, клиент получает грубо говоря "туннель" и проксе контент будет недоступен, ибо в "туннеле" будет SSL трафик.
« Last Edit: August 23, 2006, 14:44:51 by visual »

Offline sergep

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
Требуется системный программист LINUX
« Reply #2 on: August 23, 2006, 20:08:56 »
я не уверено - тема тут открыта
однако в интернете я нашёл методы позволяющие в какиз то случаях создавая коннект уже не самом сервере - пропускать через себя поток
что позволяет добиваться результатов
в 100% работоспособности решения не уверен

Offline Safir

  • Sr. Member
  • ****
  • Posts: 402
  • Karma: +0/-0
    • http://
Требуется системный программист LINUX
« Reply #3 on: August 24, 2006, 13:12:30 »
В принципе, это возможно, но, боюсь, придётся не модуль писать, а прокси от нуля.

Если прокси будет, прозрачно для клиента, принимать CONNECT, затем принимать соединение, идущее через туннель и уже от своего имени создавать соединение с сервером, копируя запросы клиента, то всё может и получиться.

Offline demiurg

  • Moderator
  • Hero Member
  • *****
  • Posts: 1014
  • Karma: +0/-0
    • http://larin.tomsk.ru
Требуется системный программист LINUX
« Reply #4 on: August 24, 2006, 13:46:46 »
Quote from: Safir
В принципе, это возможно, но, боюсь, придётся не модуль писать, а прокси от нуля.

Если прокси будет, прозрачно для клиента, принимать CONNECT, затем принимать соединение, идущее через туннель и уже от своего имени создавать соединение с сервером, копируя запросы клиента, то всё может и получиться.
А как быть с обменом ключами и сертификатами?
Если я не ошибаюсь, то HTTPS защищен от атак типа man-in-middle, что как раз в этом случае и происходит. Хотя если не принципиально скрывать от клиента факт перехвата трафика, то такой вариант наверное "прокатит".

Offline Safir

  • Sr. Member
  • ****
  • Posts: 402
  • Karma: +0/-0
    • http://
Требуется системный программист LINUX
« Reply #5 on: August 25, 2006, 13:16:33 »
Quote from: demiurg
А как быть с обменом ключами и сертификатами?
Если я не ошибаюсь, то HTTPS защищен от атак типа man-in-middle, что как раз в этом случае и происходит. Хотя если не принципиально скрывать от клиента факт перехвата трафика, то такой вариант наверное "прокатит".
С сертификатами да, облом выйдет, а в остальном - должно прокатить.  Если это, скажем, официальная политика фирмы, то пользователю остаётся только тихо согласиться. В пинципе, я даже где-то такую политику понимаю.

Offline SG_

  • Full Member
  • ***
  • Posts: 157
  • Karma: +0/-0
Требуется системный программист LINUX
« Reply #6 on: August 25, 2006, 14:51:05 »
Quote from: Safir
С сертификатами да, облом выйдет, а в остальном - должно прокатить.  Если это, скажем, официальная политика фирмы, то пользователю остаётся только тихо согласиться. В пинципе, я даже где-то такую политику понимаю.
а я нихера не понимаю. грубо вламываться в обмен между клиентом и сервером чревато косяками. после такого девайса посередине юзеру будет подсовываться либо самопальный сертификат на все конекты, либо вообще редирект на http порт данной прокси, что тоже чревато косяками.

меня тоже напрягает, что https запросы не кешируются (картинки) ни жмутся, но такова реальность.
чего хочет получить заказчик мне непонять.  в 99% получится говно.

Offline demiurg

  • Moderator
  • Hero Member
  • *****
  • Posts: 1014
  • Karma: +0/-0
    • http://larin.tomsk.ru
Требуется системный программист LINUX
« Reply #7 on: August 25, 2006, 17:26:49 »
Quote from: SG_
а я нихера не понимаю. грубо вламываться в обмен между клиентом и сервером чревато косяками. после такого девайса посередине юзеру будет подсовываться либо самопальный сертификат на все конекты, либо вообще редирект на http порт данной прокси, что тоже чревато косяками.

меня тоже напрягает, что https запросы не кешируются (картинки) ни жмутся, но такова реальность.
чего хочет получить заказчик мне непонять.  в 99% получится говно.
Проблема в связке клиент ---https#1-->proxy--https#2-->web-сервер только одна -- один сертификат для всех клиентских коннектов, что вызовет "недовольное бурчание" web-браузеров.

А получится скорее всего действительно гуано. Как я понимаю, задача такой системы "следить за контентом пользователей", тут действиельно полно проблем -- как следить и кто результаты будет разгребать. Эффективность, как мне кажется, близка к нулю, с таким же успехом к каждому сотруднику можно приставить по соглядатаю.

Offline visual

  • Hero Member
  • *****
  • Posts: 714
  • Karma: +0/-0
    • http://
Требуется системный программист LINUX
« Reply #8 on: August 25, 2006, 23:51:51 »
Quote from: demiurg
Эффективность, как мне кажется, близка к нулю, с таким же успехом к каждому сотруднику можно приставить по соглядатаю.
когда паранойя зашкаливает, проще загнать всех инетчиков на терминальный сервер, обрезав инет на рабочих местах. а уж трейсить https с клиентской машины, в роли которой будет выступать терминальный сервер, дело техники. и никаких косяков с сертификатами, рисованием layered service provider и т.п.