TLS 1.3 It has been in the work for four years. Knowing that TLS 1.2 have been implemented only recently on selected products (for those who figured how), when can we expect it will be implemented on XG and other products ?

TLS 1.3  It has been in the work for four years.  Final approval happened last week.

Knowing that TLS 1.2 have been implemented only recently on selected products (for those who figured how), when can we expect it will be implemented on XG and other products ? In 2028 ?

Paul Jr

  • This is an interessting question :-) Maybe someone of Sophos Staff can give some informations about this.

  • In reply to HuberChristian:

    It is even more interesting considering many large WEB sites and Google Chrome plan to forbid TLS 1.0 and 1.1 very soon (weeks).

    Some of those large WEB sites plan to forbid TLS 1.2 anytime next year ...

    So ...

    Paul Jr

  • Hi Paul,

    Regarding the XG:

    Currently, the XG already handles TLS 1.3 traffic with the web proxy. It does a downgrade to TLS 1.2 so as to not break traffic, which is an approach that other vendors have also taken, up until this point in time. 

    Native support for TLS 1.3 inspection is tentatively planned to be introduced in SFOS v18. However this could be subject to change at anytime.

    Regards,

  • In reply to FloSupport:

    Thanks for the answer, FLO.

    Let assume a TLS connection where the server is up to TLS 1.3 and the client is at TLS 1.1.  If allowed, the server will downgraded to TLS 1.1, right  ?

    To my understanding, TLS have always downgraded to earlier version when a client is not at the latest TLS.  This is in TLS specifications.  Unless admins locked out older TLS/SSL.  If I am not wrong, a very serious security was that TLS 1.0 would downgrade to very unsecured SSL 3.0.  TLS 1.1 appeared mostly because of that.

    Google tried TLS 1.3 early last year but had to delay a year because too many problems occurred.  Downgrading to older TLS or not.

    Technically, a supplier is not TLS if the downgrade mechanism is not implemented.

    Question is now, if a user's desktop has TLS 1.2 implemented, if a server has TLS 1.3 ONLY rule, what will happen to XG - in between - trying to scan that traffic ?

    Paul Jr

  • In reply to Big_Buck:

    Hey Paul,

    In regards to your question:

    Big_Buck

     

    Question is now, if a user's desktop has TLS 1.2 implemented, if a server has TLS 1.3 ONLY rule, what will happen to XG - in between - trying to scan that traffic 

    The XG would relay what the server responds with, which would be a TLS error.

    Regards,

  • In reply to FloSupport:

    Thanks.  And when should we expect that XG will be able to inspect TLS 1.3 traffic ?  I haven't seen any road-map mentioning it ...

    Paul Jr

  • In reply to Big_Buck:

    Hi Paul,

    Below was the feedback I was provided.

    FloSupport

    Native support for TLS 1.3 inspection is tentatively planned to be introduced in SFOS v18. However this could be subject to change at anytime.

  • TLS 1.3 is available in SFOS v18 (tentative release date 18th Feb) for XG Firewall. :)

  • In reply to AHM_Mohsin:

    Hi,

    do you mean GA release or just v18 eap4?

    Ian

  • In reply to rfcat_vk:

    SSLx (DPI) supports TLS1.3 and does not downgrade the TLS communication to TLS1.2.

  • In reply to AHM_Mohsin:

    What ??? GA ??????????

    But DPI is now even close to work properly !!!

    So all we had with v18 is a NAT re-melt ?

    Paul Jr

  • In reply to Big_Buck:

    Paul that is not correct.

    V18 is plenty of new features. Take the XG engineering course and you will see how many improvements have been added. Dpi is under improvement and it will be fixed in GA. I am the one that at the moment in beta, dpi is not working at all but They found 2 bugs and they are fixing it.

  • In reply to lferrara:

    It is not true ... Yes and No.

    First, I took the "free" courses. already.

    Full of new features ... Depends if you look at this from within Sophos, or from a market point of view.

    DPI (or whatever called xtream) and NAT re-melt are certainly main titles of v18. If one discount any of them, you cut v18 in half.

    As for for DKIM, among other things, ... that is catch-up with things competitors had since a decade. It is like saying connecting your Iphone to a car is a new feature ... If your previous car was a Citroën 2cv, then, yes, there are "many" new features.

    We can also underline basic things we still do not have.

    1. A "real time" workable Logviewer. Or real time link to wire Shark. A log Viewer CheckPoint's style.
    2. A real DHCP.
    3. A real NTP relay or server.
    4. et.c.

    So ... It's better than v17. Yes. But it won't shake our security's industry.

    Just add to that some closed minded folks at Sophos decided you cannot install it on XG105 when we all know it works very well with a $60 of hardware upgrade. A boosted XG105 is actually faster than a XG115. No. They want you to fill trashes sites and spent another thousand or two dollars uselessly.

    Finally, we have waited 3 years for that. Better late than never.

    Paul Jr

  • In reply to Big_Buck:

    It still a little bit far from competition in certain features, but the line has been tracked. I am waiting also for a logging improvement but the rest of the features are great now and depending in the industry you work in, v18 can be deployed on several installation and replace UTM 9.

    UTM does not have DPI at all and other features. Also, apart some bugs on DPI (which is still not fixed), XG v18 was very stable since EAP1 and this sounds like a great improvement compared to "disasters" occurred during 17. MRX where they tried to fix IPSec protocol.

    For my point of view, v18+ has all the chance to take a relevant portion in the industry!