Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 6 subscribers
  • Views 5234 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

TLS erzwingen beim E-Mail Versand/Empfang

HJW

Hallo,

auf einem UTM-Cluster (v9.708-6) habe ich unter "Email Protection" ==> "SMTP" ==> "Advanced" ==> "TLS Settings" das Zertifikat (Commodo) hinterlegt und "TLS version" auf 1.2 gesetzt. Funktioniert alles ganz normal, E-Mails werden TLS-verschlüsselt, wenn es geht. CheckTLS ist für die Absenderdomain der UTM auch happy.

Jetzt habe ich unter "Require TLS Negotiation Hosts/Nets" ==> "Internet IPv4" (und v6) hinzugefügt, um Verbindungen ohne TLS zu verhindern. Gut, da bleiben einige ausgehende E-Mails im Spool liegen, also dachte ich mir, ich trage die "guten" Domains, also diejenigen die ausnahmsweise auch ohne TLS erreichbar sein müssen unter "Skip TLS Negotiation Hosts/Nets" ein. Also die MX-Records der Empfänger-Domain rausgesucht, die vier FQDNs als vier "DNS Group" angelegt und bei "Skip TLS ..." eingetragen.

Leider skipped da nichts, E-Mails an die Non-TLS-Domain bleiben im Spool liegen, bis ich "Internet IPv4" bei "Require TLS Negotiation Hosts/Nets" lösche, danach werden sie abgesendet.

Mit dem Sophos-Support mach ich jetzt seit dem 30.11. rum, ohne Aussicht auf Erfolg, ich bin noch keinen Schritt weiter. Außer einer schwammigen Aussage, dass "Require" immer vor "Skip" bewertet wird. Wenn dem so sein sollte, wozu gibt es dann "Skip"? Ich soll jetzt alle Domainen, die TLS unterstützen, bei "Require" eintragen. Haha! Im Ernst, so habe ich das indische Englisch am Telefon interpretiert. Das kann doch nicht sein, oder?

2021:11:30-13:22:07 gate-2 exim-out[17258]: 2021-11-30 13:22:07 1mrzw5-0004hu-SL H=mxb.expurgate.de [194.145.224.21]:25: a TLS session is required, but the server did not offer TLS support
2021:11:30-13:22:07 gate-2 exim-out[17258]: 2021-11-30 13:22:07 1mrzw5-0004hu-SL H=mxb.expurgate.de [194.145.224.15]:25: a TLS session is required, but the server did not offer TLS support
2021:11:30-13:22:07 gate-2 exim-out[17258]: 2021-11-30 13:22:07 1mrzw5-0004hu-SL H=mxb.expurgate.de [194.145.224.16]:25: a TLS session is required, but the server did not offer TLS support
2021:11:30-13:22:07 gate-2 exim-out[17258]: 2021-11-30 13:22:07 1mrzw5-0004hu-SL H=mxb.expurgate.de [195.190.135.23]:25: a TLS session is required, but the server did not offer TLS support
2021:11:30-13:22:07 gate-2 exim-out[17258]: 2021-11-30 13:22:07 1mrzw5-0004hu-SL H=mxb.expurgate.de [195.190.135.22]:25: a TLS session is required, but the server did not offer TLS support
2021:11:30-13:22:07 gate-2 exim-out[17257]: 2021-11-30 13:22:07 1mrzw5-0004hu-SL == aaa.bbb@xxx.de R=dnslookup T=remote_smtp defer (-38) H=mxb.expurgate.de [195.190.135.22]:25: a TLS session is required, but the server did not offer TLS support

mxb.expurgate.de ist einer der MX-Records der Empfängerdomain (hier als xxx.de "geschwärzt"), also irgendein vorgeschalteter Dienstleister. Alle MX-Records der Empfängerdomain fallen bei CheckTLS durch.

Frage: Habe ich alles richtig gemacht? Ist das ein Bug oder ein Feature, dass "Skip" ignoriert wird?

