TLS แบบฉวยโอกาสกับ Force TLS ในสภาพแวดล้อมที่ใช้ Exchange | ตอนที่ 2#12

ในบทความปัจจุบัน เราจะตรวจสอบ "รสชาติ" สองประการของ TLS ในสภาพแวดล้อมแบบ Exchange สองตัวเลือกสำหรับการนำ TLS ไปใช้ ได้แก่ การฉวยโอกาส TLS และ บังคับ TLS

เซิร์ฟเวอร์ที่ใช้ Exchange (Exchange on-Premises และ Exchange Online) ได้รับการกำหนดค่าตามค่าเริ่มต้นเพื่อใช้ตัวเลือกของ TLS เชิงโอกาส

ความหมายก็คือว่า "อีกด้านหนึ่ง" รองรับ TLS ด้วย โปรโตคอลการสื่อสารเมลที่จะใช้คือ TLS

ตัวเลือกของ TLS ที่ฉวยโอกาส ไม่เหมาะสมกับสถานการณ์ที่เราต้องการตั้งค่าความจำเป็นที่จำเป็นสำหรับ ใช้ TLS ตัวอย่างเช่น ในกรณีที่อีกฝ่ายไม่รองรับ TLS เรา ไม่เต็มใจ ที่จะรับส่งอีเมลต่อไปผ่านสายการสื่อสารที่ ไม่ปลอดภัย

สถานการณ์เพิ่มเติมที่ตัวเลือก TLS ที่ฉวยโอกาส ไม่เหมาะสมคือ - สถานการณ์ที่เราต้องการ กำหนดกฎเกณฑ์เฉพาะสำหรับกระบวนการระบุตัวตน เช่น - ข้อกำหนดจาก “อีกด้านหนึ่ง” เพื่อระบุตัวตนโดยจัดเตรียมใบรับรองสาธารณะหรือใบรับรองที่มีชื่อโฮสต์\โดเมนเฉพาะ

หมายเหตุ: เท่าที่ฉันรู้ ตัวเลือกของ TLS ที่ฉวยโอกาส ทำหน้าที่สำหรับการเข้ารหัสช่องทางการสื่อสารเท่านั้น แต่ไม่ใช่สำหรับการนำกระบวนการระบุตัวตนไปใช้ ข้อมูลระบุตัวตนของเมลเซิร์ฟเวอร์อื่น

TLS สองรสชาติในสภาพแวดล้อม Exchange

การใช้ TLS เพื่อเข้ารหัสช่องทางการสื่อสารระหว่างเมลเซิร์ฟเวอร์สองเครื่องสามารถทำได้สองวิธี:

1. TLS ที่ฉวยโอกาส

วิธีการที่สามารถอธิบายได้ว่าเป็น “ความพยายามอย่างดีที่สุด ”
เมื่อเรากำหนดค่าเมลเซิร์ฟเวอร์ของเราให้ใช้ตัวเลือกของ TLS ที่ฉวยโอกาส< แต่ละครั้งที่เมลเซิร์ฟเวอร์จะพยายามส่งข้อความอีเมลไปยังเมลเซิร์ฟเวอร์อื่น (การรับส่งเมลขาออก) เมลเซิร์ฟเวอร์ของเราจะพยายามตรวจสอบว่าอีกฝ่ายรองรับ TLS หรือไม่

หากเมลเซิร์ฟเวอร์ปลายทางรองรับ TLS เมลเซิร์ฟเวอร์ของเราจะส่งอีเมลผ่านช่องทางการสื่อสารที่ปลอดภัยโดยใช้โปรโตคอล TLS

หากเมลเซิร์ฟเวอร์เป้าหมายไม่รองรับโปรโตคอล TLS เมลเซิร์ฟเวอร์ของเราจะ "ตกลง" เพื่อใช้ช่องทางการสื่อสารที่ไม่ได้เข้ารหัสโดยใช้โปรโตคอล SMTP

มีการใช้ตรรกะเดียวกันนี้เกี่ยวกับสถานการณ์ของเมลขาเข้า - เมื่อเซิร์ฟเวอร์เมลอื่นพยายามสื่อสารเซิร์ฟเวอร์เมลของเรา (กระแสเมลขาเข้า) เซิร์ฟเวอร์เมลของเราจะพยายามเสนอการใช้ TLS

