+8
Known issue

ERR_SSL_VERSION_INTERFERENCE in Chrome 63

Ryan Yoxthimer 3 years ago updated by Adam Schwartz 1 year ago 33

Getting ERR_SSL_VERSION_INTERFERENCE in Chrome 63 when accessing Control hosted on a Mono system (Linux) using HTTPS.  Please update Mono to support TLS 1.3.  Disabling TLS 1.3 in Chrome is not a viable solution long-term and looks bad to my end users.

ConnectWise Control Version:
1
Server Affected:
Host Client Affected:
Guest Client Affected:

Answer

Answer
Known issue

This issue should be resolved once users auto-upgrade to Chrome 63.0.3239.108 or above.

Good morning,


Thank you for submitting this request. Since this post is more accurately characterized as a feature request ("update mono to support TLS 1.3"), I am moving it out of the bug report forum so that the wider community of Control users can comment/upvote the request.


Cheers,

Ben

+4

It seems like there is also a bug at play rather than this just being a feature request. While an upgrade to TLS 1.3 would certainly be welcomed the application is currently broken unless browser support for 1.3 is disabled. Considering the new default under Chrome 63 is to enable this support - that basically kills access from Chrome unless the user goes into Chrome's advanced flags and disables TLS 1.3 support. Since the latest version of Chrome just started rolling out this past week it will likely affect more users as days pass.


The browser does properly negotiate a TLS 1.0 connection to the server but then once you actually login the ERR_SSL_VERSION_INTERFERENCE error comes up and the session breaks. If you research this error every other example was triggered by an errant router or proxy server that attempted to somehow intercept the SSL session.


So there is no urgent need to actually update beyond TLS 1.0, just that the application should not break if browser support for TLS 1.3 is enabled. Please review if the problem is configuration related or I can provide additional details - in my case it's running on a DigitalOcean Ubuntu 14.04.05 LTS droplet with no other applications.


Also it's probably unrelated but aside from the general weakness (older protocols, obsolete key exchange and cipher) of the current SSL implementation - it seems that the certificate chain is incorrectly sequenced. That is - it is chaining the certification authority ahead of any intermediate certificates. Browsers can generally tolerate this kind of error but this is probably something that should be corrected. In any case this may be unrelated, just something I came across when reviewing this issue. It might just be a fault in the Configurator that generates the tarball or something inherent in the app itself.


Thanks

You've stated the issue much better than I did.  I initially submitted this as a bug but it got moved.

Thank you for your comments on this issue. Based on the feedback and additional review, we've registered a bug report for this issue and development is currently investigating.


I will update this thread as new information becomes available.


Cheers,

Ben

Ben, do you have any updates on how or when this issue will be resolved?  Thank you.

Is anyone still having this issue on the current stable version of Chrome?

Seems that Google shut down the TLS 1.3 trial in advance of the holidays and will be re-enabled in a future release so it's no longer a pressing issue although there's certainly the concern that it will return with a future browser release.

https://www.chromium.org/Home/tls13

Answer
Known issue

This issue should be resolved once users auto-upgrade to Chrome 63.0.3239.108 or above.

We were also working in chrome 64, now we're broken again in chrome 65.


We are running Control 6.5.16479.6613 on ubuntu 16.04.

+3

Looks like Google has officially released TLS 1.3 in Chrome 65 and the issue has returned. Server access is broken unless TLS 1.3 is disabled in the advanced browser flags.

For the intermediate cert issue with Mono, I had to use an nginx reverse proxy. Firefox would not fill in an intermediate cert which Mono was not sending out. Unfortunately, that may be the only solution for Chrome and TLS 1.3.


http://forum.screenconnect.com/yaf_postsm7645_Relay-80--SSL-Authentication443-Web-Server-WITH-Auto-URL-redirect-from-HTTP.aspx

I too am experiencing this issue again. Looking at other reports it seems like it affects even the more recent builds of connect wise control and not just the older ScreenConnect. The problem definitely appears to be Mono.


https://control.product.connectwise.com/communities/6/topics/1691-tls-13-seems-to-breaks-screenconnect-when-using-ssl-on-mono

I am experiencing this as well.  I just updated to the 6.6.17081.6648 version of screenconnect (On Debian 8.10)  and the problem is still there.  I get "ERR_SSL_VERSION_INTERFERENCE" error in Chrome 65.0.3325.181.  It worked fine in Chrome 64.  Firefox and Internet Explorer also work fine.  Is the a configuration setting I can change in the /opt/screenconnect/App_Runtime/etc/ directory to make this work properly in Chrome?

I am experiencing this as well.   Chrome 66  and Firefox 59

Version 6.6.17081.6648 on Ubuntu Server 16.04.4


Opera, Brave, Internet Explorer and Edge works fine


