828873 - URL with https and IPv6 does not work

Status: RESOLVED DUPLICATE of bug 633001

(Core :: Security: PSM, defect)

Description

[Markus Hennig]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

https://[2001:4dd1:feb4::1] does not work,
https://[2001:4dd1:fec4::1]:4444 does not work, but
http://[2001:4dd1:fed4::1] works...

It looks like nothing happens with if https on a IPv6 IP


Actual results:

It looks like nothing happens with if https on a IPv6 IP


Expected results:

https://[2001:4dd1:fec4::1]:4444 works on IE9 and Chrome23
Win7 64bit

Comment 2

[Matthias Versen [:Matti]]

all 3 IPs aren't working for me, confirmed by traceroute.
"target host not reachable" (translated)

Comment 3

[Christian Krause]

I can confirm the reported issue. 

1. Plain IPv6 https URLs don't work anymore in recent firefox releases:

2. Plain IPv6 http URLs (or URLs with DNS names which resolve to IPv6 addresses) work.


exact behavior:
- start with any web page loaded, URL input field shows the URL of that page
- delete previous URL, enter a plain IPv6 https URL (host should be reachable)
- press <ENTER>
- displayed web page does not change
- URL field will revert back to previous URL


test environment:
- linux, Fedora 17
- i686 as well as x86_64


I have bisected the problem:

- 2012-08-25 nightly: works
http://hg.mozilla.org/mozilla-central/rev/f077de66e52d
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/08/2012-08-25-03-05-41-mozilla-central/

- 2012-08-26 nightly: does not work
http://hg.mozilla.org/mozilla-central/rev/b3cce81fef1a
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/08/2012-08-26-03-05-26-mozilla-central/

The diff between both hg revs is quite quite large, but the changes for

https://bugzilla.mozilla.org/show_bug.cgi?id=760307 (implement support for preloaded strict-transport-security (HSTS) sites)

are touching e.g. security/manager/boot/src/nsStrictTransportSecurityService.cpp .


Additionally I'm not sure that this bug really depends on 653953 (which seems to be about DNS resolver issues).

Comment 4

[Christian Krause]

The latest patch (https://bugzilla.mozilla.org/attachment.cgi?id=710900) for issue https://bugzilla.mozilla.org/show_bug.cgi?id=633001 (SSL cannot set exceptions on IPv6 addresses) solves the issue, that plain IPv6 didn't work at all, too.

Comment 5

[Markus Hennig]

Does this also fix the problem with no-standard ports in an IPv6-URL?
E.g. this kind of (correct) URLs: 
  https://[2001:face:feed::1]:4444

Comment 6

[Christian Krause]

(In reply to Markus Hennig from comment #5)
> Does this also fix the problem with no-standard ports in an IPv6-URL?
> E.g. this kind of (correct) URLs: 
>   https://[2001:face:feed::1]:4444

Yes, it does.

I've tested this locally with something like:
https://[fdd1::3b]:4433/

- access to that URL is possible
- correct port is used
- certificate exception creates a separate entry in the certificate manager
- exception is correctly remembered even after re-starting firefox

Comment 7

[Gerrit Hohl]

I'm using Firefox v22.0 and facing also that problem.

I'm accessing a Jetty web server (http://www.eclipse.org/jetty/) which I'm using in one of my projects. For HTTPS I'm using a self-signed certificate which shouldn't be a problem - at least it is not with IPv4: You get that warning and accept the certificate.
HTTP over IPv6 works also perfectly. But the moment I'm trying to use HTTPS nothing seems to happen. Firefox does something for less than a second. Afterwards: Silence. It displays the old page and nothing happens. It even shows the old URL in the address field.

I tried to analyse the IPv6 HTTPS communication using Wireshark:
- Firefox opens the connection.
- Firefox starts the handshake by sending "Client Hello".
- Jetty answers with "Server Hello", "Certificate", "Server Key Exchange" and "Server Hello Done"
- Firefox responds with "Client Key Exchange", "Change Cipher Spec" and "Encrypted Handshake Message"
- Shortly after that Firefox sends an "Encrypted Alert" and closes the connection.

I also tried to analyse the IPv4 HTTPS communication:
- Firefox opens the connection.
- Firefox starts the handshake by sending "Client Hello".
- Jetty answers with "Server Hello", "Certificate", "Server Key Exchange" and "Server Hello Done"
- Firefox responds with "Client Key Exchange", "Change Cipher Spec" and "Encrypted Handshake Message"
- Jetty sends a "Change Cipher Spec".
- In a separate packet Jetty send an §Encrypted Handshake Message".
- Shortly after that Firefox sends an "Encrypted Alert" and closes the connection.
- But it shows a warning page to the user. And if the user accepts the certificate he/she can view the requested web page.

I also tried it with Internet Explorer 9.0.8112.16421, Google Chrome 28.0.1500.72 m, Opera 15.0.1147.141 and Apple Safari 5.1.7 (7534.57.2) (all running on Windows 7). There it is working perfectly. Eh, okay, in Safari "nearly" perfectly: The dialogue which pops up because of the invalid certificate offers the button "Continue". But if I press it I get the same dialogue again. And again. And again.

Comment 8

[Kai Engert (:KaiE:)]

I get this problem on Fedora Linux 19, with both an RPM-packaged Firefox 23, and with FF versions downloaded directly from Mozilla, tried FF 17.0.8 and FF 22.

Using Firefox 10 works.

It seems impossible to visit a site by ipv6 address with https://

Comment 9

[Kai Engert (:KaiE:)]

I confirm the patch in bug 633001 fixes this bug, too.

Comment 11

[Markus Hennig]

as this bug was closed as a dupe of #633001 I'm not sure if it is still related, because the problem still appears on my FF 23.01 (Win7):

HTTPS with self-signed certificate to an IPv6 site does not work, no certificate alert is shown (or anything else...

Wireshark tells me: (14 packets)
 TLSv1 Record Layer: Handshake Protocol: Client Hello
 TLSv1 Record Layer: Handshake Protocol: Server Hello
 TLSv1 Record Layer: Handshake Protocol: Certificate
   TLSv1 Record Layer: Handshake Protocol: Server Key Exchange
   TLSv1 Record Layer: Handshake Protocol: Server Hello Done
 TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
 TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
 TLSv1 Record Layer: Encrypted Alert
 TLSv1 Record Layer: Handshake Protocol: New Session Ticket
 RST, ACK sent
 FIN, ACL received


Any ideas?


(IE & Chrome still works)

Comment 12

[Markus Hennig]

RTFM...

Tracking Flags: 	
tracking-firefox23: 	-
status-firefox23: 	wontfix
tracking-firefox24: 	+
status-firefox24: 	verified
status-firefox25: 	verified
status-firefox26: 	verified
tracking-firefox-esr17: 	-
status-firefox-esr17: 	wontfix

Comment 13

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Right - it's fixed in 24 and up.