<แข็งแกร่ง>2. บังคับใช้ TLS - ความจำเป็นบังคับสำหรับการใช้ TLS

เมื่อเรากำหนดค่าเมลเซิร์ฟเวอร์ของเราให้ใช้ตัวเลือก Force TLS เราจะกำหนดความจำเป็นที่จำเป็น การใช้ TLS เพื่อการสื่อสารทางไปรษณีย์

แต่ละครั้งที่เมลเซิร์ฟเวอร์จะพยายามส่งข้อความอีเมลไปยังเมลเซิร์ฟเวอร์อื่น (การรับส่งเมลขาออก) เมลเซิร์ฟเวอร์ของเราจะพยายามตรวจสอบว่าอีกฝั่งหนึ่งรองรับ TLS หรือไม่

หากเซิร์ฟเวอร์เมลปลายทางรองรับ TLS อีเมลจะถูกส่งผ่านช่องทางการสื่อสารที่ปลอดภัย (โดยใช้โปรโตคอล TLS สำหรับการเข้ารหัสช่องทาง)

ในกรณีที่เซิร์ฟเวอร์อีเมลปลายทางไม่รองรับ TLS การสื่อสารทางอีเมลจะไม่ดำเนินการต่อ

เพื่อให้สามารถเข้าใจตรรกะของ TLS ที่ฉวยโอกาส และ Force TLS ลองใช้คำอธิบายโดยละเอียดเพิ่มเติมเกี่ยวกับสถานการณ์ทางเลือกแต่ละสถานการณ์และขั้นตอนเฉพาะที่รวมอยู่ในแต่ละสถานการณ์ .

1.TLS เชิงฉวยโอกาส

วิธีการที่เมลเซิร์ฟเวอร์ต้องการใช้ช่องทางการสื่อสารที่ปลอดภัยกับเมลเซิร์ฟเวอร์อื่น แต่ในกรณีที่ “เซิร์ฟเวอร์เมลปลายทาง” ไม่รองรับโปรโตคอล TLS เมลเซิร์ฟเวอร์ต้นทางยินดีที่จะ “ประนีประนอม” และตกลงที่จะใช้ ช่องทางการสื่อสารที่ไม่ปลอดภัยโดยใช้โปรโตคอล SMTP

วิธีการ TLS ที่ฉวยโอกาส ถูกนำมาใช้โดยใช้การเจรจาต่อรองระหว่างเซิร์ฟเวอร์จดหมายต้นทางและปลายทาง

หมายเหตุ: แผนภาพต่อไปนี้ อธิบายสถานการณ์การรับส่งอีเมลที่แตกต่างกันซึ่งใช้ตัวเลือกของ TLS ที่ฉวยโอกาสและ Force TLS

เราเรียกเซิร์ฟเวอร์อีเมล Exchange Online ว่า “เซิร์ฟเวอร์อีเมลขององค์กร ” แต่สิ่งสำคัญคือต้องเน้นย้ำว่าแนวคิด TLS มีความเกี่ยวข้องกับเซิร์ฟเวอร์อีเมลใดๆ เช่น เซิร์ฟเวอร์ Exchange on-Premises หรือเซิร์ฟเวอร์อีเมลประเภทใดๆ

วิธีการ TLS แบบฉวยโอกาสที่นำไปใช้ใน "ทิศทาง" ของการรับส่งอีเมลสองทาง:

1. การรับส่งอีเมลขาออก

เมื่อเซิร์ฟเวอร์เมลต้นทางระบุที่อยู่เซิร์ฟเวอร์เมลปลายทาง เซิร์ฟเวอร์เมลต้นทางจะเริ่มต้นด้วย “ข้อเสนอ” เพื่อใช้การสื่อสารเมลที่เข้ารหัสโดยใช้ TLS

กรณีที่ 1 - ในกรณีที่เซิร์ฟเวอร์ปลายทางตกลงที่จะใช้ TLS ลิงก์การสื่อสารระหว่างเซิร์ฟเวอร์อีเมลจะถูกนำมาใช้โดยใช้โปรโตคอล TLS

กรณีที่ 2 - ในกรณีที่เซิร์ฟเวอร์ปลายทางไม่ยอมรับการใช้ TLS (ไม่รองรับโปรโตคอล TLS หรือมีปัญหาใดๆ เช่น ปัญหาเกี่ยวกับใบรับรองเซิร์ฟเวอร์และอื่นๆ) แหล่งที่มา เมลเซิร์ฟเวอร์ยินดีที่จะ "ดาวน์เกรด" โปรโตคอลการสื่อสารเมลเป็นโปรโตคอลการสื่อสารที่ไม่ปลอดภัยซึ่งหมายถึง - โปรโตคอล SMTP

<แข็งแกร่ง>2. การรับส่งจดหมายขาเข้า

เมื่อเมลเซิร์ฟเวอร์ที่รองรับ TLS ที่ฉวยโอกาส ถูก “ระบุที่อยู่ ” โดยเมลเซิร์ฟเวอร์อื่น โปรโตคอลการสื่อสาร ที่จะนำไปใช้ขึ้นอยู่กับ "เซิร์ฟเวอร์เมลต้นทาง" ที่เริ่มต้นการสื่อสาร

กรณีที่ 1 - ในกรณีที่เซิร์ฟเวอร์อีเมลต้นทาง “ประกาศ ” ว่าเขาต้องการใช้โปรโตคอล TLS เมลเซิร์ฟเวอร์ปลายทางจะแจ้งเซิร์ฟเวอร์เมลต้นทางว่าเขารองรับโปรโตคอล TLS

ผลลัพธ์ก็คือโปรโตคอลเมลที่จะใช้สำหรับการสื่อสารทางอีเมลจะเป็น - โปรโตคอล TLS

กรณีที่ 2 - ในกรณีที่เซิร์ฟเวอร์อีเมลต้นทางไม่ได้ “กล่าวถึง ” ความจำเป็นในการใช้โปรโตคอล TLS เซิร์ฟเวอร์อีเมลปลายทาง (Exchange Online ในสถานการณ์ของเรา) จะพยายามเจรจาและเสนอการใช้งาน โปรโตคอล TLS

ในสถานการณ์เฉพาะของเรา เซิร์ฟเวอร์เมลต้นทางไม่รองรับ TLS

เมลเซิร์ฟเวอร์ปลายทางที่รองรับ TLS ที่ฉวยโอกาส จะไม่ “ยืนยัน ” เกี่ยวกับการใช้โปรโตคอล TLS และ จะตกลงที่จะ "ดาวน์เกรด" ช่องทางการสื่อสารเป็นโปรโตคอลที่ไม่มีการเข้ารหัส

ผลลัพธ์ก็คือโปรโตคอลเมลที่จะใช้สำหรับการสื่อสารเมลจะเป็น - โปรโตคอล SMTP

บังคับ (บังคับ) TLS

คำว่า “Force TLS ” เกี่ยวข้องกับการกำหนดค่า TLS เฉพาะ ซึ่งเซิร์ฟเวอร์อีเมลต้นทาง หรือเมลเซิร์ฟเวอร์ปลายทางยินดีที่จะเริ่มช่องทางการสื่อสารกับเมลเซิร์ฟเวอร์อื่น เฉพาะในกรณีที่ช่องทางการสื่อสารพิจารณาว่าเป็นลิงก์การสื่อสารที่ปลอดภัย หมายถึง - โดยใช้โปรโตคอล TLS

เมื่อเซิร์ฟเวอร์เมลต้นทางระบุที่อยู่เซิร์ฟเวอร์เมลปลายทาง เซิร์ฟเวอร์เมลต้นทางจะเริ่มต้นด้วยการเสนอให้ใช้การสื่อสารเมลที่เข้ารหัสโดยใช้ TLS

สถานการณ์ที่ 1 | เซิร์ฟเวอร์ต้นทางใช้ Force TLS | เซิร์ฟเวอร์ปลายทางไม่รองรับ TLS

