ข้ามไปยังเนื้อหา
TESA Open Knowledge

TLS: ใบรับรอง ห่วงโซ่ความเชื่อถือ และการจับมือ

โมดูล 4 — เชื่อมต่อแพลตฟอร์ม IoT · สไลด์: slides.md · ภาพรวมโมดูล · หน้าหลักสูตร

เข้าใจว่า TLS ประกอบจากกุญแจคู่ ลายเซ็น และแฮช อ่านใบรับรอง ห่วงโซ่ความเชื่อถือ การจับมือ และ SNI ได้ แล้วบอกได้ว่า serverTLS บนพอร์ต 8884 ปกป้องอะไรและไม่ปกป้องอะไร

เป้าหมาย

หัวข้อที่มีชื่อว่า “เป้าหมาย”

เมื่อจบบทเรียนนี้ คุณจะ:

  1. อธิบายหน้าที่ของการเข้ารหัสด้วยกุญแจคู่ ลายเซ็น และแฮชใน TLS และบอกได้ว่าใบรับรองรับรองอะไร (ชื่อคู่กับกุญแจสาธารณะ ที่ CA เซ็นไว้) และไม่ได้รับรองอะไร
  2. เรียงการจับมือ TLS 1.2 สี่จังหวะตั้งแต่ TCP จนถึง MQTT CONNECT ได้ถูกลำดับ ชี้ได้ว่า SNI เดินไปก่อนการเข้ารหัส และบอกอาการเมื่อ sni_hostname ไม่ตรงกับชื่อ broker
  3. อธิบายว่าพอร์ต 8884 ถูกเลือกจาก tls_mode ไม่ใช่คีย์ port และทำไม MQTTs จากบอร์ดเข้า TESAIoT CE ที่ติดตั้งเองไม่ผ่าน
  4. กรอกตารางเทียบพอร์ต 1883 กับ 8884 ในบันทึกการเรียนจากสิ่งที่คนดักฟังเห็น และตอบได้โดยไม่เปิดสไลด์ว่า serverTLS พิสูจน์ช่องทางและเซิร์ฟเวอร์ แต่ไม่ได้พิสูจน์อุปกรณ์

ก่อนเริ่ม

หัวข้อที่มีชื่อว่า “ก่อนเริ่ม”

ทวนบทเรียน 4.4–4.6: ข้อมูลไหลครบสองทางแล้วผ่าน mqtt.* บนพอร์ต 1883 แต่ไหลแบบเปลือย สิ่งที่ต้องหยิบมาใช้ต่อคือ JSON ส่งแบน device_id ไม่เกิน 31 ตัวอักษร และค่าต้องเป็นตัวเลขถึงขึ้นกราฟ ก่อนจบบทเรียนนี้ ต้องมีค่าประจำตัวสี่ค่าของอุปกรณ์: device_id · api_key · mqtt_pass · ชื่อโฮสต์ของ broker เพิ่มอุปกรณ์ในบัญชี TESAIoT Platform ของคุณ แล้วอ่านสี่ค่านี้จากหน้าจัดการอุปกรณ์ของแพลตฟอร์ม (TESAIoT Community Edition ที่ติดตั้งเองใช้กับพอร์ต 1883 ในบทเรียน 4.4–4.6 ได้ แต่ใช้กับ MQTTs ของบทเรียน 4.7–4.9 ไม่ได้ เพราะเรื่อง root CA ในหัวข้อแนวคิด) ถ้าเรียนเป็นกลุ่ม ผู้จัดอาจเตรียมตัวตนไว้ให้ จดลงบันทึกการเรียนก่อนแตะโค้ดในบทเรียน 4.8

  • อุปกรณ์: บอร์ด Eva Kit หรือ TESAIoT Dev Kit ที่ลงเฟิร์มแวร์ MicroPython ของ BENTO แล้ว หรือ BENTO Emulator ใน BENTO IDE (บทเรียนนี้ไม่มีโค้ดให้รัน การต่อ TLS จริงเริ่มในบทเรียน 4.8 และต้องใช้บอร์ดจริงที่มีตัวตนจากแพลตฟอร์มแล้ว)
  • เรียนมาก่อน: บทเรียน 4.6 — ลงมือทำ: telemetry สองทาง

