BUG - SSL/TLS service selection does not list all services

Hi rfcat_vk 

Thanks for the feedback . We would like to investigate for "The Fronius-a and my weather station" connection not established after enabled SSL/TLS Rule if it is an issue.

Sending you PM for more details.

Thanks,

Rana Sharma

Hi Rana,

I have fixed the issue for the moment with a change to a  linked NAT using MASQ while I do further testing with a SSL/TLS rule now I know about UDP not being scanned by SSL/TLS. 

I do have a question though about UDP scanning to do with QUIC which is handled by the proxy I think?

Ian

In v18.0 only SSL/TLS connections using TCP/IP can be decrypted and managed.  Those on UDP/IP cannot.

In v18.0 QUIC is not supported by either the web proxy mode or the DPI mode, which is why there is a "Block QUIC" checkbox.

In the SSL/TLS Inspection Rule, Service selection box there is the text immediately below the box (you can see it in your screenshots) "Any UDP property of a service will not be enforced."

In addition, we made it so UDP-only services are not listed, since selecting them would not result in anything being implemented.

The thing is, it became a quagmire if we wanted to fully protect against people configuring an inspection rule UDP services.  Since you can create services from within the selector and all created services appear.  More complicated is when someone selects a service that was TCP, saves, and then changes the service to be UDP.

The UI implementation is:

- You are allowed to select save services that are both TCP and UDP.  The UDP parts will not work, and the text below the selector tells you that.

- You are allowed to save services that are UDP only.  This can only happen if you created a UDP service inside creating the rule.

- You are allowed to change a service to UDP only, even if it is used by a SSL/TLS Inspection Rule.

- When loading the SSL/TLS Inspection Rule in the UI, any invalid services (any UDP only) are removed from the list of services.  If you save the Rule, it will be saved with the services removed.  If you cancel the rule is unchanged.

If this turns out to be confusing, or we need to add more UI protection at preventing UDP from being added, we will revisit.

Hi Michael,

thank you for the very detailed explanation.

I expect to be told I am being overly cautious in locking my IoT devices and then scanning them. The IoT devices are fixed as to where they can talk to using what ports, so I was just adding cream to the pie while trying out new features.

This all came about because I have a device that has its traffic classified as P2P/torrent and I cannot see why a power switch needs to have a P2P/torrent session many times a day. I suspect it really is a NTP session to its home base.

Still experimenting.

Ian

Hi Michael,

thank you for the very detailed explanation.

I expect to be told I am being overly cautious in locking my IoT devices and then scanning them. The IoT devices are fixed as to where they can talk to using what ports, so I was just adding cream to the pie while trying out new features.

This all came about because I have a device that has its traffic classified as P2P/torrent and I cannot see why a power switch needs to have a P2P/torrent session many times a day. I suspect it really is a NTP session to its home base.

Still experimenting.

Ian