TLS 1.2 vs TLS 1.3 ต่างกันอย่างไร อัปเกรดได้ไหม

TLS (Transport Layer Security) คือโปรโตคอลเข้ารหัสที่ปกป้องข้อมูลระหว่าง browser กับ server TLS 1.2 ใช้กันมานานกว่า 10 ปี ส่วน TLS 1.3 คือเวอร์ชันล่าสุด (IETF ปี 2018) ที่เร็วและปลอดภัยกว่าอย่างมีนัยสำคัญ บทความนี้จะพาไปดูประวัติของแต่ละเวอร์ชัน เปรียบเทียบความเร็วและความปลอดภัย พร้อมวิธีเปิด-ปิด TLS แต่ละเวอร์ชันบนเซิร์ฟเวอร์จริง และวิธีตรวจสอบว่าเว็บของคุณกำลังใช้เวอร์ชันไหนอยู่

ประวัติและสถานะของ TLS แต่ละเวอร์ชัน

TLS พัฒนาต่อยอดมาจาก SSL (Secure Sockets Layer) ของยุค 1990 ปัจจุบัน SSL ทุกเวอร์ชัน (2.0 และ 3.0) ถูกยกเลิกการใช้งานหมดแล้วเพราะมีช่องโหว่ร้ายแรงอย่าง POODLE ส่วน TLS เองก็ผ่านมาหลายรุ่น ตารางด้านล่างสรุปสถานะของแต่ละเวอร์ชันในปี 2026 ว่าควรใช้ต่อหรือควรปิดทิ้ง

สรุปง่าย ๆ คือในปี 2026 ควรเปิดเฉพาะ TLS 1.2 และ TLS 1.3 เท่านั้น ส่วน SSL 3.0, TLS 1.0 และ TLS 1.1 ต้องปิดทิ้งทั้งหมด เพราะเบราว์เซอร์สมัยใหม่ไม่รองรับและมาตรฐานความปลอดภัยอย่าง PCI DSS ก็ห้ามใช้แล้ว

ความแตกต่างหลัก TLS 1.2 กับ TLS 1.3

TLS 1.3 เร็วและปลอดภัยกว่าอย่างไร (1-RTT, Forward Secrecy)

จุดเด่นที่ทำให้ TLS 1.3 เหนือกว่ารุ่นก่อนหน้ามี 3 เรื่องหลัก คือ การจับมือ (handshake) ที่เร็วขึ้น การบังคับ Forward Secrecy และการตัด cipher ที่อ่อนแอออกทั้งหมด

Handshake เร็วขึ้นด้วย 1-RTT

ใน TLS 1.2 การสร้างการเชื่อมต่อต้องใช้การวิ่งไป-กลับระหว่าง browser กับ server ถึง 2 รอบ (2-RTT) ก่อนจะเริ่มส่งข้อมูลจริงได้ แต่ TLS 1.3 ลดเหลือเพียง 1 รอบ (1-RTT) ทำให้เว็บโหลดเร็วขึ้นอย่างรู้สึกได้ โดยเฉพาะผู้ใช้ที่อยู่ไกลจากเซิร์ฟเวอร์หรือใช้เครือข่ายมือถือที่ค่า latency สูง ยิ่งระยะทางไกล ยิ่งประหยัดเวลาต่อ RTT มาก

0-RTT สำหรับการกลับมาใหม่

เมื่อผู้ใช้เคยเชื่อมต่อมาแล้วและกลับเข้าเว็บอีกครั้ง TLS 1.3 รองรับ 0-RTT resumption คือส่งข้อมูลได้ทันทีโดยแทบไม่ต้องรอ handshake ใหม่ ช่วยให้เว็บที่มีผู้ใช้ประจำตอบสนองไวขึ้นมาก แต่ควรระวังเรื่อง replay attack กับ request ที่เปลี่ยนสถานะ (เช่นการชำระเงิน) จึงควรเปิด 0-RTT เฉพาะกับ request ที่ปลอดภัยเท่านั้น

Forward Secrecy บังคับทุก session