ในกรณีที่เซิร์ฟเวอร์เป้าหมายไม่ยอมรับการใช้ TLS (ไม่รองรับโปรโตคอล TLS หรือมีปัญหาบางอย่าง เช่น ปัญหาเกี่ยวกับใบรับรองเซิร์ฟเวอร์ เป็นต้น) เมลเซิร์ฟเวอร์ต้นทางจะไม่ดำเนินการต่อ u> เซสชันเมลและจะยกเลิกการเชื่อมต่อเซสชันกับเซิร์ฟเวอร์เมลปลายทาง

สถานการณ์ที่ 2 | เซิร์ฟเวอร์ต้นทางใช้ Force TLS | เซิร์ฟเวอร์ปลายทางรองรับ TLS ที่ฉวยโอกาส

ในกรณีที่เมลเซิร์ฟเวอร์ปลายทางรองรับตัวเลือก TLS ที่ฉวยโอกาส การเชื่อมโยงการสื่อสารระหว่าง เมลเซิร์ฟเวอร์จะถูกใช้งานโดยใช้โปรโตคอล TLS

สถานการณ์ที่ 3 | เซิร์ฟเวอร์ต้นทางใช้ Force TLS | เซิร์ฟเวอร์ปลายทางรองรับ Force TLS

ในสถานการณ์สมมตินี้ เซิร์ฟเวอร์จดหมายปลายทางสนับสนุนตัวเลือกของ บังคับ TLS ลิงก์การสื่อสารระหว่างเมลเซิร์ฟเวอร์จะถูกนำมาใช้โดยใช้โปรโตคอล TLS

การใช้โปรโตคอลการสื่อสารเมลผสมกัน - SMTP, TLS แบบฉวยโอกาส + บังคับ TLS

ตามค่าเริ่มต้น แต่ละเซิร์ฟเวอร์ Exchange ที่มีใบรับรองจะสนับสนุนตัวเลือก TLS ที่ฉวยโอกาส

เพื่อให้สามารถใช้ตัวเลือก บังคับ TLS เราจะต้องสร้างตัวเชื่อมต่ออีเมลเฉพาะ (หรืออัปเดตตัวเชื่อมต่อเมลที่มีอยู่) ที่จะ "บังคับใช้" การใช้ TLS

โดยส่วนใหญ่ ตัวเลือก บังคับ TLS จะไม่ถูกนำมาใช้กับการสื่อสารทุกประเภทด้วย เมลเซิร์ฟเวอร์ใดๆ แต่จะถูกนำไปใช้กับโดเมนเมลที่ระบุแทน

ในแผนภาพต่อไปนี้ เราจะเห็นแนวคิดของการใช้โปรโตคอลการสื่อสารเมลผสม - SMTP, TLS ที่ฉวยโอกาส + บังคับ TLS

เซิร์ฟเวอร์อีเมล Exchange จะพยายามเสนอตัวเลือกในการใช้ TLS เสมอ (TLS ที่ฉวยโอกาส) ในกรณีที่เซิร์ฟเวอร์อีเมลปลายทางไม่รองรับ TLS เซิร์ฟเวอร์อีเมล Exchange จะใช้การสื่อสารอีเมล SMTP มาตรฐานกับเซิร์ฟเวอร์อีเมลที่ไม่รองรับ TLS (domain-A.com)
เซิร์ฟเวอร์อีเมล Exchange จะพยายามเสนอตัวเลือกในการใช้ TLS เสมอ (TLS ที่ฉวยโอกาส) ในกรณีที่เมลเซิร์ฟเวอร์ปลายทางรองรับ TLS ช่องทางการสื่อสารเมลจะถูกนำมาใช้โดยใช้ TLS (domain-B.com)
เกี่ยวกับความสัมพันธ์กับ domain-C.com นั้น Exchange ใช้ตัวเชื่อมต่อเมลเฉพาะที่กำหนดค่าตัวเลือก ให้กับผู้ใช้ บังคับใช้ TLS การแลกเปลี่ยนจะตกลงที่จะส่งข้อความอีเมลไปยังผู้รับจาก domain-C.com เฉพาะในกรณีที่เซิร์ฟเวอร์อีเมลที่เป็นตัวแทนของ domain-C.com รองรับ TLS ด้วย

บทความถัดไป