Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 13 replies
  • Subscribers 6 subscribers
  • Views 2667 views
  • Users 0 members are here
Options
Suggested

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

rfcat_vk

Hi folks,

I am setting up a new rule to split some of my IoT rules into https scanning and using SSL/TLS to scan th none standard ports.

In the firewall rule i can see and select all the IoT services but in the SSL/TLS rules I cannot see all of IoT services. I checked another rule by trying to add the service to ensure it was not a last man failed to make the list issue, but no, it is in the middle of the list.

I don't want to attempt to create the service again, so this is a major bug.

 

Ian

Parents
  • 0

    Hi  

    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

  • 0 in reply to 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

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk

    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.

Reply
  • 0 in reply to rfcat_vk

    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.

Children
  • 0 in reply to Michael Dunn

    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

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

Unfiltered HTML