Forward Secrecy (PFS) หมายความว่า ถึงแม้ในอนาคต private key ของเซิร์ฟเวอร์จะรั่วไหล ผู้โจมตีก็ยังถอดรหัสทราฟฟิกเก่าที่ดักเก็บไว้ไม่ได้ เพราะแต่ละ session ใช้กุญแจชั่วคราวคนละชุด ใน TLS 1.2 ฟีเจอร์นี้เป็น "ตัวเลือก" ขึ้นกับการตั้ง cipher แต่ TLS 1.3 บังคับใช้ทุก session โดยอัตโนมัติ อีกทั้งยังลดจำนวน cipher suite จาก 37 ตัวเหลือเพียง 5 ตัวที่ผ่านการตรวจสอบว่าแข็งแกร่งทั้งหมด ตัดความเสี่ยงจากการตั้งค่าผิดพลาดออกไป

เปิด/ปิด TLS version บน Nginx และ Apache

หัวใจของการตั้งค่าคือเปิดเฉพาะ TLS 1.2 กับ 1.3 และปิด TLS 1.0/1.1 ทิ้ง ด้านล่างเป็นตัวอย่างคอนฟิกที่ใช้ได้จริง

Nginx — เปิด TLS 1.2 + 1.3 ปิดที่เหลือ

# ในบล็อก server { ... } หรือ http { ... }
ssl_protocols TLSv1.2 TLSv1.3;   # ไม่ใส่ TLSv1 / TLSv1.1 = ปิดอัตโนมัติ
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;   # TLS 1.3 ให้ client เลือก cipher เอง

ทดสอบไวยากรณ์ก่อนด้วย sudo nginx -t แล้วค่อยรีโหลด sudo nginx -s reload

Apache — ปิด TLS เก่าให้ชัดเจน

# ต้องการ OpenSSL 1.1.1+ และ Apache 2.4.37+ สำหรับ TLS 1.3
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
SSLHonorCipherOrder off

ตรวจคอนฟิกด้วย sudo apachectl configtest แล้วรีโหลด sudo systemctl reload apache2 (หรือ httpd บน CentOS/RHEL)

ตรวจสอบว่าเว็บใช้ TLS เวอร์ชันไหน

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

ตรวจสอบ TLS ปัจจุบันของเซิร์ฟเวอร์

วิธีที่ 1: SSL Labs (ง่ายที่สุด)

ไปที่ https://www.ssllabs.com/ssltest/ ใส่โดเมนแล้วดูรายงาน TLS Protocols ที่รองรับ

วิธีที่ 2: curl

curl -v --tlsv1.3 --tls-max 1.3 https://yourdomain.com 2>&1 | grep "TLS"

วิธีที่ 3: OpenSSL

openssl s_client -connect yourdomain.com:443 -tls1_3 2>&1 | grep "Protocol"

เปิด TLS 1.3 บน Nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

จากนั้นรัน: sudo nginx -s reload

เปิด TLS 1.3 บน Apache

# ต้องการ OpenSSL 1.1.1+ และ Apache 2.4.37+
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

ควรปิด TLS 1.0 และ 1.1 ด้วยไหม

ใช่ — IETF ประกาศ deprecate TLS 1.0 และ 1.1 ตั้งแต่ปี 2021 browser สมัยใหม่ไม่รองรับแล้ว การปิดช่วยให้ได้คะแนน A+ บน SSL Labs และผ่าน PCI DSS compliance

Cipher Suites ที่ควรใช้กับ TLS 1.2 และ TLS 1.3

การเลือก Cipher Suite ที่ถูกต้องเป็นสิ่งสำคัญที่ช่วยให้ TLS 1.2 มีความปลอดภัยสูงพอที่จะยังใช้งานได้ควบคู่กับ TLS 1.3 ด้านล่างคือ cipher ที่แนะนำและ cipher ที่ควรถอดออกจากคอนฟิก

Cipher ที่แนะนำสำหรับ TLS 1.2

• ECDHE-ECDSA-AES128-GCM-SHA256 — รองรับ ECDSA certificate, เร็วและปลอดภัย
• ECDHE-RSA-AES128-GCM-SHA256 — รองรับ RSA certificate ที่ใช้กันทั่วไป
• ECDHE-ECDSA-AES256-GCM-SHA384 — ระดับ encryption สูงขึ้นสำหรับข้อมูลสำคัญ
• ECDHE-ECDSA-CHACHA20-POLY1305 — เร็วกว่า AES บนอุปกรณ์ที่ไม่มี AES Hardware Acceleration

Cipher ที่ต้องลบออกจากคอนฟิก TLS 1.2

• RC4 — อ่อนแอ ถูก IETF ห้ามใช้ใน RFC 7465
• 3DES / DES-CBC3 — เสี่ยงต่อ SWEET32 attack
• NULL cipher — ไม่มีการเข้ารหัสเลย อันตรายอย่างยิ่ง
• EXPORT cipher — cipher ที่ถูก export-weakened เสี่ยงต่อ FREAK attack
• RSA key exchange (non-ECDHE) — ไม่มี Forward Secrecy

Cipher ที่ TLS 1.3 บังคับใช้ (5 ตัวเท่านั้น)

สังเกตว่า TLS 1.3 ไม่มี key exchange mechanism ใน cipher suite name — เพราะ TLS 1.3 บังคับ ECDHE สำหรับทุก session อัตโนมัติ ไม่ต้องเลือก cipher สำหรับ key exchange เหมือน TLS 1.2

ตรวจสอบ TLS บน Windows, macOS และ DirectAdmin

นอกจากการใช้ curl และ OpenSSL บน Linux/VPS แล้ว ยังมีวิธีตรวจสอบ TLS version จากระบบปฏิบัติการอื่นและจาก Control Panel ของโฮสติ้ง

ตรวจสอบจาก Browser DevTools

วิธีที่ง่ายที่สุดสำหรับผู้ใช้ทั่วไปคือดูจาก Chrome DevTools โดยเปิดหน้าเว็บที่ต้องการ กด F12 แล้วไปที่แท็บ Security คลิก "View certificate" และดูข้อมูลใน "Connection" ซึ่งจะแสดง TLS version ที่กำลังใช้งานและ cipher suite ที่เลือก

ตรวจสอบด้วย PowerShell (Windows)

$request = [Net.HttpWebRequest]::Create("https://yourdomain.com")
$request.GetResponse() | Out-Null
[Net.ServicePointManager]::SecurityProtocol

ผลลัพธ์จะแสดง protocol ที่ Windows รองรับ เช่น Tls12, Tls13

ตรวจสอบจาก DirectAdmin

ใน DirectAdmin ไปที่ Account Manager → SSL Certificates ซึ่งจะแสดง certificate ที่ติดตั้งอยู่ แต่การตรวจสอบ TLS version จริงๆ ยังต้องใช้ SSL Labs หรือ curl เพราะ Control Panel แสดงเพียง certificate ไม่ใช่ server config

nmap — ตรวจสอบ TLS แบบละเอียด

nmap --script ssl-enum-ciphers -p 443 yourdomain.com

คำสั่งนี้จะแสดง cipher suite ทุกตัวที่เซิร์ฟเวอร์รองรับ พร้อมระดับความปลอดภัย (A/B/C) เหมาะสำหรับ security audit อย่างละเอียด

ผลกระทบของ TLS ต่อ SEO และ Core Web Vitals

การอัปเกรด TLS ไม่ใช่แค่เรื่องความปลอดภัย แต่ยังส่งผลโดยตรงต่อความเร็วของเว็บและคะแนน Core Web Vitals ที่ Google ใช้ในการจัดอันดับ

TTFB (Time to First Byte) ลดลงจาก TLS 1.3

TTFB คือเวลาตั้งแต่เบราว์เซอร์ส่ง request จนได้รับ byte แรกกลับมา เมื่อ TLS 1.3 ลด handshake จาก 2-RTT เป็น 1-RTT ทำให้ TTFB ลดลงอย่างมีนัยสำคัญ โดยเฉพาะสำหรับผู้ใช้ที่อยู่ไกลจากเซิร์ฟเวอร์ ตัวอย่างเช่น ถ้า latency อยู่ที่ 50ms ต่อ RTT การประหยัด 1-RTT หมายถึงลด TTFB ลงได้ 50ms ซึ่งส่งผลให้ LCP (Largest Contentful Paint) ดีขึ้นด้วย

0-RTT ช่วย Returning User โดยตรง

ผู้ใช้ที่กลับมาเยี่ยมชมเว็บซ้ำจะได้ประโยชน์จาก 0-RTT Session Resumption ของ TLS 1.3 ซึ่งแทบไม่มี handshake overhead เลย ผลที่ได้คือ INP (Interaction to Next Paint) และ FCP (First Contentful Paint) ดีขึ้นอย่างเห็นได้ชัด

Google ใช้ HTTPS เป็นสัญญาณ ranking