We have the same issue with latest builds of Chrome and Firefox on 2 x ScreenConnect installations. Is there a fix other than implementing a reverse proxy?

If running your Control server on Linux, the best thing to do currently is to use something like nginx as a TLS termination proxy.

We are running both on Linux and can implement HaProxy or Nginx without any trouble - the point is that we shouldn't have to. 

Either running the server on linux is not supported or ConnectWise needs to give us a supported fix with documentation.

Our team is pretty tired of the hard work involved in getting our some of our more novice users to open a different browser.

We're having this problem too. I'm using Firefox 59.0.2 to access our self-hosted ScreenConnect server running version 6.6.17808.6681 on Linux.

I am experiencing the same issue. Sounds like screen connect need to resolve this issue. Its commercially naive to think that your application requires specific browsers or longwinded workarrounds to work correctly is going to be acceptable. All anyone wants when they buy software is a solution. Right now its seems easier to look for an alternative to connectwise than to be messing about with installing workarounds or having to explain to clients how to work arround the issue. 

PLEASE take this as constructive criticism and get an update in place ..like today!

+2

I know it's not ideal, but in case anyone wants a quick config for nginx, here's one to work around this issue.  Thought it might save someone a few minutes of fiddling.  My screenconnect web server is listening on 444 (non-ssl), but keep the addressable URI as https (443).  I feel like the application is more responsive this way and may keep it even if they fix mono.


NGINX:

    upstream backends{
        server screenconnect.mydomain.com:444;
    }     server {
        listen       A.B.C.D:443 ssl; #IP of my linux server
        server_name  screenconnect.mydomain.com;
        ssl_certificate   /path/to/cert.cer;
        ssl_certificate_key   /path/to/private/key.key;         location / {
          proxy_pass http://backends;
          proxy_set_header Host $http_host; # so ScreenCOnnect passes the Browser URL self test
          proxy_pass_header Server; # so ScreenConnect passes the External Accessibility self test
        }     }

ScreenConnect Web.config

<add key="WebServerListenUri" value="http://A.B.C.D:444/">
    </add>
<add key="WebServerAddressableUri" value="https://screenconnect.mydomain.com">
    </add>

IPTABLES (My machine is a virtual container in the cloud, so I have to implement my own firewall to block the SC listening port 444 from everyone but the local machine)

ACCEPT     tcp  --  127.0.0.1            0.0.0.0/0            tcp dpt:444
ACCEPT     tcp  --  A.B.C.D        0.0.0.0/0            tcp dpt:444
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:444


I implemented slightly different, was able to go from ssl labs rating of F to A, and web page is loading on Chrome and Firefox.


i used 444 for my relay


so i made screenconnect listen on 8080


and made the upstream adjustment on nginx, running the latest 6.9.21415.6941


my issue is that it logs in, but outside of the admin console, none of my sessions show, i only get the loading twirls.

any ideas?

Still an issue in version 6.6 and Chrome 66, current versions May 16, 2018.

+1

This has gotten worse as latest Chrome and Firefox are refusing to load any pages with "ERR_SSL_VERSION_INTERFERENCE"

This issue is NOT fixed as per the included answer, latest Chrome and Firefox breaks ScreenConnect / Control for self-hosted Linux installations.  Time to find another solution as this once great product has reached end of life.

+1

Issue is still present. Frustrating that we need to implement a reverse proxy to get the server working on Linux and that the installation guides for Linux haven't been updated to reflect this significant change - meaning we are left to browse community forums for a solution.


Part of me wonders if failing to provide a fix for this issue is just another gentle push towards the cloud offering.



+1

I'm not sure if it's just me, but it appears that voting for this bug has been disabled.  I guess they don't want to hear how many people have this problem.

Any alternatives ?

+1

This is still a major issue for us. Any progress?

We ended up building a Window 7 box and transferring the clients over, the hardest part was watching 10 years of Windows updates install.  This is not an acceptable solution but a necessity to keep us running.  Shame on ConnectWise for obviously abandoning the original on-premises ScreenConnect in an effort to move customers to their overpriced hosted solution.

I just ordered a Dell NUC for this. Question: Why Windows 7? I'm thinking about Windows 10 or Windows Server 2016.

We had an unused tower with a Windows 7 sticker so it just made sense.  SC seems to be running very well on this old box, 60+ clients connected with 4GB of RAM and no issues so far.

+1 Fixed the issue and it's much faster!

Sorry to see the Connectwise never resolved this.  Finally had to migrate to a Windows server and have no complaints now.

We moved to a Windows server too, it's really fast and convenient. 

My suggestion here is that ConnectWise should either resolve the linux/mono issue, or discontinue the linux server option. It's silly to have a "supported" but broken option. It caused us a bunch of hassle. Once it became clear that Windows was the only truly supported option, we switched, and we're happy again.