ดูของจริงก่อน

หัวข้อที่มีชื่อว่า “ดูของจริงก่อน”

ดูภาพแรกของสไลด์ซึ่งเทียบสิ่งที่เครื่องมือดักจับเห็นบนเครือข่ายเดียวกัน บนพอร์ต 1883 คนดักฟังอ่าน MQTT CONNECT ได้ทุกไบต์ ทั้ง username: team03 รหัสผ่านของอุปกรณ์ และ JSON ของค่าเซนเซอร์ บนพอร์ต 8884 เห็นแค่ TLS Application Data เป็นไบต์ที่อ่านไม่ออก ยาวเท่าเดิม เวลาเดิม แต่เนื้อในหายไป สิ่งเดียวที่ยังเห็นคือชื่อโฮสต์ปลายทาง บอร์ดเดิม เครือข่ายเดิม โค้ดเกือบเหมือนเดิม ต่างกันแค่ว่าเราเรียกโมดูลไหน

แนวคิด

หัวข้อที่มีชื่อว่า “แนวคิด”

พอร์ต 1883 ไม่ได้ “ปลอดภัยน้อยกว่า” มัน ไม่มีความปลอดภัยเลย ทั้งเรื่องเนื้อหาและเรื่องตัวตน ถ้าไม่เข้ารหัส ทุกคนในเครือข่ายเดียวกัน คืออุปกรณ์ของเรา สิ่งที่ 8884 เพิ่มเข้ามาคือสองอย่างพร้อมกัน: การเข้ารหัส และการรู้ว่ากำลังคุยกับใคร โมดูลก็เปลี่ยนด้วย จาก mqtt ที่เลือกโฮสต์และพอร์ตเองได้ เป็น tesaiot ที่ตั้งค่าคนละแบบและเลือกพอร์ตเองไม่ได้

TLS ประกอบจากสามชิ้น: เข้ารหัส = ปิดไม่ให้อ่าน (ล็อกด้วยกุญแจสาธารณะ มีแต่กุญแจส่วนตัวที่เปิดได้) · เซ็น = พิสูจน์ว่าใครเขียน (เซ็นด้วยกุญแจส่วนตัว ใครก็ตรวจได้ด้วยกุญแจสาธารณะ) · แฮช = จับได้ว่าถูกแก้ (เปลี่ยนตัวอักษรเดียว ค่าเปลี่ยนทั้งก้อน) ใบรับรองของเซิร์ฟเวอร์มีช่อง Subject, Public Key, Validity และ Issuer + Signature สิ่งที่ทำให้มันมีค่าคือลายเซ็นของ CA ท้ายใบ ใบรับรองแปลว่า “มีคนที่คุณเชื่ออยู่แล้ว ยืนยันว่ากุญแจนี้เป็นของชื่อนี้” ไม่มากกว่านั้น มันไม่ได้บอกว่าเจ้าของเป็นคนดี และเป็นข้อมูลสาธารณะที่ก๊อปได้ ห่วงโซ่เดินจาก leaf ที่ intermediate เซ็น ไปถึง root ที่เซ็นตัวเอง root คือจุดที่เรา “เลือกเชื่อ” ไว้ก่อน ถ้ากล่องกลางทางใส่ CA ของมันไว้ในเครื่องได้ มันก็ออกใบชื่อเดียวกันได้ รายชื่อ CA ที่เชื่อจึงสำคัญพอ ๆ กับการเข้ารหัส