Google ประกาศ HTTPS เป็น ranking signal ตั้งแต่ปี 2014 และยังคงให้ความสำคัญต่อเนื่อง แม้จะไม่ได้เพิ่มน้ำหนักเรื่อง TLS version โดยตรง แต่เว็บที่มี TLS 1.3 จะได้คะแนน Best Practices บน Lighthouse สูงขึ้น และ PageSpeed Insights จะไม่แจ้งเตือนเรื่อง "Insecure protocol" ซึ่งส่งผลต่อ user experience score

HTTP/2 และ HTTP/3 ต้องการ TLS

HTTP/2 บังคับใช้ TLS ในทุก browser implementation จริง (แม้ spec จะบอกว่า optional) ส่วน HTTP/3 (QUIC) รวม TLS 1.3 เข้าไปในโปรโตคอลเลย ดังนั้นการรองรับ TLS 1.3 คือเงื่อนไขพื้นฐานสำหรับการใช้ HTTP/3 ซึ่งช่วยลด latency และปรับปรุง Core Web Vitals ได้ดีกว่า TLS 1.2 + HTTP/2 อีก

การ Migrate จากสภาพแวดล้อมที่มี TLS เก่า

ถ้าเซิร์ฟเวอร์ยังใช้ OpenSSL เก่าหรือ OS เก่าอยู่ อาจไม่สามารถเปิด TLS 1.3 ได้ทันที ต้องอัปเดตก่อน ตารางด้านล่างสรุปเงื่อนไขขั้นต่ำที่ต้องการ

ถ้าใช้ Shared Hosting หรือ Managed Hosting เช่น AsiaGB Hosting ระบบจะอัปเดต OpenSSL และ Web Server ให้อัตโนมัติ ลูกค้าไม่ต้องทำเอง SSL/TLS จะพร้อมใช้งานและรองรับ TLS 1.3 อัตโนมัติตั้งแต่วันแรก

คำถามที่พบบ่อยเกี่ยวกับ TLS 1.2 และ TLS 1.3

ถ้าเปิดแค่ TLS 1.3 อย่างเดียวได้ไหม

ทำได้ แต่ยังไม่แนะนำในปี 2026 เพราะอุปกรณ์หรือเบราว์เซอร์เก่าบางตัวรองรับแค่ TLS 1.2 ถ้าปิด 1.2 ทิ้งผู้ใช้กลุ่มนั้นจะเข้าเว็บไม่ได้ ทางที่ดีที่สุดคือเปิด TLS 1.2 + 1.3 ควบคู่กัน เพื่อความเข้ากันได้สูงสุดโดยยังปลอดภัย

การอัปเกรดเป็น TLS 1.3 ต้องเปลี่ยน SSL Certificate ใหม่ไหม

ไม่ต้อง — TLS เป็นเรื่องของโปรโตคอลการเชื่อมต่อ ส่วน SSL Certificate เป็นเรื่องของการยืนยันตัวตน ใบเซอร์เดิมใช้กับ TLS 1.3 ได้ทันที เพียงปรับคอนฟิกฝั่งเซิร์ฟเวอร์ให้เปิด TLS 1.3 และอัปเดต OpenSSL ให้เป็นเวอร์ชัน 1.1.1 ขึ้นไป

ปิด TLS 1.0/1.1 แล้วลูกค้าเก่าจะเข้าเว็บไม่ได้หรือเปล่า

กระทบเฉพาะอุปกรณ์ที่เก่ามาก เช่น Windows XP หรือ Android รุ่นเก่ากว่า 5.0 ซึ่งปัจจุบันมีสัดส่วนผู้ใช้น้อยมาก เบราว์เซอร์สมัยใหม่ทุกตัวรองรับ TLS 1.2 เป็นอย่างต่ำอยู่แล้ว การปิด 1.0/1.1 จึงเป็นมาตรฐานที่ปลอดภัยและจำเป็นต่อการผ่าน PCI DSS

จะรู้ได้อย่างไรว่าเว็บผ่านมาตรฐานความปลอดภัย TLS แล้ว

วิธีง่ายที่สุดคือนำโดเมนไปทดสอบที่ SSL Labs (ssllabs.com/ssltest) ถ้าได้เกรด A หรือ A+ และเห็นว่ารองรับเฉพาะ TLS 1.2/1.3 ก็ถือว่าผ่านมาตรฐาน หากใช้ Hosting ของ AsiaGB ระบบตั้งค่า TLS 1.3 และปิดเวอร์ชันเก่าให้อัตโนมัติอยู่แล้ว