foxyproxy / firefox-extension

FoxyProxy for Firefox extension beginning with Firefox 57 (Quantum)
GNU General Public License v2.0
523 stars 115 forks source link

FoxyProxy Standard extension on Firefox doesn't work together with the Dante socks proxy (a password issue) #212

Closed aki-k closed 1 year ago

aki-k commented 1 year ago

If my Dante socks proxy user password includes the character ä FoxyProxy Standard extension on Firefox is unable to talk to the Dante socks proxy.

I tested the same password (äääää) with curl on Linux and curl + Dante socks proxy works ok.

curl -v -L -x socks5h://dante:äääää@fqdn:port/ URL

When accessing the Dante socks proxy with FoxyProxy Standard extension and the above password, I get this error message in Dante's "debug: 1" log:

accesscheck(): no match for authentication: system password authentication failed for user 'dante'
erosman commented 1 year ago

Can you please test with FoxyProxy v8.0? If the issue is not fixed in v8.0, please post to that repository for further investigation.

aki-k commented 1 year ago

@erosman I changed the Dante socks proxy user password to huhuäbubu and the dante socks proxy connection through FoxyProxy v8.0 stopped working at once. Then I changed the dante socks proxy user password to something that doesn't contain ä and FoxyProxy v8.0 started working again.

erosman commented 1 year ago

FoxyProxy doesn't alter the user/pass and sends them as they are. It is possible that Firefox encodes them and/or Dante expects encoded Unicode.

Do you have access to the transmitted data? If so, please check:

Have you tried it with any other socks proxy server?

jackyzy823 commented 1 year ago

Hello , I came from necko matrix , i made some test for you. hope it helps.

Result: 1) User/password testproxy:äääää

curl

2023/09/14 22:41:05.000629105 length=22 from=5 to=26 01 09 74 65 73 74 70 72 6f 78 79 0a ..testproxy. c3 a4 c3 a4 c3 a4 c3 a4 c3 a4 ..........

foxy

2023/09/14 22:42:22.000376446 length=17 from=3 to=19 01 09 74 65 73 74 70 72 6f 78 79 05 e4 e4 e4 e4 ..testproxy..... e4

2) Since ä has a 0xe4 format (which may not exceed uchar 255 ) , i tested a more complex password

User/password chinese:你好

curl

2023/09/14 22:47:07.000277102 length=16 from=5 to=20 01 07 63 68 69 6e 65 73 65 06 e4 bd a0 e5 a5 bd ..chinese.......

foxy

2023/09/14 22:47:56.000581016 length=12 from=3 to=14 01 07 63 68 69 6e 65 73 65 02 60 7d ..chinese.`}

jackyzy823 commented 1 year ago

Some further digging:

After this line https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.sys.mjs#232 , the password in proxyInfo is changed from "你好" to "`}"

I guess that when passing from JavaScript to c , password (in type ACString) is treat as narrow string , but underlying wide string.

I just do a test , set host to "你好" in foxy and then proxyInfo.host is just the same , because its type is AUTF8String so the JavaScript to c conversion is correct.

Ref https://searchfox.org/mozilla-central/source/netwerk/base/nsIProtocolProxyService.idl#194 Ref https://firefox-source-docs.mozilla.org/xpcom/stringguide.html


Not sure if changing idl will fix this https://searchfox.org/mozilla-central/source/__GENERATED__/dist/include/nsIProtocolProxyService.h#102-103

  /* nsIProxyInfo newProxyInfoWithAuth (in ACString aType, in AUTF8String aHost, in long aPort, in ACString aUsername, in ACString aPassword, in ACString aProxyAuthorizationHeader, in ACString aConnectionIsolationKey, in unsigned long aFlags, in unsigned long aFailoverTimeout, in nsIProxyInfo aFailoverProxy); */
  NS_IMETHOD NewProxyInfoWithAuth(const nsACString& aType, const nsACString& aHost, int32_t aPort, const nsACString& aUsername, const nsACString& aPassword, const nsACString& aProxyAuthorizationHeader, const nsACString& aConnectionIsolationKey, uint32_t aFlags, uint32_t aFailoverTimeout, nsIProxyInfo *aFailoverProxy, nsIProxyInfo **_retval) = 0;

in idl host is AUTF8String , but in c definition it is also nsACString.

So i guess change username/password in idl from ACString to AUTF8String would help ?

ericjung commented 1 year ago

The underlying Firefox code does not support Unicode or multi-byte characters string for SOCKS5 usernames and passwords. Here is my analysis:

WriteV5UsernameRequest() writes the username/password to the SOCKS5 connection:

  // RFC 1929 Username/password auth for SOCKS 5
  LOGDEBUG(("socks5: sending username and password"));
  mDataLength = Buffer<BUFFER_SIZE>(mData)
                    .WriteUint8(0x01)                     // version 1 (not 5)
                    .WriteUint8(mProxyUsername.Length())  // username length
                    .WriteString<MAX_USERNAME_LEN>(mProxyUsername)  // username
                    .WriteUint8(password.Length())  // password length
                    .WriteString<MAX_PASSWORD_LEN>(
                        password)  // password. WARNING: Sent unencrypted!
                    .Written();

RFC 1929, mentioned in the comment, does not say anything about username/password character encoding or Unicode. It is from 1996 when Unicode was not yet too common.

Anyway, that function uses WriteString to write the character string into the buffer:

  template <size_t MaxLength>
  Buffer<Size - MaxLength> WriteString(const nsACString& aStr) {
    if (aStr.Length() > MaxLength) {
      return Buffer<Size - MaxLength>(nullptr);
    }
    return WritePtr<char, MaxLength>(aStr.Data(), aStr.Length());
  }

WriteString takes an argument of type nsACString:

// Single-byte (char) string types.

using nsACString = nsTSubstring<char>;

I'm not diving any deeper to see what nsTSubString is because the comment above says 'single-byte (char) string types'. That excludes Uniode and multi-byte strings such as 你好 and ä.

jackyzy823 commented 1 year ago

I tested a build of firefox with change username/password in idl from ACString to AUTF8String and it helps.

So i opened a ticket in mozilla bugizlla https://bugzilla.mozilla.org/show_bug.cgi?id=1853203.

erosman commented 1 year ago

@jackyzy823 Thank you for all the help.

erosman commented 1 year ago

Issues is Fixed in Firefox 119.