Firefox Problems after upgrading to v12.4

Immediately after upgrading our FB to v12.4.B589964, our users started complaining about being unable to access sites from Firefox. The issue is:

Secure Connection Failed
Error code: SSL_ERROR_NO_CYPHER_OVERLAP

Sample sites would be:
https://community.acog.org
https://annualmeeting.acog.org

I am able to bypass the error and view the site if I change the following setting under ABOUT:CONFIG

Default
security.tls.version.fallback-limit;4

Workaround
security.tls.version.fallback-limit;0

What has changed in the FB to make this happen?
Is there a change in the FB I can make to access these sites?

When I run the same version of Firefox at home with the Default (security.tls.version.fallback-limit;4) those sites are accessible without a problem, so it appears it is something with the new firmware.

Any ideas?

«1

Comments

  • I am running V12.4 and Firefox, and I have no issue accessing those sites.
    My Firefox has security.tls.version.fallback-limit;4

    What do you have set in your HTTPS proxy for the TLS Profile ?
    Mine is: PFS Ciphers = allowed, Minimum TLS = 1.0 TLS Compliance = Enforced

    Consider opening a support incident on this.

  • Looks like the PFS Ciphers=Allow was the trick.

    As always Bruce, thanks for the quick reply.

  • Bruce, another oddball for you.

    Can you access https://trust.cdc.gov from Chrome, IE, or Edge.

    In Chome, IE, and Edge, I get security issues.

    In Firefox, the communication works fine (you will get a server side exception) but the site does respond.

    Testing in Chome, IE, and Edge outside of the FB works fine.

  • I get the same error in Firefox, IE & Chrome. I don't use Edge.

    Secure Proxy Server - Error Report
    Error Details
    Request URI : /
    Error Type : SPS Exception
    Error Code : Noodle_ConnectException
    Message : Connection refused remotely, no process is listening on the remote address/port.

  • Actually, that is what you should see -- I didn't include all the extra parameters. So you are able to communicate with that server. I only get that in Firefox, other browsers give me a error:

    This site can’t provide a secure connection trust.cdc.gov sent an invalid response.
    Try running Windows Network Diagnostics.
    ERR_SSL_PROTOCOL_ERROR

    Any ideas of what I should look at? I've tried all the different TLS Profile options.

    These browser specific issues are not fun.

  • "Connection refused remotely, no process is listening on the remote address/port."
    suggests to me that there is an issue at the CDC site with HTTPS to this domain.
    I get the same error even if I add an Allow entry in my HTTPS proxy.
    And I can't get to it from my phone either.
    Site is down IMHO

  • FWIW, staff said they were able to access before the upgrade. I see this in my logs if it helps:

    2019-04-10 13:21:50 Member1 pxy 0x429d450-1444029 connect failed Connection refused 4843: 10.0.1.175:29591 -> 198.246.102.45:80 [A] {B} | 5282: 209.116.152.2:29591 -> 198.246.102.45:80 [!B c] {B}[P] Debug

  • RyanTaitRyanTait WatchGuard Representative

    Good morning

    In Fireware 12.4 we introduced TLS 1.3 support. Some websites that advertise TLS1.3 are not being handled by the proxy properly. The problem is being tracked as FBX-16143/FBX-16203. When a fix is available to the public it will be listed in the release notes with one of these bug numbers.

    The PFS thing is a red herring (but still a neat way of validating what is happening). By denying PFS ciphers it alters the SSL server response to something the proxy can handle. Overall you want to Allow the use of PFS ciphers. more things will just break by denying them.

    The support team is currently validating SSL key exchange problems to see if they will be fixed with FBX-16143/FBX-16203. If you have experienced this problem, open up a support case and include the websites in question.

    If you want to validate this on your own, look for logs like these

    "Connect SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/sslv3 alert handshake failure] Domain: www.example.com PFS: ALLOWED | ALLOWED Debug "

    Ryan Tait | Support Representative
    WatchGuard Technologies, Inc. | www.watchguard.com

  • Ryan, I'm not seeing that particular error in my logs.

    The problem is accessing the https://trust.cdc.gov website (the actual URL is very long, but is not required to for the test).

    If I access via Firefox, it communicates with the server and lets me know I didn't pass the URL variables with this message:

    Secure Proxy Server - Error Report
    Error Details
    Request URI
    : /
    Error Type
    : SPS Exception
    Error Code
    : Noodle_ConnectException
    Message
    : Connection refused remotely, no process is listening on the remote address/port.

    If I access via Chrome, it can not communicate with the server and gives me this error:

    This site can’t provide a secure connection trust.cdc.gov sent an invalid response.
    Try running Windows Network Diagnostics.
    ERR_SSL_PROTOCOL_ERROR

    When I evaluate the proxy debug logs, Chrome shows a lot of nondata events, including CHAN_READ_BLOCKED, that Firefox does not show. I suspect this is the important error. Does that tie into FBX-16143/FBX-16203?

    I don't see a way to attach a file to this post. How can I include the debug logs in the forum?

  • Snippet of Chrome (Not Working) Logs:
    2019-04-10 17:03:07 Member1 https-proxy 0x2ef83e0-2349245 https_domain_name_check matching rule against ip: 198.246.102.45 Debug
    2019-04-10 17:03:07 Member1 https-proxy 0x376d520-1779045 58119456:1779045: nondata event 'CHAN_READ_BLOCKED: 887: 10.0.1.175:18582 -> 198.246.102.45:443 [A txr] {N }' Debug
    2019-04-10 17:03:07 Member1 https-proxy 0x376d520-1779045 58119456:1779045: nondata event 'CHAN_READ_BLOCKED: 907: 209.116.152.2:18582 -> 198.246.102.45:443 [B txrs] {N }' Debug
    2019-04-10 17:03:07 Member1 https-proxy 0x376d520-1779045 58119456:1779045: nondata event 'CLOSE: 887: 10.0.1.175:18582 -> 198.246.102.45:443 [A tr] {N}' Debug
    2019-04-10 17:03:07 Member1 https-proxy 0x376d520-1779045 58119456:1779045: nondata event 'CLOSE: 907: 209.116.152.2:18582 -> 198.246.102.45:443 [B trs] {N}' Debug
    2019-04-10 17:03:07 Member1 https-proxy 0x376d520-1779045 58119456:1779045: nondata event 'DATA_INTERNAL(185): 887: 10.0.1.175:18582 -> 198.246.102.45:443 [A t] {X}' Debug
    2019-04-10 17:03:07 Member1 https-proxy 0x376d520-1779045 58119456:1779045: nondata event 'SSL_PROTO_CLIENT_HELLO_COMPLETE: 887: 10.0.1.175:18582 -> 198.246.102.45:443 [A t] {B}' Debug
    2019-04-10 17:03:07 Member1 https-proxy 0x376d520-1779045 58119456:1779045: nondata event 'SSL_PROTO_SERVER_PARSING_COMPLETE: 907: 209.116.152.2:18582 -> 198.246.102.45:443 [B t] {B}' Debug
    2019-04-10 17:03:07 Member1 https-proxy 0x376d520-1779045 887: 10.0.1.175:18582 -> 198.246.102.45:443 [A t] {N}: got 7 bytes of data Debug

  • Also, as the FBX-16143 & FBX-16203 are not in the Known Issues, we can't even look up what they are supposed to address.

  • RyanTaitRyanTait WatchGuard Representative

    trust.cdc.gov is something different, It looks like it requires a client certificate. I get that same message here when I try to access the site with just a packet filter.

    Open a case with the support team and we can work with you to see what is happening

    Ryan Tait | Support Representative
    WatchGuard Technologies, Inc. | www.watchguard.com

  • Will do.
    BTW, when accessing from home, on any browser, I can communicate with the server.

  • Heard back from Support:

    It was reported that you are unable to go to certain Https sites from Google Chrome.

    This is currently a known issue that our Engineering team is working on. (FBX-16203)

    For proper case tracking and notifications, I will set the status of this case to 'Bug/Enhancement Submitted'. This allows you to receive an update when either the Bug has been resolved or the feature enhancement becomes available.

    The case will not be closed until a resolution has been provided and it will not be necessary to update the case unless there are additional questions regarding the problem.

    As we discussed, here is a workaround while we are in the process of resolving the BUG/Enhancement Request:

    1. Create an outbound HTTPS proxy with the default HTTPS-Client.Standard action. The TLS profile will have Perfect Forward Secrecy Ciphers set to Allowed.
    2. Open the Chrome or Firefox web browsers and attempt to open https://www.fedex.com.
    3. Modify the proxy action and TLS profile of the proxy. Set PFS Ciphers to None.
    4. Attempt to open the website again.

    Please Be aware Internet Explorer and Edge are able to load the page properly with PFS set to Allowed.

    With PFS set to None, Chrome and Firefox will load the fedex.com page. However, other webpages that use PFS may fail to load with it disabled in the proxy.

  • This was happening to us also with a different website. Our workaround was to disable our HTTPS Proxy rule and add a HTTPS Packet rule until the issue is resolved. Be aware, this will disable WebBlocker if you use it.

  • For this problem:
    2019-04-19 10:37:50 pxy 0x10651ad0-1474 79: 10.10.11.5:4648 -> 2.228.120.10:443 [B t] {N}: Connect SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/sslv3 alert handshake failure] Domain: f.cimdept.it PFS: ALLOWED | ALLOWED Debug

    The solution I tried and works is to set pfs to None instead of Allowed in the TLS profile

  • That was a proposed work-around suggested to me when I opened the bug report (see below). However, that does not work for the site I was trying to access (at lest on the test build I'm running): https://trust.cdc.gov

    On you system, if you use Chrome and try to access https://trust.cdc.gov do you get a communications error, or "Error Type: SPS Exception" which indicates you are able to communicate, just don't have all the URL parameters necessary to access the resource?

    ==== Except from Bug Ticket ====
    As we discussed, here is a workaround while we are in the process of resolving the BUG/Enhancement Request:

    1. Create an outbound HTTPS proxy with the default HTTPS-Client.Standard action. The TLS profile will have Perfect Forward Secrecy Ciphers set to Allowed.
    2. Open the Chrome or Firefox web browsers and attempt to open https://www.fedex.com.
    3. Modify the proxy action and TLS profile of the proxy. Set PFS Ciphers to None.
    4. Attempt to open the website again.

    Please Be aware Internet Explorer and Edge are able to load the page properly with PFS set to Allowed.

    With PFS set to None, Chrome and Firefox will load the fedex.com page. However, other webpages that use PFS may fail to load with it disabled in the proxy.

  • I also got this issue after upgraded FB to V12.4 and the debugging show as below

    2019-04-23 16:44:28 pxy 0x249a430-809811 1034: xx.xx.xx.xx:60429 -> xx.xx.xx.xx:443 [B t] {N}: Connect SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/sslv3 alert handshake failure] Domain: xxx.xxx.com PFS: ALLOWED | ALLOWED

    If cannot get any solutions better to restore the last know good backup
    Any suggest?

  • There is a new CSP for V12.4 out yesterday - but no description of what it fixes.
    Either open a support incident to see if there is a fix for this issue now or downgrade until there is a confirmed fix for it.

  • The new CSP v12.4.B592447 resolves the https://trust.cdc.gov issue for me in all browsers!

  • The issue was solved but new issue just come see as below debugging

    2019-04-24 13:29:53 pxy 0x10bf8c0-53553 1496: 58.137.19.66:58764 -> xx.xx.xx.xx:443 [B t] {N}: Accept SSL Error [ret 0 | SSL err 0 | Peer closed the channel] Domain: xxx.xxx.com PFS: ALLOWED | ALLOWED Debug

    Can you please help me on this?

  • What's the domain?

  • Whats a CSP?

  • Customer Specific Patch.
    The CSP release notes are now showing a number of fixes to HTTPS issues in base V12.4.
    If users are having issues with HTTPS, then they should open a support incident to get the CSP from support.

  • Recommend holding off upgrading to 12.4 then? Or just automatically request the CSP?

  • If there is nothing that you need in V12.4, consider waiting until V12.4.1.
    Otherwise get the CSP

  • I'm having the same issue in Firefox and Chrome on 12.4 with https:\www.fedex.com.

    The site works with these settings:
    Min Protocol Version TLSv1.1
    PFS None

    but not with these settings:

    Min Protocol Version TLSv1.1
    PFS Allow
    or
    Min Protocol Version TLSv1.0
    PFS None

  • CSP1 fixes these

  • edited April 25

    @Bruce_Briggs said:
    CSP1 fixes these

    Saw that but since Edge seemed to work fine, it wasn't causing any problems for users here. We'll probably wait for 12.4.1.

  • edited May 25

    Message content deleted by Gregg Hill.

    Gregg Hill

Sign In to comment.