Teamviewer. Is the exception "Teamviewer Remote Access Work around Teamviewer SSL handshake Bug" still required ?

Is the exception "Teamviewer Remote Access Work around Teamviewer SSL handshake Bug"  still required ?

But more importantly, is the Teamviewer SSL handshake bug still there ?

The exception used to be this:

 

^([A-Za-z0-9.-]*\.)?tvcdn\.de/?

^([A-Za-z0-9.-]*\.)?teamviewer\.com/?

 

But in v18, the exception cannot be edited and is missing ^([A-Za-z0-9.-]*\.)?tvcdn\.de/?

Paul Jr

Parents
  • Hi Paul,

    The out of box exception for Teamviewer was added in XG 17.1 and always was only teamviewer.com.  The UTM has a similar exception.

     
    From what I can tell, there are several posts on the internet about people annoyed teamviewer started using tvcdn and that they need to punch more holes through their proxy.  But not one of them mentions Sophos or XG, and there are no Sophos community threads on it.  So I do not think that there ever was a SSL handshake bug on the XG for tvcdn.de.
     
     
    I suspect that you might have added the tvcdn.de yourself.
     
     
    From v18 forward, we want Sophos to manage the out-of-box exceptions and not have them modified by customers.  That allow us to add/remove things without changing anything a customer configured, and similarly protects us from a customer removing something from an exception.
     
     
    The way the upgrade should have worked is if you had modified the Teamviewer exception before upgrade, during upgrade it should have made a copy of your modified version with a variant on the name, and then recreated the out-of-box exception to the Sophos standard one.
     
    Are you sure that there was a tvdn.de before the upgrade?  In v18 have you made sure you don't have two exceptions for Teamviewer (your modified and our readonly)?
     
Reply
  • Hi Paul,

    The out of box exception for Teamviewer was added in XG 17.1 and always was only teamviewer.com.  The UTM has a similar exception.

     
    From what I can tell, there are several posts on the internet about people annoyed teamviewer started using tvcdn and that they need to punch more holes through their proxy.  But not one of them mentions Sophos or XG, and there are no Sophos community threads on it.  So I do not think that there ever was a SSL handshake bug on the XG for tvcdn.de.
     
     
    I suspect that you might have added the tvcdn.de yourself.
     
     
    From v18 forward, we want Sophos to manage the out-of-box exceptions and not have them modified by customers.  That allow us to add/remove things without changing anything a customer configured, and similarly protects us from a customer removing something from an exception.
     
     
    The way the upgrade should have worked is if you had modified the Teamviewer exception before upgrade, during upgrade it should have made a copy of your modified version with a variant on the name, and then recreated the out-of-box exception to the Sophos standard one.
     
    Are you sure that there was a tvdn.de before the upgrade?  In v18 have you made sure you don't have two exceptions for Teamviewer (your modified and our readonly)?
     
Children
  • Another interesting point: Teamviewer has an own Port, which TV tries first: TCP-/UDP-Port 5938

    If this port fails, it will fallback to 443. 

    So if you are concern, you could put 5938 with a non scan SSLx Rule and let the traffic happen. 

    __________________________________________________________________________________________________________________

  • I wish I could have upgraded from v17.5 to v18, but it failed.  So yes tvcdn.de was added by myself.  Because up to very recently, it would simply not work otherwise.

    So where's the exception list for Google Chrome Update ?  I mean, one that works because none on this forum really works.

    Paul Jr

  • This discussion is no longer related to v18.0, this applies to all versions and even the SG UTM.

     

    No complaints about needing tvcdn.de have reached the dev team.  I don't know if it is needed or not, but we haven't heard.  Maybe customers or support knows different.

     

    Chrome updates happen using Microsoft BITS.  BITS works by doing a "background download" and trying to download the update a little bit of the time using range requests.  The idea is that if your computer is idle, BITS will download 1MB of the update.  Then a minute later download another 1MB of the update, and so on.

    The problem is that the XG cannot virus scan files that are downloaded piece by piece with range requests.  In order to implement best protection, the range requests are blocked.

    This isn't a bug, it is by design.

    Chrome uses gvt1.com to do updates, but the I think chrome uses the domain for other things as well.  If you trust Google/Chrome you can create an exception that applies to gvt1.com (or better yet RegExs the exact paths) and skips the malware scanning.  I personally think that the XG should ship with an OOB exception for this and other BITS download urls, but default disabled, but I'm not the one making the decisions. :)

  • Ok.  But meanwhile, ^([A-Za-z0-9.-]*\.)?teamviewer\.com/? is a blank check to Teamviewer.  That I not really trust, taking into account their terrible security past.

    And that Regix is the generic Teamviewer website.

    "tvcdn.de" was the address used up to recently for updates.  At least here.

    Paul Jr

  • I agree it is a balancing act.  Trying to make things secure but also to make things compatible.  Sometimes an administrator needs to make a choice.