Closed Bug 243986 Opened 20 years ago Closed 7 years ago

SOCKS5: DNS error (hostname not found) -> proxy hostname not found error

Categories

(Core :: Networking, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox53 --- fixed

People

(Reporter: benc, Assigned: xeonchen)

References

()

Details

(Whiteboard: [proxy][necko-active])

Attachments

(1 file)

STEPS:
Configure SOCKS5 w/ correct configuration.

Click on link w/ incorrect/non-existent hostname.

OBSERVED:
The error message displayed is the error for a proxy w/ a bad hostname, not the
actual connection.

EXPECTED:
The normal DNS error (under current SOCKS5 DNS behavior, see bug 134105). 

-or- correct SOCKS error handling (if that bug is ever fixed).
benc: Might it be that this bug here also applies to SOCKS4 (see Bug 276269)?
Assignee: darin → nobody
QA Contact: benc → networking
Whiteboard: [necko-backlog]
Whiteboard: [necko-backlog] → [proxy][necko-backlog]
I use OpenSSH tunneling to create a SOCKS5 server, and I can reproduce this bug.
However, the the server closes the connection ([1]) if we send an invalid host name to resolve on server side, looks like OpenSSH doesn't handle this correctly:

> debug1: channel 8: new [dynamic-tcpip]
> debug2: channel 8: pre_dynamic: have 0
> debug2: channel 8: pre_dynamic: have 3
> debug2: channel 8: decode socks5
> debug2: channel 8: socks5 auth done
> debug2: channel 8: pre_dynamic: need more
> debug2: channel 8: pre_dynamic: have 0
> debug2: channel 8: pre_dynamic: have 28
> debug2: channel 8: decode socks5
> debug2: channel 8: socks5 post auth
> debug2: channel 8: dynamic request: socks5 host nonexistent.mozilla.org port 443 command 1
> debug3: send packet: type 90
> debug3: receive packet: type 92
> channel 8: open failed: administratively prohibited: open failed
> debug2: channel 8: zombie
> debug2: channel 8: garbage collecting
> debug1: channel 8: free: direct-tcpip: listening port 1080 for nonexistent.mozilla.org port 443, connect from ::1 port 60847 to ::1 port 1080, nchannels 9

In Sec. 6 "Replies" of RFC 1928, it is supposed to response an error code instead of closing directly.

[1] https://dxr.mozilla.org/mozilla-central/rev/7083c0d30e75fc102c715887af9faec933e936f8/netwerk/socket/nsSOCKSIOLayer.cpp#1158
Assignee: nobody → xeonchen
Whiteboard: [proxy][necko-backlog] → [proxy][necko-active]
I've just tested this with TorSocks
Comment on attachment 8820642 [details]
Bug 243986 - Handle SOCKS5 remote DNS resolution error;

https://reviewboard.mozilla.org/r/100112/#review104112

ship it!
Attachment #8820642 - Flags: review?(daniel) → review+
Keywords: checkin-needed
Pushed by ihsiao@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/10aef51fa9df
Handle SOCKS5 remote DNS resolution error; r=bagder
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/10aef51fa9df
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: