Bug 741793

Summary:	"auth strong" doesn't seem to be working with md4/5 hashes
Product:	[Fedora] Fedora	Reporter:	Mr-4 <mr.dash.four>
Component:	3proxy	Assignee:	Pavel Alexeev <pahan>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	pahan
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-07 15:37:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Mr-4 2011-09-27 22:06:20 UTC

Description of problem:
When I configure the following proxy:

users "test:CR:$1$qwer$CHFTUFGqkjue9HyhcMHEe1"
auth strong
flush
allow test 127.0.0.1
proxy -a -i127.0.0.1 -p12799

and then start the browser, directing this to the new proxy service I get the user/password prompt from the browser, but when I try to enter the user (test) and the password (test) 3proxy does NOT accept it. 

When I then tried "mycrypt qwer test" that produces the above hash, I get the same result - CR:$1$qwer$CHFTUFGqkjue9HyhcMHEe1 - which isn't accepted by 3proxy, but when I execute "mycrypt test" and enter the new result (NT:0CB6948805F797BF2A82807973B89537) as part of the users option (i.e. "users test:NT:0CB6948805F797BF2A82807973B89537") that seems to be working and I can log on through my browser and use the proxy as normal.

Version-Release number of selected component (if applicable):
The latest version (0.6.1) as distributed with fc15

How reproducible:
always

Steps to Reproduce:
1. configure the above proxy (make sure fakeresolve is NOT present)
2. start 3proxy
3. try logging in using any modern browser
  
Actual results:
Password failure

Expected results:
Using the proxy after successful login

Additional info:

Comment 1 Pavel Alexeev 2011-10-08 18:56:55 UTC

Hm.

I can't reproduce that.

Default configuration of 3proxy have such:
users 3APA3A:CL:3apa3a "test:CR:$1$qwer$CHFTUFGqkjue9HyhcMHEe1"

So, as I test it out of the box it is accepted like a charm, look:

$ LANG=C http_proxy=http://127.0.0.1:3128 wget --proxy-user=test --proxy-password=test http://fedoraproject.org --spider
Spider mode enabled. Check if remote file exists.
--2011-10-08 22:56:08--  http://fedoraproject.org/
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 22524 (22K) [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.


I do not see any troubles. Please test with default config and say if it works for you.

Comment 2 Mr-4 2012-02-07 15:37:52 UTC

The above error was caused by the overzealous SELinux policy I have deployed on that machine, preventing 3proxy access to the resources it requires (random/urandom etc), so I am closing this bug!