การจับมือมีสี่จังหวะ: หนึ่ง TCP ต่อวงจร (ยังไม่เข้ารหัส) · สอง ClientHello บอกว่ารองรับอะไรและแนบชื่อโฮสต์ปลายทาง (SNI) · สาม เซิร์ฟเวอร์ยื่นใบรับรอง บอร์ดตรวจลายเซ็นย้อนขึ้นไปถึง root ที่มี แล้วแลกกุญแจลับของรอบนี้ · สี่ ตั้งแต่ Finished ทุกไบต์ถูกเข้ารหัส แล้ว MQTT CONNECT จึงเดินเข้าไปข้างใน เฟิร์มแวร์ของเราเจรจา TLS 1.2 ซึ่งใช้สองรอบไป-กลับ (TLS 1.3 เหลือรอบเดียว) บนบอร์ดที่ CPU ช้าจึงกินเวลาหลายวินาที โค้ดในบทเรียน 4.8 จึงต้องมีลูปรอ SNI คือชื่อที่เดินไปแบบเปิดเผย เซิร์ฟเวอร์ใช้มันหยิบใบรับรองใบที่ถูก sni_hostname จึงต้องเท่ากับชื่อ broker เป๊ะ ตั้งผิดแล้วอาการคือ ต่อไม่ติดโดยไม่มีข้อความอะไรเลย

บนบอร์ด TLS วิ่งบน CM33_NS คอร์เดียวกับที่รัน Python ส่วน CM55 ที่วาดจอไม่แตะเครือข่ายเลย ช่วงจับมือกินหน่วยความจำก้อนใหญ่ที่สุด จึงควรเรียก tesaiot.connect() ตอนต้นสคริปต์ขณะหน่วยความจำยังโล่ง root CA ของแพลตฟอร์มถูกคอมไพล์ติดมากับเฟิร์มแวร์ ไม่มี API ให้เปลี่ยนตอนรัน ส่วนพอร์ตเป็นผลลัพธ์ของ tls_mode ไม่ใช่ค่าที่รับเข้ามา: server_tls → 8884 (เส้นทางของชุดบทเรียนนี้) และ mutual_tls → 8883 (ต้องมีใบรับรองของอุปกรณ์) ตั้งคีย์ port ได้โดยไม่ error แต่มันเปลี่ยนแค่ป้ายที่แสดง MQTTs จากบอร์ดจึงเข้า CE ที่ติดตั้งเองไม่ผ่าน เพราะสคริปต์ติดตั้งของ CE สุ่ม root CA ใหม่ทุกครั้ง บอร์ดไม่มีทางรู้จัก ถ้าลองแล้วต่อไม่ติด ไม่ต้องดีบักโค้ด ให้กลับไปใช้โฮสต์ของแพลตฟอร์ม TESAIoT ที่ได้มาพร้อมตัวตนของอุปกรณ์

serverTLS พิสูจน์ได้ข้างเดียว: ข้อมูลถูกเข้ารหัสตลอดทาง และเรารู้ว่าเซิร์ฟเวอร์เป็นตัวจริงเพราะมันยื่นใบที่ CA เซ็นและชื่อตรงกับ SNI แต่เซิร์ฟเวอร์ ไม่รู้ว่าอุปกรณ์ตัวไหนพูด รู้แค่ว่ามีคนที่รู้ device_id กับ mqtt_pass ที่ถูกต้อง ความลับชนิดนี้คัดลอกได้ การพิสูจน์อุปกรณ์ต้องใช้ mTLS ที่มีกุญแจส่วนตัวอยู่ในตัวอุปกรณ์จริง ๆ ก่อนเริ่มโค้ด บอร์ดทุกตัวยังต้องมี device_id ของตัวเอง เพราะบอร์ดออกจากโรงงานด้วยค่าเริ่มต้นเดียวกันหมด ถ้าหลายบอร์ดใช้ซ้ำ broker จะเตะตัวเก่าออกวนไปเรื่อย ๆ ทั้งที่โค้ดทุกตัวถูก

