Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 10869 views
  • Users 0 members are here
Options
Suggested
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

akamaihd.net und co

Marcel Hoffmann

Hallo Community,

ich habe mal eine Frage zu den CDN-Anbietern, wie akamaihd.net, akamaized.net, googlevideo usw. Diese sind ein großer Bestandteil unseres täglichen Traffics. Bisher haben wir noch keine Appcontrol oder QOS-Regeln für Apps eingeführt. Wird aber wohl bald soweit sein, facebook und co. kann ich nicht blocken, da es teilweise auch betrieblich genutzt wird.

Bisher habe ich immer angenommen, dass die ersten beiden immer Content-Lieferanten von Facebook und co. sind ... aber ist das wirklich so? Wenn ich den Report eines Users anschaue, der gestern 4GB mit akamaihd.net verbraten hat, sehe ich auch als URL erst einmal nur http://akamaihd.net ... kann man irgendwie auf die Quelle schließen, also die Website, von der dieser Inhalt nachgeladen wurde? Ist das nur Facebook, oder evtl. auch youtube? Beides finde ich in der URL-List dieses Users. Ich wäre allerdings etwas überrascht, wenn Facebook-Videos in kurzer Zeit 4GB durch die Leitung jagen.

Danke für Denkanstöße :)

Gruß

Marcel



This thread was automatically locked due to age.
Parents
  • 0

    You must implement https decrypt-and-scan.   Most of these sites use HTTPS for everything.  With HTTPS decrypt-and-scan off, UTM only logs the initial connection to the server.  All of the remaining detail is hidden in the encrypted portion of the packet, and all of the subsequent requests are not logged.   With HTTPS decrypt-and-scan on, you get the full path for every web request.

Reply
  • 0

    You must implement https decrypt-and-scan.   Most of these sites use HTTPS for everything.  With HTTPS decrypt-and-scan off, UTM only logs the initial connection to the server.  All of the remaining detail is hidden in the encrypted portion of the packet, and all of the subsequent requests are not logged.   With HTTPS decrypt-and-scan on, you get the full path for every web request.

Children
  • 0 in reply to DouglasFoster

    Hi Douglas,

    thanks a lot, that sounds interesting.

    We already use our root signing CA to avoid certificate errors. So I guess I can also use it for https decrypting.

    I remember that I tried to use a subordinate CA for this purpose but for some reason this never worked. The VPN connections all ran into an error with a subordinate CA, so I went back to the root CA although I have my doubts if this is a good idea for security reasons.

    Best regards

    Marcel

  • 0 in reply to Marcel Hoffmann

    Yes, I think the resolution of your other problem was that a subordinate signing CA does not work, but I have never tried it myself.

    Known issues with https decrypt-and-scan:

    • It does not work well with non-standard traffic such as Citrix ICA.   Bypass web proxy or disable https inspection for those sites.

    • UTM will block sites with invalid certificate chains.    In the web proxy logs, look for id="0002" and error=""  to find problem URLs.   You have to use ssllabs.com server test, your certificate vendor's test site, or the Openssl utility to find out the reason:

      • Missing intermdiate certifcate:  Obtain the missing certificate and install it as a local root certificate.   If the site is safe, you can browse to it with UTM bypassed, then display the certificate properties for the site.  Navigate up to the intermediate certificate and export to a file.  This workaround is possible because browsers implement AIA Fetching to correct for intermediate certificate errors, but UTM does not.
      • In firmware 9.4, UTM will also block sites that include a self-signed root certificate.   Upgrade to 9.5 or create an exception to bypass certificate checking for that site.
      • Expired certicates.   These are usually sites that do not matter, but if they do matter, you should contact the site owner.   As a workaround, create an exception to bypass certificate date checking.
      • In older firmware, Chrome 58 and later will reject the UTM CA certificate.   This has been corrected, I think he patches appeared in UTM 9.413 and 9.503.
  • 0 in reply to DouglasFoster

    Thanks a lot for your help. By now I have only activated https decrypting for certain categories (that include social media and streaming sites). Let's see, if I can get now more information from the logs :).