909021 - Firefox is not able to connect to a SOCKS-Proxy with IPv6 in square brackets

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Erik]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux) Firefox
Build ID: 20130329043827

Steps to reproduce:

I try to configure a SOCKS5-Proxy what is only accessible with IPv6.
No way is working, neither direct input by UI nor with a PAC-Script that returns "SOCKS5 [IPv6-Address]:Port-Number".
I have tried a Connection to ::1 to a local SOCKS-Proxy (created with "ssh -D [::1]:1234 host") and a Connection to a real Proxy that is present in the local Network. The HTTP-Server that runs on the same Host as the Proxy is accessible by Firefox and if i configure Firefox to automatic detection for Proxy than Firefox successful loads the wpad.dat but do even not connect to the SOCKS-Proxy.
I have tested it with Firefox 20, Firefox 23 and newest Firefox Nightly on 32 Bit Linux and 64 Bit Linux.
A actual Version of Chromium works correctly, in automatic proxy configuration it reads the PAC-Script and use the SOCKS5-Proxy correctly for all external Web-Pages.


Actual results:

Firefox do not connect to the Proxy, Firefox do not start a TCP-Connection to the SOCKS5-Proxy. I see no Traffic to the SOCKS5-Proxy with wireshark.


Expected results:

Firefox should connect to the Proxy and use it for accessing the desired Web-Page.

Comment 1

[Erik]

with the actual Firefox Version 30 the Problem is still present

Firefox is in a IPv6-only local Network not able to access the Internet through a SOCKS-Proxy!
Independent of Operating System and Platform.

Other Browsers, Chromium and Safari and Internet Explorer, working correct.

Comment 2

[Daniel Stenberg [:bagder]]

I just successfully tried this with firefox nightly (34):

$ ssh -D '[::1]:9080' [my remote ssh-server]

... then in firefox I told it to use socks5 proxy on ::1 port 9080. I can then browse the Internet fine, and running wireshark on my local machine I can see IPv6-only traffic and I can see that everything is going over the proxy.

Is that a setup that would cause the problem to trigger for you?

Comment 3

[Erik]

> I told it to use socks5 proxy on ::1 port 9080
The interesting part is "::1" (without quotes) that do _not_ have squared brackets.

I have tested this Problem again and when i enter the Proxy-IP-Address into the UI without brackets then it works, Firefox is able to access the SOCKS-Proxy and the Internet. If i enter Proxy-IP-Address with brackets then Firefox do nothing. I can not find any Error-Message, neither in the UI nor in any Developer-Tools-Console. Firefox say all okay but response length is 0 bytes.

Then i configure the UI to "auto-detect the proxy settings for this network" than Firefox load the PAC-Script (conform to the "Web Proxy Autodiscovery Protocol") and do nothing if the Script returns with
> return "SOCKS5 [2001:db8::dead:beaf]:8888";
In the Proxy-Script can the squared brackets not avoided because it need a difference to the Port-Number.

Okay, the Bug is not in the TCP-Component but Firefox is not able to use a IPv6-Address with squared brackets.
This is in my Opinion a critical Bug too.
In the PAC-Scripts are the brackets a "must have" and Firefox do not support it.
I hope this is a small Bug and it can fixed soon.

In my Network-Environment i can not relinquish to the PAC-Script, the capabilities of Firefox for the decision job for selecting the proxy or connection directly to the desired Host are not enough.

Comment 4

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 7

[grzchr15]

Any progress to support IPv6 address, albeit in brackets?
Firefox at Desktop works fine with [ipv6]
https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2
Berners-Lee, et al. Standards Track [Page 18]
RFC 3986 URI Generic Syntax January 2005

The host subcomponent of authority is identified by an IP literal
encapsulated within square brackets, an IPv4 address in dotted-
decimal form, or a registered name. The host subcomponent is case-
insensitive. The presence of a host subcomponent within a URI does
not imply that the scheme requires access to the given host on the
Internet. In many cases, the host syntax is used only for the sake
of reusing the existing registration process created and deployed for
DNS, thus obtaining a globally unique name without the cost of
deploying another registry. However, such use comes with its own
costs: domain name ownership may change over time for reasons not
anticipated by the URI producer. In other cases, the data within the
host component identifies a registered name that has nothing to do
with an Internet host. We use the name "host" for the ABNF rule
because that is its most common purpose, not its only purpose.

  host        = IP-literal / IPv4address / reg-name

The syntax rule for host is ambiguous because it does not completely
distinguish between an IPv4address and a reg-name. In order to
disambiguate the syntax, we apply the "first-match-wins" algorithm:
If host matches the rule for IPv4address, then it should be
considered an IPv4 address literal and not a reg-name. Although host
is case-insensitive, producers and normalizers should use lowercase
for registered names and hexadecimal addresses for the sake of
uniformity, while only using uppercase letters for percent-encodings.

