เวอร์ชัน TLS ชุดรหัสลับ และการรักษาความลับล่วงหน้าอย่างสมบูรณ์
กำหนดค่า TLS 1.2/1.3 เลือกชุดรหัสลับที่แข็งแกร่ง และเปิดใช้การรักษาความลับล่วงหน้าอย่างสมบูรณ์ เพื่อให้ไม่สามารถถอดรหัสทราฟฟิกที่บันทึกไว้ย้อนหลังได้
เวอร์ชัน TLS ชุดรหัสลับ และการรักษาความลับล่วงหน้าอย่างสมบูรณ์ เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
ภาพรวมโพรโทคอล TLS
TLS (Transport Layer Security) คือโพรโทคอลการเข้ารหัสที่ใช้รักษาความปลอดภัยให้การสื่อสารทางอินเทอร์เน็ตส่วนใหญ่ — HTTPS, SMTPS, IMAPS, LDAPS และ VPN ล้วนพึ่งพา TLS โดย TLS มีคุณสมบัติด้านความปลอดภัยสามประการ ได้แก่ การรักษาความลับ (การเข้ารหัสป้องกันการดักฟัง) ความถูกต้องครบถ้วน (MAC ป้องกันการแก้ไขข้อมูล) และ การพิสูจน์ตัวตน (ใบรับรองใช้ยืนยันตัวตนของเซิร์ฟเวอร์) TLS พัฒนาต่อยอดมาจาก SSL (Secure Sockets Layer) ซึ่งเลิกใช้แล้วในปัจจุบัน เวอร์ชันปัจจุบันคือ TLS 1.2 (มีการใช้งานอย่างแพร่หลาย) และ TLS 1.3 (เร็วกว่าและปลอดภัยกว่า โดยแนะนำให้ใช้กับการติดตั้งระบบใหม่ทั้งหมด)
ประวัติเวอร์ชัน TLS และเวอร์ชันที่เลิกใช้
TLS ผ่านการพัฒนามาหลายเวอร์ชัน โดยเวอร์ชันเก่ามีช่องโหว่ร้ายแรง SSL 2.0/3.0: เลิกใช้แล้ว และมีช่องโหว่ต่อการโจมตี POODLE และ DROWN TLS 1.0: NIST และ PCI-DSS เลิกใช้ในปี 2020 (มีช่องโหว่ต่อ BEAST และ POODLE เมื่อใช้กับรหัสลับแบบบล็อก) TLS 1.1: เลิกใช้พร้อมกับ TLS 1.0 TLS 1.2: มาตรฐานขั้นต่ำในปัจจุบัน และปลอดภัยเมื่อกำหนดค่าด้วยชุดรหัสลับที่แข็งแกร่งอย่างเหมาะสม TLS 1.3: เปิดตัวในปี 2018 นำอัลกอริทึมที่อ่อนแอทั้งหมดออก บังคับใช้ความลับส่งต่อ รองรับ handshake ที่เร็วขึ้นอย่างมาก (1-RTT แทน 2-RTT) และป้องกันการโจมตีแบบลดระดับเวอร์ชัน โดย PCI-DSS 4.0 กำหนดให้ใช้ TLS 1.2 เป็นอย่างต่ำ และแนะนำ TLS 1.3
# TLS version timeline
SSL 2.0 1995 DEPRECATED (DROWN)
SSL 3.0 1996 DEPRECATED (POODLE)
TLS 1.0 1999 DEPRECATED 2020 (BEAST, POODLE)
TLS 1.1 2006 DEPRECATED 2020 (no improvements over 1.0)
TLS 1.2 2008 MINIMUM STANDARD (strong ciphers required)
TLS 1.3 2018 RECOMMENDED (mandatory PFS, faster, secure)
# Check which TLS versions a server supports
nmap --script ssl-enum-ciphers -p 443 example.com
# Or:
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3ชุดรหัสลับ
ชุดรหัสลับ คือกลุ่มอัลกอริทึมการเข้ารหัสที่ทำงานร่วมกันในเซสชัน TLS ชุดรหัสลับแต่ละชุดระบุสิ่งต่อไปนี้: อัลกอริทึมการแลกเปลี่ยนกุญแจ (วิธีสร้างกุญแจเซสชัน) อัลกอริทึมการพิสูจน์ตัวตน (วิธียืนยันเซิร์ฟเวอร์) อัลกอริทึมการเข้ารหัสข้อมูลจำนวนมาก (สิ่งที่ใช้เข้ารหัสข้อมูล) และอัลกอริทึม รหัสยืนยันความถูกต้องของข้อความ (MAC) (วิธีตรวจสอบความถูกต้องครบถ้วน) Client และ Server จะเจรจาเลือกชุดรหัสลับที่จะใช้ระหว่าง TLS handshake โดย Server จะเลือกชุดที่แข็งแกร่งที่สุดจากชุดที่ทั้งสองฝ่ายรองรับ
# TLS cipher suite naming format (TLS 1.2)
# TLS_[KeyExchange]_WITH_[Cipher]_[MAC]
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
ECDHE = Elliptic Curve Diffie-Hellman Ephemeral
RSA = Server certificate authentication
AES_256_GCM = 256-bit AES in Galois/Counter Mode
SHA384 = HMAC with SHA-384 for integrity
# TLS 1.3 simplified format (fewer components)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256อัลกอริทึมการแลกเปลี่ยนกุญแจ
ระยะการแลกเปลี่ยนกุญแจจะสร้างกุญแจเซสชันโดยไม่ส่งกุญแจนั้นออกไป การแลกเปลี่ยนกุญแจ RSA (TLS 1.2): Client เข้ารหัสความลับก่อนใช้งานด้วยกุญแจสาธารณะของ Server — หากกุญแจส่วนตัวถูกโจมตีในภายหลัง เซสชันในอดีตทั้งหมดจะถูกถอดรหัสได้ DHE (Diffie-Hellman Ephemeral): สร้างคู่กุญแจใหม่สำหรับแต่ละเซสชัน ให้ความลับส่งต่อ แต่ทำงานช้า ECDHE (Elliptic Curve DHE): ให้ความลับส่งต่อเช่นเดียวกับ DHE แต่ใช้ขนาดกุญแจเล็กกว่าและมีประสิทธิภาพดีกว่า จึงเป็นวิธีแลกเปลี่ยนกุญแจที่แนะนำสำหรับทั้ง TLS 1.2 และ TLS 1.3 โดย TLS 1.3 กำหนดให้ใช้ ECDHE หรือ DHE และนำการแลกเปลี่ยนกุญแจ RSA ออกทั้งหมด
ความลับส่งต่ออย่างสมบูรณ์แบบ (PFS)
ความลับส่งต่ออย่างสมบูรณ์แบบ (PFS) ช่วยให้มั่นใจว่า แม้กุญแจส่วนตัวระยะยาวของ Server จะถูกโจมตีในภายหลัง ก็จะไม่สามารถถอดรหัสเซสชันที่บันทึกไว้ก่อนหน้านั้นได้ PFS ทำได้โดยใช้ การแลกเปลี่ยนกุญแจชั่วคราว (ECDHE หรือ DHE) ซึ่งสร้างคู่กุญแจชั่วคราวใหม่สำหรับแต่ละเซสชันและทิ้งหลังใช้งาน หากไม่มี PFS (การแลกเปลี่ยนกุญแจ RSA) Attacker สามารถบันทึกเซสชัน TLS ที่เข้ารหัสทั้งหมดในวันนี้ แล้วถอดรหัสย้อนหลังได้เมื่อได้กุญแจส่วนตัวมาในภายหลัง กลยุทธ์การสอดแนมของ NSA ที่เรียกว่า ‘เก็บรวบรวมตอนนี้ ถอดรหัสภายหลัง’ ตั้งอยู่บนสมมติฐานว่าเป้าหมายจะเปลี่ยนไปใช้กุญแจที่แข็งแกร่งขึ้นในอนาคต หรือคอมพิวเตอร์ควอนตัมจะทำลายกุญแจที่ใช้อยู่ในปัจจุบันได้
# Cipher suites WITH perfect forward secrecy
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 # Good
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 # Good
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 # OK (slower)
# Cipher suites WITHOUT perfect forward secrecy
TLS_RSA_WITH_AES_256_CBC_SHA256 # NO PFS - avoid
TLS_RSA_WITH_3DES_EDE_CBC_SHA # NO PFS + weak
# Key: look for ECDHE or DHE prefix
# RSA alone as key exchange = no forward secrecyอัลกอริทึมรหัสลับที่อ่อนแอซึ่งควรหลีกเลี่ยง
องค์ประกอบรหัสลับรุ่นเก่าหลายรายการถูกทำลายด้านความปลอดภัยเชิงการเข้ารหัสแล้ว และต้องปิดใช้งาน รหัสลับ NULL: ไม่มีการเข้ารหัสเลย รหัสลับระดับส่งออก (การโจมตี FREAK): ถูกทำให้อ่อนแอลงโดยเจตนาเพื่อให้เป็นไปตามกฎระเบียบการส่งออกของ US ในทศวรรษ 1990 RC4: รหัสลับแบบสตรีมที่มีความเอนเอียงทางสถิติและถูกใช้ประโยชน์ในการโจมตี DES และ 3DES: รหัสลับแบบบล็อกที่มีขนาดบล็อกเล็กเกินไป (การโจมตี SWEET32) หรือมีความยาวกุญแจไม่เพียงพอ MD5 และ SHA-1 สำหรับ MAC: มีช่องโหว่ด้านการชนกัน รหัสลับแบบไม่ระบุตัวตน (aNULL): ไม่มีการพิสูจน์ตัวตนของ Server การกำหนดค่า TLS สมัยใหม่ควรอนุญาตให้ใช้เฉพาะ AES-GCM, ChaCha20-Poly1305, AES-CCM เป็นรหัสลับสำหรับการเข้ารหัสข้อมูลจำนวนมาก
# nginx: disable weak ciphers, enforce strong only
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:
ECDHE-RSA-CHACHA20-POLY1305:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;
# Explicitly disable weak ciphers in Apache
SSLCipherSuite 'HIGH:!aNULL:!MD5:!3DES:!RC4:!EXPORT'การปรับปรุงใน TLS 1.3
TLS 1.3 ปรับปรุงความปลอดภัยจาก TLS 1.2 อย่างมีนัยสำคัญหลายประการ บังคับใช้ PFS: นำการแลกเปลี่ยนกุญแจ RSA ออก โดยทุกเซสชันใช้ ECDHE หรือ DHE ชุดรหัสลับน้อยลง: อนุญาตเฉพาะชุดรหัสลับ AEAD จำนวน 5 ชุด จึงไม่สามารถเจรจาใช้รหัสลับที่อ่อนแอได้ handshake เร็วขึ้น: ใช้การเดินทางไปกลับ 1 รอบ (1-RTT) เทียบกับ 2-RTT ใน TLS 1.2 และใช้ 0-RTT เพื่อกลับมาใช้เซสชันเดิม (แต่ 0-RTT ต้องคำนึงถึงการโจมตีแบบเล่นซ้ำ) handshake ที่เข้ารหัส: ใบรับรองของ Server ถูกเข้ารหัสระหว่าง handshake ทำให้ผู้สังเกตการณ์แบบไม่แทรกแซงไม่สามารถระบุได้ว่า Client กำลังเชื่อมต่อไปยังเว็บไซต์ใดจากใบรับรองที่ใช้
# TLS 1.3 handshake (simplified)
Client -> Server: ClientHello (supported ciphers, key shares)
Server -> Client: ServerHello (chosen cipher, key share)
{EncryptedExtensions}
{Certificate}
{CertificateVerify}
{Finished}
Client -> Server: {Finished}
# Both sides now have session keys
# Total: 1 round-trip before application data
# (TLS 1.2 required 2 round trips)
# Note: {} = encrypted (cert is hidden from observers)การโจมตีแบบลดระดับเวอร์ชันและ POODLE
การโจมตีแบบลดระดับเวอร์ชันหลอกให้ Server และ Client TLS ใช้เวอร์ชัน TLS หรือชุดรหัสลับที่เก่ากว่าและอ่อนแอกว่าที่ทั้งสองฝ่ายรองรับ POODLE (Padding Oracle On Downgraded Legacy Encryption) ใช้ประโยชน์จากข้อเท็จจริงที่การใช้งาน TLS จะ fallback ไปยัง SSL 3.0 เมื่อเกิดข้อผิดพลาดในการเชื่อมต่อ วิธีบรรเทาคือปิดใช้งาน SSL 3.0 FREAK และ Logjam ใช้ประโยชน์จากรหัสลับระดับส่งออก TLS_FALLBACK_SCSV คือชุดรหัสลับเทียมที่ Client ใส่ไว้เพื่อส่งสัญญาณว่า ‘นี่ไม่ใช่เวอร์ชันที่ต้องการ’ — หาก Server พบสัญญาณนี้และรองรับเวอร์ชันที่สูงกว่า ก็จะยกเลิกความพยายามลดระดับเวอร์ชัน
การตรวจสอบและการตรึงใบรับรอง
การพิสูจน์ตัวตนของ Server ด้วย TLS อาศัยการที่ Client ตรวจสอบสายโซ่ใบรับรองย้อนกลับไปยัง CA รากที่เชื่อถือได้ การตรวจสอบสำคัญ ได้แก่ วันหมดอายุ (ใบรับรองต้องอยู่ภายในช่วงเวลาที่มีผล) การเพิกถอน (การตรวจสอบ CRL หรือ OCSP ยืนยันว่าใบรับรองยังไม่ถูกเพิกถอน) ชื่อโฮสต์ (SAN หรือ CN ต้องตรงกับโดเมนที่กำลังเชื่อมต่อ) และ สายโซ่ลายเซ็น (ลายเซ็นของ CA ระดับกลางและ CA รากถูกต้อง) Certificate Transparency (CT) กำหนดให้ใบรับรองที่ได้รับความเชื่อถือจากสาธารณะทั้งหมดต้องถูกบันทึกในบันทึก CT ที่เพิ่มข้อมูลได้อย่างเดียว ทำให้ตรวจพบใบรับรองที่ออกอย่างไม่ถูกต้องได้ภายในไม่กี่นาทีหลังการออกใบรับรอง
# Check TLS certificate details
openssl s_client -connect example.com:443 \
-showcerts 2>/dev/null | openssl x509 -noout \
-text | grep -E 'Subject:|Issuer:|Not After:|SAN'
# Verify certificate chain
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
server.crt
# Check OCSP status
openssl ocsp -issuer intermediate.crt \
-cert server.crt \
-url http://ocsp.ca.example.com \
-text -noverifySSL Labs และการทดสอบการกำหนดค่า
Qualys SSL Labs (ssllabs.com/ssltest) เป็นเครื่องมือมาตรฐานสูงสุดสำหรับประเมินการกำหนดค่า TLS ของเว็บ Server เครื่องมือนี้ให้คะแนน Server ตั้งแต่ A+ (ยอดเยี่ยม) ถึง F (มีปัญหาร้ายแรง) โดยพิจารณาจากเวอร์ชัน TLS ที่รองรับ ความแข็งแกร่งของชุดรหัสลับ ความถูกต้องของใบรับรอง การกำหนดค่า HSTS การรองรับความลับส่งต่อ และความต้านทานต่อการโจมตีที่ทราบแล้ว การได้คะแนน A+ ต้องมี TLS 1.2 ขึ้นไปเท่านั้น ใช้รหัสลับ ECDHE ทั้งหมด มีใบรับรองที่ถูกต้อง และใช้ HSTS พร้อม preload องค์กรควรเรียกใช้การทดสอบ SSL Labs หลังการกำหนดค่าเริ่มต้น และเรียกใช้อีกครั้งหลังการเปลี่ยนแปลงใด ๆ กับชุดซอฟต์แวร์ TLS กรอบการปฏิบัติตามข้อกำหนดหลายประเภท (PCI-DSS) กำหนดให้ประเมินการกำหนดค่า TLS เป็นระยะ
แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการใบรับรอง TLS
ใบรับรอง TLS ที่หมดอายุทำให้บริการหยุดชะงักและทำให้ผู้ใช้เห็นคำเตือนเรื่องความน่าเชื่อถือ ซึ่ง Attacker สามารถใช้ประโยชน์ได้ การจัดการวงจรชีวิตใบรับรองประกอบด้วยการติดตามใบรับรองทั้งหมดในคลังใบรับรอง การกำหนดค่าการแจ้งเตือนวันหมดอายุล่วงหน้าอย่างน้อย 30 วัน การต่ออายุโดยอัตโนมัติด้วยโพรโทคอล ACME (Let's Encrypt, Certbot) การใช้อายุใบรับรองที่สั้น (90 วันสำหรับใบรับรองสาธารณะ) เพื่อลดช่วงเวลาความเสี่ยงจากการถูกโจมตี และการใช้ใบรับรองไวลด์การ์ด (*.example.com) อย่างระมัดระวัง เนื่องจากใบรับรองไวลด์การ์ดที่ถูกโจมตีจะส่งผลต่อซับโดเมนทั้งหมด แพลตฟอร์มจัดการใบรับรอง (Venafi, DigiCert CertCentral) ช่วยทำให้การค้นหาและจัดการวงจรชีวิตของใบรับรองในคลังขนาดใหญ่เป็นแบบอัตโนมัติ
# Auto-renew Let's Encrypt cert with Certbot
# Install Certbot
apt install certbot python3-certbot-nginx
# Issue certificate
certbot --nginx -d example.com -d www.example.com
# Certbot auto-renewal (runs twice daily via systemd timer)
systemctl status certbot.timer
# Test renewal without actually renewing
certbot renew --dry-run
# Verify cert expiry date
openssl x509 -enddate -noout -in /etc/ssl/certs/example.crt
# Output: notAfter=Feb 20 12:00:00 2025 GMTตรวจสอบอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า TLS 1.0/1.1 เลิกใช้แล้ว และ TLS 1.2 เป็นมาตรฐานขั้นต่ำ ขณะที่ TLS 1.3 เป็นตัวเลือกที่ต้องการ โดยบังคับใช้ PFS และ handshake ที่เข้ารหัส ชุดรหัสลับจะระบุการแลกเปลี่ยนกุญแจ (ควรเลือก ECDHE) การเข้ารหัสข้อมูลจำนวนมาก (AES-GCM, ChaCha20) และอัลกอริทึม MAC และ ความลับส่งต่ออย่างสมบูรณ์แบบต้องใช้การแลกเปลี่ยนกุญแจชั่วคราว (DHE/ECDHE) เพื่อไม่ให้ถอดรหัสเซสชันในอดีตได้ แม้กุญแจจะถูกโจมตีแล้วก็ตาม ต่อไปเราจะศึกษา DNS ที่ปลอดภัย: DNSSEC และ DNS over HTTPS
คำถามที่พบบ่อย
บทเรียน “เวอร์ชัน TLS ชุดรหัสลับ และการรักษาความลับล่วงหน้าอย่างสมบูรณ์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “เวอร์ชัน TLS ชุดรหัสลับ และการรักษาความลับล่วงหน้าอย่างสมบูรณ์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “เวอร์ชัน TLS ชุดรหัสลับ และการรักษาความลับล่วงหน้าอย่างสมบูรณ์”
กำหนดค่า TLS 1.2/1.3 เลือกชุดรหัสลับที่แข็งแกร่ง และเปิดใช้การรักษาความลับล่วงหน้าอย่างสมบูรณ์ เพื่อให้ไม่สามารถถอดรหัสทราฟฟิกที่บันทึกไว้ย้อนหลังได้ คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “เวอร์ชัน TLS ชุดรหัสลับ และการรักษาความลับล่วงหน้าอย่างสมบูรณ์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม
ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การแทนที่โพรโทคอลที่ไม่ปลอดภัย: Telnet กับ SSH, FTP กับ SFTP
- เวอร์ชัน TLS ชุดรหัสลับ และการรักษาความลับล่วงหน้าอย่างสมบูรณ์
- DNS ที่ปลอดภัย: DNSSEC และ DNS ผ่าน HTTPS (DoH)
- IPsec โพรโทคอล VPN และความปลอดภัยในการเข้าถึงจากระยะไกล