ตัวอย่างสมบูรณ์

หัวข้อที่มีชื่อว่า “ตัวอย่างสมบูรณ์”

สไลด์ของบทเรียนนี้อ้างถึงไฟล์ที่อยู่ในบทเรียนอื่นด้วย:

เช็กความเข้าใจ

หัวข้อที่มีชื่อว่า “เช็กความเข้าใจ”

คำถามชุดเดียวกันอยู่ใน quiz.yaml สำหรับระบบที่ตรวจอัตโนมัติ

  1. ใบรับรอง X.509 ของ broker ที่ CA เซ็นไว้ รับรองอะไรกันแน่ (เลือกหนึ่งข้อ · เป้าหมายข้อ 1)

    • ก) กุญแจสาธารณะในใบนี้เป็นของชื่อโฮสต์นี้จริง โดยมี CA ที่เราเชื่ออยู่แล้วเซ็นยืนยัน
    • ข) เจ้าของเซิร์ฟเวอร์เป็นคนดีและเก็บข้อมูลของเราอย่างปลอดภัย
    • ค) ใบรับรองเป็นความลับ ถ้าใครก๊อปไปได้จะปลอมเป็นเซิร์ฟเวอร์ได้ทันที
    • ง) ข้อมูลที่ส่งผ่านเซิร์ฟเวอร์นี้ถูกต้องเสมอ
    เฉลย

    ก — ใบรับรองพิสูจน์แค่ “ชื่อคู่กับกุญแจ” และมีค่าเพราะลายเซ็นของ CA ท้ายใบ ตัวใบเป็นข้อมูลสาธารณะที่ก๊อปได้ และไม่ได้บอกว่าเจ้าของดีหรือเก็บข้อมูลดี

  2. เรียงจังหวะการจับมือ TLS 1.2 ระหว่างบอร์ดกับ broker ตั้งแต่ต้นจนข้อมูล MQTT เริ่มเดิน (เรียงลำดับ · เป้าหมายข้อ 2)

    • ก) ClientHello บอกว่ารองรับอะไร และแนบชื่อโฮสต์ปลายทาง (SNI)
    • ข) ตั้งแต่ Finished ทุกไบต์ถูกเข้ารหัส แล้ว MQTT CONNECT เดินเข้าไปข้างใน
    • ค) TCP ต่อวงจร ยังไม่มีอะไรเข้ารหัส
    • ง) เซิร์ฟเวอร์ยื่นใบรับรอง บอร์ดตรวจลายเซ็นย้อนขึ้นไปถึง root แล้วแลกกุญแจลับของรอบนี้
    เฉลย

    ค → ก → ง → ข — TCP ต้องมาก่อน แล้ว ClientHello จึงเดินพร้อม SNI แบบยังไม่เข้ารหัส เซิร์ฟเวอร์ยื่นใบที่ตรงกับชื่อนั้น บอร์ดตรวจถึง root แล้วแลกกุญแจ หลัง Finished จึงเข้ารหัสทุกไบต์ MQTT ไม่รู้เรื่อง TLS เลย มันแค่ถูกวางไว้ข้างในท่อที่สร้างเสร็จแล้ว

  3. ทีมหนึ่งตั้ง sni_hostname สะกดต่างจากชื่อ broker ไปหนึ่งตัวอักษร จะเห็นอาการใด (เลือกหนึ่งข้อ · เป้าหมายข้อ 2)

    • ก) ต่อไม่ติดโดยไม่มีข้อความอะไรเลย
    • ข) ขึ้น error ว่าชื่อโฮสต์ผิดพร้อมบอกชื่อที่ถูก
    • ค) ต่อติดแต่ข้อมูลเดินแบบไม่เข้ารหัส
    • ง) บอร์ดสลับไปใช้พอร์ต 8883 เอง
    เฉลย

    ก — SNI คือชื่อที่เซิร์ฟเวอร์ใช้หยิบใบรับรองมายื่น ชื่อผิดก็ได้ใบผิด ตรวจไม่ผ่าน และล้มเงียบ ไม่ใช่ error ที่บอกว่าชื่อผิด

  4. ข้อใดถูกเกี่ยวกับพอร์ตและ root CA ของเส้นทาง tesaiot เลือกทุกข้อที่ถูก (เลือกได้หลายข้อ · เป้าหมายข้อ 3)

    • ก) พอร์ตที่ต่อจริงถูกเลือกจาก tls_mode โดย server_tls ได้ 8884
    • ข) ตั้งคีย์ port เป็น 1883 แล้วบอร์ดจะต่อพอร์ต 1883 แบบไม่เข้ารหัส
    • ค) MQTTs เข้า CE ที่ติดตั้งเองไม่ผ่าน เพราะ CE สุ่ม root CA ใหม่ทุกการติดตั้ง แต่บอร์ดรู้จักแค่ root ที่คอมไพล์มากับเฟิร์มแวร์
    • ง) เปลี่ยน root CA บนบอร์ดได้ด้วยการเรียก API ตอนรัน
    เฉลย

    ก, ค — พอร์ตเป็นผลลัพธ์ของ tls_mode คีย์ port เปลี่ยนแค่ป้ายที่แสดง และ root CA ถูกคอมไพล์ติดเฟิร์มแวร์ ไม่มี API ให้เปลี่ยนตอนรัน จะใช้ CE ต้อง build เฟิร์มแวร์ใหม่พร้อม CA ของ CE ชุดนั้น

  5. serverTLS ที่ใช้ในชุดบทเรียนนี้ทำอะไรได้บ้าง เลือกทุกข้อที่ถูก (เลือกได้หลายข้อ · เป้าหมายข้อ 4)

    • ก) เข้ารหัสข้อมูลตลอดทาง คนกลางอ่านไม่ได้และแก้ระหว่างทางโดยเราไม่รู้ไม่ได้
    • ข) พิสูจน์ว่าเซิร์ฟเวอร์เป็นตัวจริง เพราะยื่นใบที่ CA เซ็นและชื่อตรงกับ SNI
    • ค) พิสูจน์ว่าอุปกรณ์ตัวไหนเป็นคนส่ง แม้มีคนก๊อป mqtt_pass ไปได้
    • ง) ซ่อนชื่อโฮสต์ปลายทางจากคนดักฟัง
    เฉลย

    ก, ข — serverTLS พิสูจน์ช่องทางและเซิร์ฟเวอร์ ไม่ได้พิสูจน์อุปกรณ์ ตัวตนอุปกรณ์มาจากรหัสผ่านที่ก๊อปได้ และ SNI ยังเดินแบบเปิดเผย คนดักฟังจึงเห็นว่าเราคุยกับใคร แต่ไม่เห็นว่าคุยว่าอะไร

