Options

Chrome 92 and WG HTTPS Proxy

ZiXZiX
edited July 2021 in Technical Discussion

We use SNI for publishing few web applications using one IP address and we use the SNI for this. It worked fine before our customers starts to updating their Chrome to version 92. After that SNI began to behave unusual: few sites still works but few stop working. We use the Watchguard XTM device which route traffic between server based on SNI. From another browsers (Opera, Yandex Browser, Mozilla) it still works fine:

2021-07-21 22:15:11 XTM515-TOP Allow -- https/tcp 5707 443 13-Proxima 10-DMZ ProxyAllow: HTTPS domain name match (HTTPS-proxy.Servers-00) proc_id="https-proxy" rc="590" msg_id="2CFF-0003" proxy_act="HTTPS-Server.Servers" rule_name="WebPlan3D Angstrem" sni="--"
2021-07-21 22:15:16 XTM515-TOP Allow -- https/tcp 5707 443 13-Proxima 10-DMZ HTTPS Request (HTTPS-proxy.Servers-00) proc_id="https-proxy" rc="548" msg_id="2CFF-0000" app_id="0" app_cat_id="0" proxy_act="HTTPS-Server.Servers" action="allow" src_ctid="ad64c258" dst_ctid="a28853b0" out_port="5707" srv_ip="--" srv_port="443" sent_bytes="13837" rcvd_bytes="13837" tls_version="TLS_V12" tls_profile="TLS-Server-HTTPS.Servers" sni="--"

This means that SNI -- was successfully processed and traffic was routed to the load server --. Also we can see that TLS1.2 is in use.

Now I try to load same site into Chrome 92:

2021-07-21 22:17:46 XTM515-TOP Deny -- https/tcp 7577 443 15-Rostelekom 10-DMZ ProxyDrop: HTTPS invalid protocol (HTTPS-proxy.Servers-00) proc_id="https-proxy" rc="594" msg_id="2CFF-0007" proxy_act="HTTPS-Server.Servers" length="0"
2021-07-21 22:17:46 XTM515-TOP Deny -- https/tcp 7577 443 15-Rostelekom 10-DMZ HTTPS Request (HTTPS-proxy.Servers-00) proc_id="https-proxy" rc="548" msg_id="2CFF-0000" app_id="0" app_cat_id="0" proxy_act="HTTPS-Server.Servers" action="drop" src_ctid="ab3bf8b8" dst_ctid="ab3bf8b8" out_port="7577" srv_ip="--" srv_port="443" sent_bytes="7" rcvd_bytes="1460" tls_version="SSL_0" tls_profile="TLS-Server-HTTPS.Servers"

Now my XTM device said that ProxyDrop: HTTPS invalid protocol. So it can't found the SNI in Hello message. Browser shows that chipher mismatch and than connection closed.

It's interesting that another web sites like -- and others behind this XTM and behind same rule works fine.
Also i've tried to create another rule: -- which routes to the same server. It works fine.
Then I've tried to just remove the rule for manager.angstrem-mebel.ru and XTM anyway shows that HTTPS invalid protocol. So rule even not starts to implement. But if I create new domain for ex. manager1.angstrem-mebel.ru which points to the same server it will works fine.

So only old DNS name works incorrect in latest Chrome 92. It works fine in previous version and all other browsers. I've read and then re-read all what's new from version 92 and can't found anything referred to my problem. So now I'm stuck. May be anyone can help me.

Comments

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @ZiX
    Our spam filter kept catching you because of all the IPs and domain names in your logs. In the future, if you post logs, please sanitize them so they're not personally identifiable. (I've edited your IPs and host names out of the logs as best I can.)

    It looks like you might be running one of our older devices. What firmware are you running? If it's something older, chrome might be encoding the SNI in a way the firewall can't interpret. The first step would be to jump into the latest firmware and see if the issue persists there.

    it's likely something related to TLS (possibly 1.3)
    https://techsearch.watchguard.com/KB?type=Known Issues&SFDCID=kA10H000000g3ckSAA&lang=en_US

    -James Carson
    WatchGuard Customer Support

  • Options

    I believe we are in the same boat as you however it is not SNI it is our user traffic. We started having issues connecting to certain websites (amazon / apple ) and getting HTTPS invalid protocol errors in our Watchguard logs. The Proxy is dropping the packets so the websites can not be reached.

    This only happens on Google Chrome or MS Edge (Chrome based). Safari, Firefox, and old IE do not have the issue. On chrome the error comes up as ERR_CONNECTION_RESET and ERR_SSL_VERSION_OR_CIPHER_MISMATCH. It started happening on 7/27/2021 (or that's when we noticed it).

    We are doing SSL inspection. If we turn off "Allow only TLS-compliant traffic" for the TLS profile of the configuration then the issue goes away so it seems something is wrong with TLS.

    We have a old XTM box so we are stuck on the 12.1 Fireware OS track.

    We opened a ticket with Watchguard on 7/27/2021 and they have been unresponsive for over a week so we are looking for help in the community. We are not happy since we pay a lot yearly for support and this is becoming an increasingly bigger issue as more and more website are being affected.

  • Options

    Could this be a DNS over HTTPS issue?
    I Deny dns.google in my HTTPS proxy action

  • Options

    ironically.... We are now actively working with support now on this issue. Seems it is a TLS issue

  • Options

    @FSD could you find a final solution with the support?
    I have the same issue by one of our costumers.

Sign In to comment.