LINUX.ORG.RU
ФорумAdmin

SQUID и digest_auth


0

0

Здавствуй, ALL!!! Кто реализовал сабж? Скомпилировал Сквиду с поддержкой аутентификации digest. Вроде все установил и создал файл с паролями при помощи htdigest из апача. Цепляюсь Oper'ой к проксе. Выпадает окошко с полями логина и пароля --> ввожу их самых --> доступ к кэшу запрещен. Че за фигня??? может htdigest неправильно синтаксис в файл пишет или что???

Заранее спасибо за помощь.

anonymous

Как оно все происходит и как правильно надо не скажу, но могу написать как оно у меня получалось:
делал все так же само и все так же само выходило - доступ не давало. Начал копать глубже - нарыл то, что оказывается пароль в файле должен быть не шифрованый. Попробовал - получилось.
Стало непонятно почему apache с digest_auth умеет пользоваться зашифрованным паролем в файле, а squid (точнее его auth_program для этого типа аутентификации) требует plain text password.
Выяснилось, что squid-у не нужен plain text пароль, он берет шифрованный, а шифрует его эта самая аутентификационная программка из plain text пароля. Появился еще 1 вопрос: "А почему бы сразу не хранить шифрованный пароль на винте и тупо (не шифруя на ходу) отдавать его squid-у, ему ведь именно такой и нужен ???"
Попытался руками поговорить с аутентификационной программкой, она действительно выдает такой пароль, какой получается и с помощью апачевской htdigest (причем всегда 1 и тот же).
Попробовал написать свою auth program (на perl-е правда), которая из файла, созданного с пом. htdigest, берет уже шифрованный пароль и тупо отдает его squid-у. Чисто для эксперимента создавал только 1-го user-а и возвращал всегда только один password.
Результат: при вводе login-а отличного от того, что создавал, и любого password-а squid не дает доступа (что есть правильной реакцией), но если ввести login правильный, а password какой угодно - доступ есть. Почему такое получалось - без понятия, ведь всегда возвращался 1 и тот же шифрованный пароль (как и стандартной auth program).

Если у кого-нибудь получилось сделать так, чтоб все работало и при этом не нужно было хранить пароли в открытом виде, я был бы очень рад узнать КАК :-)

P.S. Опыты проводил над squid-2.5.STABLE1 (был самый последний на тот момент).

spirit ★★★★★
()

т.е. получается, что аутентификация при помощи ncsa_auth надежнее? (в смысле шифрования пароля) и сам digest_auth - некая экспериментальная программа аутентификации. К сожалению в ncsa_auth логин и пароль передается в открытом виде => их можно отловить банальным сниффером. Хотелось бы узнать про модули аутентификации, которые передают пароль в зашифрованном виде, в частности про pam-модуль.

Пробовал помещать в файл пароль и логин plain text - работает ведь зараза, тогда непонятно на кой черт squid шифрует их при получении, шифрует пароль и логин из файла digpass и сравнивает, по моему геморой какой-то или корявый понт разработчиков squid. Еще один вопрос: может быть сам интернет браузер не поддерживает digest_auth, тогда зачем он (digest_auth) нужен на самом деле?

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

----=====Заранее спасибо (автор сабжа).

anonymous
()

Очень давно об этом не чтал, но раньше было так: для digest-auth считается контрольная сумма чего-то с паролем и она передается в канал. Соответственно хеш пароля не проходит - откуда клиенту знать, как он хеширован на сервере. В случае же plain сервер получает пароль и можен сравнивать вычисленный хеш с тем, что хранится у него. Вопрос надежности спорный - по моему легче защитить 1 файл на сервере чем весь маршрут от клиента до сервера.

А бровзеры действительно могут не поддерживать digest-auth

DonkeyHot ★★★★★
()

> ncsa_auth надежнее? (в смысле шифрования пароля)
Вы же сами ниже отвечаете, что нет :-)
Кстати, ncsa_auth - это не тип аутентификации, а всего лишь аутентификационная программка, а используемый тип при этом - Basic auth. При этом типе идет Base64 кодирование паролей, т.е. можно сказать никакого шифрования нет.

> в частности про pam-модуль
PAM-модуль не поможет, т.к. он должен запускаться на сервере, а как сервер будет получать пароль по сети это уже не его забота, что как раз в данный момент и является ключевым фактором :-)

> может быть сам интернет браузер не поддерживает digest_auth
Последние версии должны поддерживать, по-моему это вещь не новая (моя Opera 6.0 умеет работать с digest auth).
Можно попробовать digest auth на apache, если он скомпилен с модулем "mod_auth_digest.c": создать в каком-то каталоге .htdigest с login-ами/паролями и .htaccess и попробовать залезть туда:
--- .htaccess ---
AuthName realm
AuthType Digest
AuthDigestFile /полный/путь/к/файлу/.htdigest
Require valid-user

spirit ★★★★★
()

2 DonkeyHot:
> по моему легче защитить 1 файл на сервере чем весь маршрут от
> клиента до сервера

Но ведь apache умеет хранить и на винте в шифрованном виде, и digest auth спрашивать у клиентов, и не глючить при этом !

spirit ★★★★★
()

Защита файла на сервере это одно, а вот как сделать чтобы пароль на сервер передавался в шифрованном виде - компилить сквиду с поддержкой OpenSSL? Ведь проблема то как раз и состоит в том, что необходимо защитить маршрут клиент-сервер, чтобы злоумышленники не "пронюхали" кто есть кто и какие пароли на доступ к кэшу.

anonymous
()

последнему anonymous-у: digest аутентификация как раз и позволяет передавать пароли в шифрованном виде (MD5).

spirit ★★★★★
()

Ну тогда все круто. Всем спасибо.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.