แล็บ

หัวข้อที่มีชื่อว่า “แล็บ”

แล็บบนกระดาษ (ราว 15 นาที) จดทุกข้อลงบันทึกการเรียน

  • จดค่าประจำตัวสี่ค่าจากหน้าจัดการอุปกรณ์ของแพลตฟอร์ม (device_id · api_key · mqtt_pass · ชื่อโฮสต์ broker) และนับว่า device_id ไม่เกิน 31 ตัวอักษร
  • เปิดดูใบรับรองของเว็บไซต์ HTTPS สักแห่งจากเบราว์เซอร์ จด Subject, Issuer, Validity และห่วงโซ่ root → intermediate → leaf ที่เห็น
  • วาดการจับมือสี่จังหวะ ระบุว่าจังหวะไหนยังไม่เข้ารหัส SNI เดินไปตอนไหน และ MQTT CONNECT เข้าไปตอนไหน
  • กรอกตาราง 1883 กับ 8884 (การเข้ารหัส · ตัวตนของ broker · ตัวตนของอุปกรณ์ · ปลายทาง · โมดูล) จากภาพสิ่งที่คนดักฟังเห็น ไม่ใช่ลอกตารางในสไลด์
  • เขียนหนึ่งประโยคด้วยคำของตัวเอง: serverTLS พิสูจน์อะไร และไม่ได้พิสูจน์อะไร

