How will Sophos UTM intercept/protect against malicious data in TLS 1.3 secured connections?

Of course, you have to be using decrypt-and-scan for this to be done at all.    With it enabled, UTM acts as server to the browser, and acts as client to the website.   In both cases, it will negotiate based on what it can do, which will result in a TLS1.2 session.    So there is no security breach created by its existence.   I think we are a long ways from seeing either clients or servers that support TLS1.3 exclusively, so I do not think you will see denial-of-service for that reason.

I had read previously that TLS 1.3 created feasibility problems for decrypt-and-scan (https inspection).  Your post caused me to research the issue further.  The following links (all https) were helpful.  I have obscured them with spaces because I don't think the forum allows links to non-Sophos sites (for our security).

• blog . cloudflare . com / why-tls-1-3-isnt-in-browsers-yet
  A discussion about the challenges faced when people tried to deploy early version of TLS 1.3, and how the design has evolved as a result.  Lots of material about how a security device which is not aware of TLS 1.3 can create obstacles to TLS 1.3 implementation.  It also shows that the TLS 1.3 standard has been slow to stabilize.
  
  
• blogs . cisco . com / security /tls-1-3-and-forward-secrecy-count-us-in-and-heres-why
  Mostly a discussion about why PFS is important, and therefore TLS 1.3 is important because PFS is required.   But it also had a pointer to the next article.
  
  
• tools .ietf . org / html/draft-camwinget-tls-use-cases-00
  A Cisco-written document about the problems that TLS 1.3 creates for proxy devices,but without solutions.   My interpretation from a first read of the document is that:
  a) HTTP Inspection for TLS 1.3 will only work in STANDARD mode.
  b) WAF / Webserver Protection / Reverse Proxy for TLS 1.3 will NOT WORK AT ALL.

Given all of that, I can understand why Sophos is not rushing to implement TLS 1.3 in UTM.

Of course, you have to be using decrypt-and-scan for this to be done at all.    With it enabled, UTM acts as server to the browser, and acts as client to the website.   In both cases, it will negotiate based on what it can do, which will result in a TLS1.2 session.    So there is no security breach created by its existence.   I think we are a long ways from seeing either clients or servers that support TLS1.3 exclusively, so I do not think you will see denial-of-service for that reason.

I had read previously that TLS 1.3 created feasibility problems for decrypt-and-scan (https inspection).  Your post caused me to research the issue further.  The following links (all https) were helpful.  I have obscured them with spaces because I don't think the forum allows links to non-Sophos sites (for our security).

• blog . cloudflare . com / why-tls-1-3-isnt-in-browsers-yet
  A discussion about the challenges faced when people tried to deploy early version of TLS 1.3, and how the design has evolved as a result.  Lots of material about how a security device which is not aware of TLS 1.3 can create obstacles to TLS 1.3 implementation.  It also shows that the TLS 1.3 standard has been slow to stabilize.
  
  
• blogs . cisco . com / security /tls-1-3-and-forward-secrecy-count-us-in-and-heres-why
  Mostly a discussion about why PFS is important, and therefore TLS 1.3 is important because PFS is required.   But it also had a pointer to the next article.
  
  
• tools .ietf . org / html/draft-camwinget-tls-use-cases-00
  A Cisco-written document about the problems that TLS 1.3 creates for proxy devices,but without solutions.   My interpretation from a first read of the document is that:
  a) HTTP Inspection for TLS 1.3 will only work in STANDARD mode.
  b) WAF / Webserver Protection / Reverse Proxy for TLS 1.3 will NOT WORK AT ALL.

Given all of that, I can understand why Sophos is not rushing to implement TLS 1.3 in UTM.