A host identified by an Internet Protocol literal address, version 6
[RFC3513] or later, is distinguished by enclosing the IP literal
within square brackets ("[" and "]"). This is the only place where
square bracket characters are allowed in the URI syntax. In
anticipation of future, as-yet-undefined IP literal address formats,
an implementation may use an optional version flag to indicate such a
format explicitly rather than rely on heuristic determination.

  IP-literal = "[" ( IPv6address / IPvFuture  ) "]"

  IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

The version flag does not indicate the IP version; rather, it
indicates future versions of the literal format. As such,
implementations must not provide the version flag for the existing
IPv4 and IPv6 literal address forms described below. If a URI
containing an IP-literal that starts with "v" (case-insensitive),
indicating that the version flag is present, is dereferenced by an
application that does not know the meaning of that version flag, then
the application should return an appropriate error for "address
mechanism not supported".

A host identified by an IPv6 literal address is represented inside
the square brackets without a preceding version flag. The ABNF
provided here is a translation of the text definition of an IPv6
literal address provided in [RFC3513]. This syntax does not support
IPv6 scoped addressing zone identifiers.
A 128-bit IPv6 address is divided into eight 16-bit pieces. Each
piece is represented numerically in case-insensitive hexadecimal,
using one to four hexadecimal digits (leading zeroes are permitted).
The eight encoded pieces are given most-significant first, separated
by colon characters. Optionally, the least-significant two pieces
may instead be represented in IPv4 address textual format. A
sequence of one or more consecutive zero-valued 16-bit pieces within
the address may be elided, omitting all their digits and leaving
exactly two consecutive colons in their place to mark the elision.

  IPv6address =                            6( h16 ":" ) ls32
              /                       "::" 5( h16 ":" ) ls32
              / [               h16 ] "::" 4( h16 ":" ) ls32
              / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
              / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
              / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
              / [ *4( h16 ":" ) h16 ] "::"              ls32
              / [ *5( h16 ":" ) h16 ] "::"              h16
              / [ *6( h16 ":" ) h16 ] "::"

  ls32        = ( h16 ":" h16 ) / IPv4address
              ; least-significant 32 bits of address

  h16         = 1*4HEXDIG
              ; 16 bits of address represented in hexadecimal

A host identified by an IPv4 literal address is represented in
dotted-decimal notation (a sequence of four decimal numbers in the
range 0 to 255, separated by "."), as described in [RFC1123] by
reference to [RFC0952]. Note that other forms of dotted notation may
be interpreted on some platforms, as described in Section 7.4, but
only the dotted-decimal form of four octets is allowed by this
grammar.

  IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet

  dec-octet   = DIGIT                 ; 0-9
              / %x31-39 DIGIT         ; 10-99
              / "1" 2DIGIT            ; 100-199
              / "2" %x30-34 DIGIT     ; 200-249
              / "25" %x30-35          ; 250-255

A host identified by a registered name is a sequence of characters
usually intended for lookup within a locally defined host or service
name registry, though the URI's scheme-specific semantics may require
that a specific registry (or fixed name table) be used instead. The
most common name registry mechanism is the Domain Name System (DNS).
A registered name intended for lookup in the DNS uses the syntax
defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters. The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.

  reg-name    = *( unreserved / pct-encoded / sub-delims )

If the URI scheme defines a default for host, then that default
applies when the host subcomponent is undefined or when the
registered name is empty (zero length). For example, the "file" URI
scheme is defined so that no authority, an empty host, and
"localhost" all mean the end-user's machine, whereas the "http"
scheme considers a missing authority or empty host invalid.

This specification does not mandate a particular registered name
lookup technology and therefore does not restrict the syntax of reg-
name beyond what is necessary for interoperability. Instead, it
delegates the issue of registered name syntax conformance to the
operating system of each application performing URI resolution, and
that operating system decides what it will allow for the purpose of
host identification. A URI resolution implementation might use DNS,
host tables, yellow pages, NetInfo, WINS, or any other system for
lookup of registered names. However, a globally scoped naming
system, such as DNS fully qualified domain names, is necessary for
URIs intended to have global scope. URI producers should use names
that conform to the DNS syntax, even when use of DNS is not
immediately apparent, and should limit these names to no more than
255 characters in length.

The reg-name syntax allows percent-encoded octets in order to
represent non-ASCII registered names in a uniform way that is
independent of the underlying name resolution technology. Non-ASCII
characters must first be encoded according to UTF-8 [STD63], and then
each octet of the corresponding UTF-8 sequence must be percent-
encoded to be represented as URI characters. URI producing
applications must not use percent-encoding in host unless it is used
to represent a UTF-8 character sequence. When a non-ASCII registered
name represents an internationalized domain name intended for
resolution via the DNS, the name must be transformed to the IDNA
encoding [RFC3490] prior to name lookup. URI producers should
provide these registered names in the IDNA encoding, rather than a
percent-encoding, if they wish to maximize interoperability with
legacy URI resolvers.

Comment 8

[Valentin Gosu [:valentin] (he/him)]

I was able to use a socks proxy by with the following PAC URL:
data:text/plain,function FindProxyForURL(url, host) { return "SOCKS5 [::1]:9090";}

I think we can mark this as fixed.
Please comment if there are some STR where there are still issues.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

I think this was fixed by bug 1582359.