ไปต่อ

หัวข้อที่มีชื่อว่า “ไปต่อ”

บทเรียน 4.8 เปิดโมดูล tesaiot ทีละฟังก์ชัน: ตั้งตัวตนด้วย config_set() สั่ง connect() แล้ววนรอ is_connected() ก่อน publish() ถ้าอยากเข้าใจเร็วขึ้น ดูคลิปในสไลด์: PKI Bootcamp (ห่วงโซ่ใบรับรอง ราว 4 นาที) และคลิปภาษาไทยของ SaKKo sama เรื่อง SSL/TLS/HTTPS

บทเรียนถัดไป: บทเรียน 4.8 — โมดูล tesaiot: MQTTs สู่แพลตฟอร์ม

สะท้อนคิด

หัวข้อที่มีชื่อว่า “สะท้อนคิด”
  • ถ้ามีกล่องกลางทางที่ใส่ CA ของมันไว้ในเครื่องเรา เราจะรู้ตัวได้อย่างไร และทำไมรายชื่อ CA ที่เชื่อถึงสำคัญพอ ๆ กับการเข้ารหัส
  • ถ้ามีคนได้ mqtt_pass ของอุปกรณ์เราไป serverTLS ช่วยอะไรได้บ้าง และช่วยอะไรไม่ได้
  • ค่าที่ตั้งได้ไม่ได้แปลว่าค่านั้นมีผล คุณเคยเจอระบบอื่นที่เป็นแบบคีย์ port นี้ไหม

คำถามทบทวน