Danke für eure Unterstützung!



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to emmosophos

    Hi Emmanuel,

    sure, the ID is: 04676748

    Thanks in advance,

      HJW

  • 0 in reply to HJW

    Hello HJW,

    Thank you for the Case ID.

    As per NUTM-9617 Require TLS Negotiation Hosts/Nets does have a higher priority than SKIP tls, this is by design since implementation. 

    I do understand your point about the logic, of "REQUIRING" having a higher priority than SKIP, so I have asked for feedback, once I hear back I will update the thread.

    As a possible workaround, you could select the specific domains you want to enforce TLS negotiation rather than forcing all domains. 

    Regards,

     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • +1 in reply to emmosophos

    Hello HJW,

    Based on feedback, "The intent of ‘Require TLS Negotiation’ was to specify sensitive domains where we should NOT send messages if TLS negotiation failed. It was never really intended to be used to force TLS for ALL domains."

    Is this what you’re looking to do? Or are you just trying to ensure TLS is used whenever it’s available, but fallbacks are acceptable?

     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • 0 in reply to emmosophos

    Hi Emmanuel,

    emmosophos said:
    Or are you just trying to ensure TLS is used whenever it’s available, but fallbacks are acceptable?

    Fallbacks are acceptable if our side makes the decission to do so. Without "Require for all", the decision is made by the receiving side, which is out of our control.

    It was the customers request, to make sure the DS-GVO is met - and he will not run into trouble, because sensitive data is sent unencrypted. Disappointed

    emmosophos said:
    "The intent of ‘Require TLS Negotiation’ was to specify sensitive domains where we should NOT send messages if TLS negotiation failed. It was never really intended to be used to force TLS for ALL domains."

    Ok, this is bad news.

    emmosophos said:
    As a possible workaround, you could select the specific domains you want to enforce TLS negotiation rather than forcing all domains. 

    Yes, IF we know before. But what if e.g. an emplyoee sends an email with sensitive data  to a new recipient for the first time? TLS could fail and we are guilty, because we didn't drop the connection. As a workaround, we need to check every new domain manually beforew we add it to the"Required-List" ...

    Just being curiuos:
    In the given situation

    emmosophos said:
    Require TLS Negotiation Hosts/Nets does have a higher priority than SKIP tls, this is by design

    - in what case would the "Skip-List" be used? If we for example put the known nets/hosts for "google.com, outlook.com, ..." into the "Require-List", what will go into the "Skip-List"?
    Every other net/host beside of "google.com or "outlook.com" could be skipped anyway, if the receiver does not offer TLS.

    It does not make any sense to me, sorry...

    Another thought, which came into my mind right now:
    Some time ago, we tried to enable a system inside the office to pick emails via IMAPS from outlook.office365.com, therefore a FW-rule was created with "inside-system => 993 (tcp) => outlook.office365.com". It didn't work out, because the DNS clients on the inside system and on the UTM resolved "outlook.office365.com" to different IP addresses with each lookup. So, we had to use "inside-system => 993 (tcp) => any".

    What I tried to explain: We cannot use "outlook.office365.com" in the "Require TLS" list, because it's IP address is not enduring, it changes with every lookup. We would need to enter all M$ networks (as they are documented now and stay unchanged) - same for google and every bigger company behind a loadbalancer. I think, this isn't a feasible way.

    But anyway, thanks for your explanation, and maybe you could explain to me, what the "Skip TLS" list is used for, maybe I can work with it, once I understood.

    Thank you!
      HJW

  • +1 in reply to HJW

    Hello HJW,

    Just to let you know that I provided your feedback to our PM team, they mentioned that the Skip TLS negotiation setting was designed more in mind for troubleshooting or working around servers that might cause problems with their TLS implementations (If TLS is incompatible in some way), this was due to the fact that where situations were attempting to communicate over TLS would partially succeed, (enough) to prevent the UTM failing back to SMTP, but not enough for the messages to get through in a timely fashion.

    Based on your feedback this will be put as a consideration for a future release. 

    Thank you for filling your idea on ideas.sophos.com

    Regards,

     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
Unfiltered HTML