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
all 3 IPs aren't working for me, confirmed by traceroute. "target host not reachable" (translated)
Component: Untriaged → Security: PSM
Product: Firefox → Core
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).
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
(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
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.
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://
OS: Windows 7 → All
I confirm the patch in bug 633001 fixes this bug, too.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
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)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → INVALID
Right - it's fixed in 24 and up.
Resolution: INVALID → DUPLICATE
You need to log in before you can comment on or make changes to this bug.