ลองตอบเองก่อน แล้วค่อยเปิดดูเฉลย

  1. ใบรับรอง X.509 ของ broker ที่ CA เซ็นไว้ รับรองอะไรกันแน่ (เป้าหมายข้อ 1)

    1. กุญแจสาธารณะในใบนี้เป็นของชื่อโฮสต์นี้จริง โดยมี CA ที่เราเชื่ออยู่แล้วเซ็นยืนยัน
    2. เจ้าของเซิร์ฟเวอร์เป็นคนดีและเก็บข้อมูลของเราอย่างปลอดภัย
    3. ใบรับรองเป็นความลับ ถ้าใครก๊อปไปได้จะปลอมเป็นเซิร์ฟเวอร์ได้ทันที
    4. ข้อมูลที่ส่งผ่านเซิร์ฟเวอร์นี้ถูกต้องเสมอ
    ดูเฉลย

    คำตอบ: A. กุญแจสาธารณะในใบนี้เป็นของชื่อโฮสต์นี้จริง โดยมี CA ที่เราเชื่ออยู่แล้วเซ็นยืนยัน

    ใบรับรองพิสูจน์แค่ "ชื่อคู่กับกุญแจ" และมีค่าเพราะลายเซ็นของ CA ท้ายใบ ตัวใบเป็นข้อมูลสาธารณะที่ก๊อปได้ และไม่ได้บอกว่าเจ้าของดีหรือเก็บข้อมูลดี

  2. เรียงจังหวะการจับมือ TLS 1.2 ระหว่างบอร์ดกับ broker ตั้งแต่ต้นจนข้อมูล MQTT เริ่มเดิน (เป้าหมายข้อ 2)

    1. ClientHello บอกว่ารองรับอะไร และแนบชื่อโฮสต์ปลายทาง (SNI)
    2. ตั้งแต่ Finished ทุกไบต์ถูกเข้ารหัส แล้ว MQTT CONNECT เดินเข้าไปข้างใน
    3. TCP ต่อวงจร ยังไม่มีอะไรเข้ารหัส
    4. เซิร์ฟเวอร์ยื่นใบรับรอง บอร์ดตรวจลายเซ็นย้อนขึ้นไปถึง root แล้วแลกกุญแจลับของรอบนี้
    ดูเฉลย

    ลำดับที่ถูก: C. TCP ต่อวงจร ยังไม่มีอะไรเข้ารหัส → A. ClientHello บอกว่ารองรับอะไร และแนบชื่อโฮสต์ปลายทาง (SNI) → D. เซิร์ฟเวอร์ยื่นใบรับรอง บอร์ดตรวจลายเซ็นย้อนขึ้นไปถึง root แล้วแลกกุญแจลับของรอบนี้ → B. ตั้งแต่ Finished ทุกไบต์ถูกเข้ารหัส แล้ว MQTT CONNECT เดินเข้าไปข้างใน

    TCP ต้องมาก่อน แล้ว ClientHello จึงเดินพร้อม SNI แบบยังไม่เข้ารหัส เซิร์ฟเวอร์ยื่นใบที่ตรงกับชื่อนั้น บอร์ดตรวจถึง root แล้วแลกกุญแจ หลัง Finished จึงเข้ารหัสทุกไบต์ MQTT ไม่รู้เรื่อง TLS เลย มันแค่ถูกวางไว้ข้างในท่อที่สร้างเสร็จแล้ว

  3. ทีมหนึ่งตั้ง `sni_hostname` สะกดต่างจากชื่อ broker ไปหนึ่งตัวอักษร จะเห็นอาการใด (เป้าหมายข้อ 2)

    1. ต่อไม่ติดโดยไม่มีข้อความอะไรเลย
    2. ขึ้น error ว่าชื่อโฮสต์ผิดพร้อมบอกชื่อที่ถูก
    3. ต่อติดแต่ข้อมูลเดินแบบไม่เข้ารหัส
    4. บอร์ดสลับไปใช้พอร์ต 8883 เอง
    ดูเฉลย

    คำตอบ: A. ต่อไม่ติดโดยไม่มีข้อความอะไรเลย

    SNI คือชื่อที่เซิร์ฟเวอร์ใช้หยิบใบรับรองมายื่น ชื่อผิดก็ได้ใบผิด ตรวจไม่ผ่าน และล้มเงียบ ไม่ใช่ error ที่บอกว่าชื่อผิด

  4. ข้อใดถูกเกี่ยวกับพอร์ตและ root CA ของเส้นทาง `tesaiot` เลือกทุกข้อที่ถูก (เป้าหมายข้อ 3)

    1. พอร์ตที่ต่อจริงถูกเลือกจาก `tls_mode` โดย `server_tls` ได้ 8884
    2. ตั้งคีย์ `port` เป็น 1883 แล้วบอร์ดจะต่อพอร์ต 1883 แบบไม่เข้ารหัส
    3. MQTTs เข้า CE ที่ติดตั้งเองไม่ผ่าน เพราะ CE สุ่ม root CA ใหม่ทุกการติดตั้ง แต่บอร์ดรู้จักแค่ root ที่คอมไพล์มากับเฟิร์มแวร์
    4. เปลี่ยน root CA บนบอร์ดได้ด้วยการเรียก API ตอนรัน
    ดูเฉลย

    คำตอบ: A. พอร์ตที่ต่อจริงถูกเลือกจาก `tls_mode` โดย `server_tls` ได้ 8884 · C. MQTTs เข้า CE ที่ติดตั้งเองไม่ผ่าน เพราะ CE สุ่ม root CA ใหม่ทุกการติดตั้ง แต่บอร์ดรู้จักแค่ root ที่คอมไพล์มากับเฟิร์มแวร์

    พอร์ตเป็นผลลัพธ์ของ `tls_mode` คีย์ `port` เปลี่ยนแค่ป้ายที่แสดง และ root CA ถูกคอมไพล์ติดเฟิร์มแวร์ ไม่มี API ให้เปลี่ยนตอนรัน จะใช้ CE ต้อง build เฟิร์มแวร์ใหม่พร้อม CA ของ CE ชุดนั้น

  5. serverTLS ที่ใช้ในชุดบทเรียนนี้ทำอะไรได้บ้าง เลือกทุกข้อที่ถูก (เป้าหมายข้อ 4)

    1. เข้ารหัสข้อมูลตลอดทาง คนกลางอ่านไม่ได้และแก้ระหว่างทางโดยเราไม่รู้ไม่ได้
    2. พิสูจน์ว่าเซิร์ฟเวอร์เป็นตัวจริง เพราะยื่นใบที่ CA เซ็นและชื่อตรงกับ SNI
    3. พิสูจน์ว่าอุปกรณ์ตัวไหนเป็นคนส่ง แม้มีคนก๊อป `mqtt_pass` ไปได้
    4. ซ่อนชื่อโฮสต์ปลายทางจากคนดักฟัง
    ดูเฉลย

    คำตอบ: A. เข้ารหัสข้อมูลตลอดทาง คนกลางอ่านไม่ได้และแก้ระหว่างทางโดยเราไม่รู้ไม่ได้ · B. พิสูจน์ว่าเซิร์ฟเวอร์เป็นตัวจริง เพราะยื่นใบที่ CA เซ็นและชื่อตรงกับ SNI

    serverTLS พิสูจน์ช่องทางและเซิร์ฟเวอร์ ไม่ได้พิสูจน์อุปกรณ์ ตัวตนอุปกรณ์มาจากรหัสผ่านที่ก๊อปได้ และ SNI ยังเดินแบบเปิดเผย คนดักฟังจึงเห็นว่าเราคุยกับใคร แต่ไม่เห็นว่าคุยว่าอะไร

