Thread Info
  • State Suggested Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 5 subscribers
  • Views 2456 views
  • Users 0 members are here
Options
Suggested

My challenges with TLS/SSL Inspection

stlissold

Hi there,

I am using v18 EAP2 now for a few weeks at home (best lab :D) and have some weird happenings.

 

1. I am using Google home speakers, which have trouble connecting/answering questions every now and then, only working after asking twice. After building an exception for all speakers it is working again. It is hard to troubleshoot, as all SSL errors were fixed and no other security features are enabled in the firewall policy rule.

2. I am using Threema, a secure instant messaging client on mobile phones. This one is unknown via app control, so there is no catergory and therefore no way to build an exception for it. As there are no URLs communicated for it I am not able to except anything - Fun fact: Threema is working with messaging and stuff, but sending pictures is not possible. After switching wifi off the file is send immediately. Same here: No other Security Features are enabled. In SSL/TLS log you see a connection to blobp-upload.threema.ch. I added it to my Local exception list but it is still not working. How to troubleshoot it further?

 

Regards
Stefan

Parents
  • 0

    Hi Stefan,

    you can setup a rule that allows your speakers etc only out without using https scanning or TLS/SSL DPI. I think that would be a better solution rather than trying to setup exceptions which add complexity to the debugging process. If you set the initial rule to allow any service then you can see what is being used in logviewer and then restrict/improve security by only allowing that rule to use those ports.

    Ian

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 EAP

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

  • 0 in reply to rfcat_vk

    Hi Ian,

    I tried that before but is not working correctly.

    Now I disabled SSL/TLS decrypting (via inspection settings) and everything is working again without any problems.

     

    So my experience: Troubleshooting is very hard if you are using SSL/TLS inspection, even if nothing is decrypted.

     

    Right after disabling, what is the most compatible way which should not produce any errors? SSL/TLS with decryption profile 'Maximum compatibility' is causing a lot of trouble in my network. Is there another, maybe not so strict way?

     

    Regards

    Stefan

  • 0 in reply to stlissold

    Hi Stefan,

    if you are using a firewall rule that does not have any boxes ticked in the WEB proxy orTLS/SSL then your traffic is going out another firewall rule. 

    I have firewall rules that do not use TLS/SSL inspection for some of my IoT devices that do not like or understand inspection.

    Ian

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 EAP

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

  • 0 in reply to stlissold

    One area that we are not yet where we want to be is in reporting connection failures that happen when a client does not (or can not) have the XG Firewall's re-signing CA file installed. These are currently reported as successes in the SSL/TLS log, because the failure is actually caused by the client rejecting the certificate, not by some error or problem on the firewall. We are hoping to improve this significantly, but this will most likely not come until a refresh to our EAP3 release.

    In general, though, it is almost always going to be best to exclude IOT devices from SSL/TLS decryption completely, unless you happen to have a device that allows you to install additional CA certificates. If it cannot trust an external signing certificate, then it will never successfully accept decrypted connections - not just from XG Firewall, but from any SSL inspection product. 

Reply
  • 0 in reply to stlissold

    One area that we are not yet where we want to be is in reporting connection failures that happen when a client does not (or can not) have the XG Firewall's re-signing CA file installed. These are currently reported as successes in the SSL/TLS log, because the failure is actually caused by the client rejecting the certificate, not by some error or problem on the firewall. We are hoping to improve this significantly, but this will most likely not come until a refresh to our EAP3 release.

    In general, though, it is almost always going to be best to exclude IOT devices from SSL/TLS decryption completely, unless you happen to have a device that allows you to install additional CA certificates. If it cannot trust an external signing certificate, then it will never successfully accept decrypted connections - not just from XG Firewall, but from any SSL inspection product. 

Children
No Data
Unfiltered HTML