Support for SSH Inspection with the new Xstream Inspection Engine.

Hi,

Will the new Xstream SSL/TLS Inspection engine support SSH Inspection?

This would allow to block SSH-Tunnels, X-11 Forwarding, Port-Forward, and also allow for AV Scanning on files being transferred over SSH.

 

There's already an Idea on Sophos Ideas about this. It has made in June/2018.

 

Thanks!

Parents
  • SSH does not use SSL/TLS, so the quick answer is no. Google "SSH vs TLS".


    That being said, the Xstream SSL/TLS inspection engine works on any TLS stream, not just HTTPS.
    As per my understanding:

    Just like firewall rules, SSL/TLS inspection rules apply to a "Service" which is really a port.
    Therefore you can build one set of SSL/TLS inspection rules for HTTPS (443) and a different set for other services. If you are only trying to cover port HTTPS on 443, make sure that you switch from Any to HTTPS.

    In v18.0, at the start of any TCP connection on any port we will detect if it starts with a TLS handshake. If it is, the SSL/TLS inspection rules are applied to the TLS connection. That means that the protocol and certificate enforcement that is in the decryption profile are enforced, and that if configured to decrypt the TLS connection is decrypted and re-signed with a the appliance's CA. If there are no matching rules, then is in effect Don't Decrypt, Maximum Compatibility, Do not log.

    If we are decrypting, once there is a TLS tunnel is established we attempt to do HTTP detection within it.
    If traffic within the encrypted tunnel matches the HTTP spec, we then apply web policy and virus scan as per the firewall rule.
    If traffic within the encrypted tunnel does not match the HTTP spec, we then allow it unscanned.

    Therefore in v18 we support TLS enforcement on any TLS connection on any port. But within the TLS tunnel we only support HTTP.

    But SSH uses a different encryption protocol than TLS, and is not supported in v18.

Reply
  • SSH does not use SSL/TLS, so the quick answer is no. Google "SSH vs TLS".


    That being said, the Xstream SSL/TLS inspection engine works on any TLS stream, not just HTTPS.
    As per my understanding:

    Just like firewall rules, SSL/TLS inspection rules apply to a "Service" which is really a port.
    Therefore you can build one set of SSL/TLS inspection rules for HTTPS (443) and a different set for other services. If you are only trying to cover port HTTPS on 443, make sure that you switch from Any to HTTPS.

    In v18.0, at the start of any TCP connection on any port we will detect if it starts with a TLS handshake. If it is, the SSL/TLS inspection rules are applied to the TLS connection. That means that the protocol and certificate enforcement that is in the decryption profile are enforced, and that if configured to decrypt the TLS connection is decrypted and re-signed with a the appliance's CA. If there are no matching rules, then is in effect Don't Decrypt, Maximum Compatibility, Do not log.

    If we are decrypting, once there is a TLS tunnel is established we attempt to do HTTP detection within it.
    If traffic within the encrypted tunnel matches the HTTP spec, we then apply web policy and virus scan as per the firewall rule.
    If traffic within the encrypted tunnel does not match the HTTP spec, we then allow it unscanned.

    Therefore in v18 we support TLS enforcement on any TLS connection on any port. But within the TLS tunnel we only support HTTP.

    But SSH uses a different encryption protocol than TLS, and is not supported in v18.

Children
  • Hi,


    We're well aware of what we'd like to do regarding SSH inspection and the use cases for why it's needed.  We have this story in our feature backlog.   Thanks!

  • Michael Dunn said:

    If we are decrypting, once there is a TLS tunnel is established we attempt to do HTTP detection within it.
    If traffic within the encrypted tunnel matches the HTTP spec, we then apply web policy and virus scan as per the firewall rule.
    If traffic within the encrypted tunnel does not match the HTTP spec, we then allow it unscanned. 

    To clarify:

    If traffic within the encrypted tunnel does not match the HTTP spec, we then allow it without scanning for viruses. We may apply ATP, IPS, and other policies.