อ้างอิงบทเรียนนี้

ถ้านำบทเรียนนี้ไปสอน ทำสไลด์ หรือทำเอกสารต่อ ให้อ้างอิงด้วยข้อความนี้ ถ้าดัดแปลงเนื้อหา ให้เติม (ดัดแปลง)ต่อท้ายชื่อบทเรียน

"TLS: ใบรับรอง ห่วงโซ่ความเชื่อถือ และการจับมือ" จาก TESA Open Knowledge โดยสมาคมสมองกลฝังตัวไทย (Thai Embedded Systems Association: TESA) https://github.com/tesaiot/tesa-qualification-program สัญญาอนุญาต CC BY-NC 4.0

ข้อความอ้างอิงภาษาอังกฤษ: "TLS: certificates, the chain of trust and the handshake" from TESA Open Knowledge by the Thai Embedded Systems Association (TESA), https://github.com/tesaiot/tesa-qualification-program, licensed under CC BY-NC 4.0

ลิงก์บทเรียน: https://tesaiot.github.io/tesa-qualification-program/courses/aiot-micropython/m04-iot-connectivity/l07-tls-concepts/

บทเรียนนี้ดัดแปลงจากต้นฉบับด้านล่าง เมื่ออ้างอิงให้คงเครดิตต้นฉบับไว้ด้วย
https://github.com/Advance-Innovation-Centre-AIC/embedded-systems-for-aiot-developer/blob/a80bbe88a34bcb9bb8d991f42f9252b77cdab079/session-11.html (slides 1–18)

วิธีอ้างอิง TESA ฉบับเต็ม

TESA Open Knowledge · © 2026 สมาคมสมองกลฝังตัวไทย (TESA) · CC BY-NC 4.0

เนื้อหาเผยแพร่ภายใต้ CC BY-NC 4.0 นำไปใช้ต่อในงานที่ไม่ใช่เพื่อการค้าได้ โปรดอ้างอิงสมาคมสมองกลฝังตัวไทย (TESA) ทุกครั้ง · วิธีอ้างอิง TESA