This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Web protection exception rule - ip that matches to dns group

Hello,

I'm using a video cloud system called StarLeaf. Since I have enabled SSL traffic, I need to exclude some urls that are written using IP, not a specific hostname.

These ip are 3 and are associated to config.starleaf.com. Actually they are:

72.28.118.203

80.231.134.47

89.202.39.91

For the moment, I created 3 rules like these:

^https?://72\.28\.118\.203\.*

^https?://80\.231\.134\.47\.*

^https?://89\.202\.39\.91\.*

But obviously when the ip will change, I will need to modify the rules too.

Can anyone suggest a way to create a definitive rule?

thanks



This thread was automatically locked due to age.
Parents
  • This is odd, because SSL (actually now TLS) must use a DNS name not an IP address, because part of the process is to validate the other node. If your exceptions work, then the request is using an IP and not a host name.

    The application may be authenticating with TLS and then switching to port 80 without SSL for the video feed.   You may not care in this case, but it is worth noting in case you do.  Encryption creates performance issues for live video.

    If the second session is using anything other than port 80, your exceptions should have been ignored.

    Transparent mode proxy would ignore any traffic on non-standard porys and firewall rules would apply instead.  Standard mode proxy would block any nom-standard port until specifically authorized.

    Consequently, I wonder what your proxy logs indicate about my confusion.

    I am also curious if Bob's solution does solve the whole problem.

  • DouglasFoster said:

    This is odd, because SSL (actually now TLS) must use a DNS name not an IP address, because part of the process is to validate the other node. If your exceptions work, then the request is using an IP and not a host name.

    In the logs I see only ip, not hostnames, in that case the solution was to add exception using hostnames with regular expressions.

    DouglasFoster said:

    The application may be authenticating with TLS and then switching to port 80 without SSL for the video feed.   You may not care in this case, but it is worth noting in case you do.  Encryption creates performance issues for live video.

    If the second session is using anything other than port 80, your exceptions should have been ignored.

    Port 80 is never used. Yes, I know about performaces issues, but https port is used just because in this way, videoconferences always works: 443 port is always opened. For a better performance, breeze uses also other upd ports.

    DouglasFoster said:

    I am also curious if Bob's solution does solve the whole problem.

    Yes, it solved my problem.

    thanks

    f.

     
Reply
  • DouglasFoster said:

    This is odd, because SSL (actually now TLS) must use a DNS name not an IP address, because part of the process is to validate the other node. If your exceptions work, then the request is using an IP and not a host name.

    In the logs I see only ip, not hostnames, in that case the solution was to add exception using hostnames with regular expressions.

    DouglasFoster said:

    The application may be authenticating with TLS and then switching to port 80 without SSL for the video feed.   You may not care in this case, but it is worth noting in case you do.  Encryption creates performance issues for live video.

    If the second session is using anything other than port 80, your exceptions should have been ignored.

    Port 80 is never used. Yes, I know about performaces issues, but https port is used just because in this way, videoconferences always works: 443 port is always opened. For a better performance, breeze uses also other upd ports.

    DouglasFoster said:

    I am also curious if Bob's solution does solve the whole problem.

    Yes, it solved my problem.

    thanks

    f.

     
Children
No Data