การดู : 124

29/10/2026 11:41น.

ซองจดหมายปิดผนึกด้วยครั่งวางบนโต๊ะร้านกาแฟข้างแก้วกาแฟ พร้อมการ์ดสรุปว่า HTTP ข้อความเปิดอ่านได้ ส่วน HTTPS เข้ารหัสด้วย TLS

HTTPS คืออะไร SSL กับ TLS ต่างกันอย่างไร ลองดู Certificate จริง

#https คืออะไร

#ssl กับ tls ต่างกันอย่างไร

#http กับ https

#tls คืออะไร

#ssl certificate

#mixed content

#let's encrypt

ลองนึกภาพว่าคุณนั่งอยู่ในร้านกาแฟ ต่อ Wi-Fi ฟรีของร้าน แล้วล็อกอินเข้าเว็บสักเว็บด้วยอีเมลกับรหัสผ่าน โต๊ะข้างๆ มีคนเปิดโน้ตบุ๊กต่อ Wi-Fi วงเดียวกันอยู่ ถ้าเว็บนั้นเป็น HTTP ธรรมดา สิ่งที่คุณกดส่งจะวิ่งผ่านเครือข่ายเป็นข้อความเปิดอ่านได้ คนที่ดักดูเครือข่ายเป็นอาจเห็นรหัสผ่านของคุณทั้งตัว แต่ถ้าเว็บนั้นเป็น HTTPS สิ่งที่เขาเห็นจะเหลือแค่ว่าคุณกำลังคุยกับเว็บไหน ส่วนเนื้อหาข้างในกลายเป็นข้อมูลที่ถูกเข้ารหัสจนอ่านไม่ออก

สั้นๆ: HTTPS คือ HTTP ที่ส่งผ่านการเชื่อมต่อแบบ TLS ซึ่งเข้ารหัสข้อมูล ป้องกันไม่ให้ข้อมูลถูกแก้ระหว่างทาง และยืนยันว่าเซิร์ฟเวอร์ที่คุณคุยด้วยเป็นเจ้าของโดเมนนั้นจริง ส่วน SSL คือชื่อของโปรโตคอลรุ่นก่อน TLS ที่เลิกใช้ไปแล้ว

วันนี้ Superdev Academy จะพาไปดูว่า HTTPS ทำงานอย่างไร SSL กับ TLS ต่างกันตรงไหน แล้วลองเปิดดูใบรับรองของเว็บจริงด้วยคำสั่งที่คุณพิมพ์ตามได้ในเครื่องตัวเอง

HTTPS คืออะไร ย่อมาจากคำว่าอะไร

HTTPS ย่อมาจาก HyperText Transfer Protocol Secure ตามคำอธิบายของ MDN ตัว S ที่เพิ่มเข้ามาคือคำว่า Secure ส่วน HTTP ข้างหน้าก็คือโปรโตคอลเดิมที่เบราว์เซอร์ใช้ขอหน้าเว็บจากเซิร์ฟเวอร์ (Request) แล้วรับคำตอบกลับมา (Response)

หลายคนเข้าใจว่า HTTPS เป็นโปรโตคอลใหม่อีกตัว จริงๆ แล้วไม่ใช่ มาตรฐาน HTTP ฉบับปัจจุบันอย่าง RFC 9110 หัวข้อ 4.2.2 นิยาม scheme "https" ว่าเป็นการคุย HTTP บนการเชื่อมต่อ TLS ที่ถูก "secured" แล้ว คือเซิร์ฟเวอร์ผ่านการยืนยันตัวตน และข้อมูลได้รับการป้องกันทั้งเรื่องความลับและความถูกต้อง คำสั่ง GET, Status Code อย่าง 200 หรือ 404 และ Header ต่างๆ ยังหน้าตาเหมือนเดิมทุกอย่าง แค่ทั้งหมดถูกใส่ซองที่ TLS ปิดผนึกไว้ให้

อีกจุดที่ RFC 9110 ระบุไว้คือ Port (ช่องทางเชื่อมต่อของเครื่องปลายทาง) ถ้า URL ไม่ได้บอก Port มา HTTPS จะใช้ TCP Port 443 เป็นค่าเริ่มต้น ขณะที่ HTTP ธรรมดาใช้ Port 80

HTTP กับ HTTPS ต่างกันอย่างไร

ย้อนกลับไปที่โต๊ะในร้านกาแฟ ความต่างที่จับต้องได้ที่สุดคือ คนที่อยู่กลางทางมองเห็นอะไรบ้าง

  • HTTP: ข้อความเปิดอ่านได้ ทั้ง URL เต็ม, Cookie, ข้อมูลในฟอร์มรวมถึงรหัสผ่าน และคนกลางทางยังแก้เนื้อหาก่อนส่งต่อได้โดยที่ทั้งสองฝั่งไม่รู้ตัว

  • HTTPS: เข้ารหัสด้วย TLS คนกลางทางยังเห็นว่าคุณเชื่อมต่อไปที่ IP ไหน และในหลายกรณียังเห็นชื่อโดเมน แต่ไม่เห็น path ของหน้า, Cookie หรือข้อมูลที่คุณกรอก ถ้ามีใครแอบแก้ข้อมูลระหว่างทาง ปลายทางก็ตรวจจับได้

ทำไมชื่อโดเมนยังหลุดออกไปได้? ส่วนหนึ่งเพราะก่อนเริ่มเข้ารหัส เบราว์เซอร์ต้องบอกเซิร์ฟเวอร์ก่อนว่าอยากคุยกับเว็บไหน ข้อมูลนี้เรียกว่า SNI (Server Name Indication) อีกส่วนคือการถาม DNS เพื่อแปลงชื่อเว็บเป็น IP ซึ่งเราอธิบายไว้ใน DNS คืออะไร ทำงานอย่างไร เรื่องนี้ไม่ได้ทำให้ HTTPS ไร้ประโยชน์ แค่ควรรู้ว่ามันปกป้อง "เนื้อหา" แต่ไม่ได้ซ่อน "ว่าคุณไปเว็บไหน"

TLS คืออะไร ให้อะไรกับการเชื่อมต่อบ้าง

TLS ย่อมาจาก Transport Layer Security เป็นโปรโตคอลที่ทำงานอยู่ใต้ HTTP อีกชั้นหนึ่ง เอกสารมาตรฐานของ TLS 1.3 (RFC 8446 ออกเมื่อสิงหาคม 2018) เขียนเป้าหมายไว้ว่าเพื่อกันการดักฟัง การแก้ไขข้อมูล และการปลอมข้อความ แล้วแยกออกมาเป็นคุณสมบัติ 3 ข้อ

  • Confidentiality: หลังเชื่อมต่อเสร็จ ข้อมูลที่ส่งจะมองเห็นได้เฉพาะสองปลายทางเท่านั้น

  • Integrity: ถ้ามีใครแก้ข้อมูลระหว่างทาง ปลายทางจะตรวจเจอ

  • Authentication: ฝั่งเซิร์ฟเวอร์ถูกยืนยันตัวตนเสมอ ส่วนฝั่งผู้ใช้จะยืนยันหรือไม่ก็ได้

ข้อ 3 คือจุดที่ Certificate (ใบรับรองดิจิทัล) เข้ามาเกี่ยว RFC 9110 อธิบายว่าเบราว์เซอร์จะถือว่ากำลังคุยกับเว็บที่ถูกต้อง ก็ต่อเมื่อเซิร์ฟเวอร์พิสูจน์ได้ว่าถือ Private Key ที่คู่กับ Certificate ซึ่งเบราว์เซอร์ไว้ใจสำหรับโดเมนนั้น พูดง่ายๆ คือ Certificate เป็นเหมือนบัตรประชาชนของเว็บ มีหน่วยงานกลางที่เรียกว่า Certificate Authority (CA) เซ็นรับรองให้ และเครื่องของคุณมีรายชื่อ CA ที่ไว้ใจติดมาอยู่แล้ว

ถ้าไม่มีข้อ 3 การเข้ารหัสแทบไม่มีความหมาย เพราะคนกลางทางอาจทำตัวเป็นเซิร์ฟเวอร์ปลอม แล้วเข้ารหัสคุยกับคุณอย่างดี ข้อมูลก็ยังไปถึงมือเขาอยู่ดี

SSL กับ TLS คืออะไร ต่างกันอย่างไร

ตอบแบบตรงๆ ไม่อ้อม: TLS คือรุ่นต่อจาก SSL (Secure Sockets Layer) ทั้งคู่ทำหน้าที่เดียวกัน แต่ SSL ถูกประกาศเลิกใช้ไปหมดแล้ว ไทม์ไลน์จากเอกสารของ IETF เอง

  • SSL 3.0: ถูกแทนที่ด้วย TLS 1.0 ตั้งแต่ปี 1999 และ RFC 7568 (มิถุนายน 2015) ประกาศชัดว่า SSLv3 ต้องไม่ถูกใช้อีก (MUST NOT be used)

  • TLS 1.0 และ 1.1: RFC 8996 (มีนาคม 2021) ประกาศเลิกใช้ทั้งสองเวอร์ชันด้วยถ้อยคำแบบเดียวกัน

  • TLS 1.2 และ 1.3: สองเวอร์ชันที่ยังใช้งานอยู่ โดย TLS 1.3 เป็นเวอร์ชันล่าสุดตาม RFC 8446

แล้วทำไมทุกคนยังเรียกว่า SSL Certificate

เพราะชื่อติดปากมาตั้งแต่ยุคที่ SSL ยังเป็นมาตรฐานหลัก และเครื่องมือหลายตัวก็ยังพิมพ์คำว่า SSL ออกมา แม้แต่ curl ที่เราจะลองใช้ในหัวข้อถัดไปก็ยังขึ้นว่า "SSL connection using TLSv1.3" ทั้งที่ของที่วิ่งอยู่จริงคือ TLS 1.3 ใบรับรองที่ขายหรือแจกในชื่อ SSL Certificate คือใบเดียวกับที่ TLS ใช้ เวลาเห็นคำว่า SSL Certificate อ่านในใจว่า TLS Certificate ได้เลย

ลองเปิดดู Certificate ของเว็บจริงด้วยตัวเอง

แทนที่จะให้เชื่อตามที่เล่า เราลองเปิดดูใบรับรองของ www.superdevacademy.com เองด้วย OpenSSL 3.6.3 บน macOS เมื่อวันที่ 1 ตุลาคม 2026 คำสั่งนี้เชื่อมต่อไปที่ Port 443 แล้วพิมพ์เฉพาะส่วนสำคัญของใบรับรองออกมา

$ openssl s_client -connect www.superdevacademy.com:443 -servername www.superdevacademy.com </dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN=www.superdevacademy.com
issuer=C=US, O=Google Trust Services, CN=WE1
notBefore=Aug 21 08:04:58 2026 GMT
notAfter=Nov 19 09:04:55 2026 GMT

อ่านทีละบรรทัด

  • subject: ใบนี้ออกให้ชื่อ www.superdevacademy.com ตรงกับโดเมนที่เราเชื่อมต่อ

  • issuer: CA ที่เซ็นรับรองคือ Google Trust Services

  • notBefore / notAfter: ใช้ได้ตั้งแต่ 21 สิงหาคม ถึง 19 พฤศจิกายน 2026 นับแล้วอายุ 90 วัน

flag -servername ในคำสั่งคือการส่งชื่อโดเมน (SNI) ไปบอกเซิร์ฟเวอร์ตั้งแต่ต้น ซึ่งก็คือเหตุผลเดียวกับที่คนกลางทางยังเห็นชื่อโดเมนได้

ถ้าอยากเห็นขั้นตอนการเชื่อมต่อ ใช้ curl แบบ verbose ได้ ด้านล่างคือผลจาก curl 8.4.0 วันเดียวกัน ตัดมาเฉพาะบรรทัดที่เกี่ยว

$ curl -vI https://www.superdevacademy.com/
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
*  subject: CN=www.superdevacademy.com
*  subjectAltName: host "www.superdevacademy.com" matched cert's "www.superdevacademy.com"
*  issuer: C=US; O=Google Trust Services; CN=WE1
*  SSL certificate verify ok.
< HTTP/2 200

บรรทัด matched cert's คือ curl เช็คแล้วว่าชื่อในใบรับรองตรงกับโดเมน ส่วน SSL certificate verify ok คือเช็คแล้วว่า CA ที่เซ็นอยู่ในรายชื่อที่เครื่องไว้ใจ ถ้าข้อใดข้อหนึ่งไม่ผ่าน เบราว์เซอร์จะขึ้นหน้าเตือนแทนที่จะเปิดเว็บให้

แม่กุญแจบนเบราว์เซอร์ ไม่ได้แปลว่าเว็บน่าเชื่อถือ

นี่คือความเข้าใจผิดที่แพงที่สุดในเรื่องนี้ แม่กุญแจหรือ https:// บนแถบที่อยู่บอกได้แค่สองอย่าง คือการเชื่อมต่อถูกเข้ารหัส และเซิร์ฟเวอร์ปลายทางถือใบรับรองที่ใช้ได้จริงของโดเมนบนแถบที่อยู่นั้น มันไม่ได้บอกว่าเจ้าของโดเมนเป็นคนดี

เว็บหลอกลวงก็ขอใบรับรองได้เหมือนเว็บอื่น Let's Encrypt อธิบายขั้นตอนของตัวเองว่าก่อนออกใบรับรอง ผู้ขอต้องพิสูจน์ว่าควบคุมโดเมนนั้นได้ ด้วยการตั้ง DNS record หรือวางไฟล์ไว้บนเว็บตามที่กำหนด สิ่งที่ถูกตรวจคือ "คุมโดเมนได้ไหม" ไม่ใช่ "เป็นธุรกิจที่สุจริตไหม" ถ้าโดเมนบนแถบที่อยู่คือ paypa1-secure-login.example ที่มีแม่กุญแจครบ การเข้ารหัสก็แค่ช่วยให้รหัสผ่านของคุณเดินทางไปถึงมิจฉาชีพอย่างปลอดภัย

วิธีป้องกันจึงไม่ใช่การดูแม่กุญแจ แต่คือการอ่านชื่อโดเมนให้ครบทุกตัวอักษรก่อนกรอกรหัสผ่าน และเข้าเว็บสำคัญจาก bookmark หรือพิมพ์เองแทนการกดลิงก์ในข้อความ ส่วนถ้าคุณเป็นคนเขียนเว็บ HTTPS เป็นแค่ชั้นแรกของความปลอดภัย เรื่องที่ต้องทำต่อในโค้ดเราสรุปไว้ใน เทคนิค Secure Coding ที่มือใหม่ต้องรู้

Certificate ได้มาจากไหน ต้องเสียเงินไหม

ไม่จำเป็นต้องเสียเงิน Let's Encrypt เป็น CA ไม่แสวงกำไรที่ดำเนินการโดย Internet Security Research Group (ISRG) และระบุใน FAQ ว่าไม่เก็บค่าธรรมเนียมใบรับรอง ใบรับรองมาตรฐานของ Let's Encrypt มีอายุ 90 วัน และมีตัวเลือกใบรับรองอายุสั้นเพียง 6 วันให้คนที่เลือกใช้ด้วย

อายุสั้นแบบนี้ไม่ได้มีแค่ที่ Let's Encrypt ใบรับรองของ superdevacademy.com ที่เราเพิ่งเปิดดูก็อายุ 90 วันเหมือนกัน และ CA/Browser Forum ซึ่งเป็นที่ประชุมของ CA กับผู้ทำเบราว์เซอร์ ลงมติรับ Ballot SC-081v3 ในปี 2025 ให้ลดอายุสูงสุดของใบรับรอง TLS ลงเป็นขั้นๆ เริ่มมีนาคม 2026 จาก 398 วัน ไปจนเหลือ 47 วันในมีนาคม 2029

ผลในทางปฏิบัติคือ การต่ออายุด้วยมือยิ่งไม่เหมาะ ควรให้ระบบต่ออายุอัตโนมัติ ถ้าอยากเห็นการตั้งค่าแบบใช้งานจริงกับ Certbot และ cert-manager เราเขียนไว้แล้วใน EP.125 TLS / WSS และ Certificate Management สำหรับ WebSocket

ทำเว็บให้เป็น HTTPS ให้ครบ: Redirect และ Mixed Content

Redirect จาก HTTP ไป HTTPS

มีใบรับรองแล้วยังไม่จบ ถ้ามีคนพิมพ์ http:// เข้ามา เว็บควรพาไป https:// ให้อัตโนมัติ ลองเช็คเว็บของเราเองในวันเดียวกัน (ตัดมาเฉพาะบรรทัดที่เกี่ยว)

$ curl -sI http://www.superdevacademy.com/
HTTP/1.1 301 Moved Permanently
Location: https://www.superdevacademy.com/

301 Moved Permanently คือ Status Code ที่บอกเบราว์เซอร์ว่าหน้านี้ย้ายไปที่ใหม่ถาวร แล้ว Location บอกว่าที่ใหม่คือ https:// ถ้าอยากอ่านรหัสตัวอื่นต่อ ดูได้ใน HTTP Status Code คืออะไร มีอะไรบ้าง

Mixed Content คืออะไร

ตามคำอธิบายของ MDN Mixed Content คือหน้าเว็บที่โหลดผ่าน HTTPS แต่ดึงไฟล์ประกอบบางตัวผ่าน HTTP เช่น รูปหรือสคริปต์ที่ลิงก์ด้วย http:// ไฟล์พวกนั้นถูกอ่านหรือแก้ระหว่างทางได้ ทั้งหน้าจึงไม่ได้ปลอดภัยเท่าที่แม่กุญแจบอก MDN แบ่งไว้สองกลุ่ม

  • Upgradable: รูป เสียง และวิดีโอ เบราว์เซอร์จะเปลี่ยนคำขอเป็น HTTPS ให้เองแล้วขึ้นคำเตือนใน Console

  • Blockable: สคริปต์ ไฟล์ CSS, iframe, คำขอจาก fetch() และฟอนต์ เบราว์เซอร์จะบล็อกไม่ให้โหลดเลย

อาการที่พบได้บ่อยหลังย้ายเว็บขึ้น HTTPS คือหน้าตาเพี้ยนหรือปุ่มกดไม่ได้ สาเหตุมักเป็นไฟล์ CSS หรือ JavaScript ที่ยังลิงก์ด้วย http:// อยู่ วิธีไล่หาคือเปิด DevTools แท็บ Console ดูว่าไฟล์ไหนถูกบล็อก แล้วแก้ลิงก์เป็น https:// ทีละจุด


สรุป: HTTPS คืออะไร และสำคัญอย่างไรต่อการใช้งานเว็บไซต์

HTTPS คือ HTTP ที่วิ่งบน TLS ไม่ใช่โปรโตคอลใหม่ ความสำคัญของมันคือสามเรื่องที่ TLS ให้มา ข้อมูลอย่างรหัสผ่านและ Cookie ไม่ถูกอ่านกลางทางแม้อยู่บน Wi-Fi สาธารณะ เนื้อหาไม่ถูกแก้โดยที่ไม่มีใครรู้ และคุณได้คุยกับเซิร์ฟเวอร์ของโดเมนนั้นจริง ส่วน SSL เป็นชื่อรุ่นเก่าที่เลิกใช้แล้ว เหลืออยู่แค่ในคำว่า SSL Certificate และแม่กุญแจก็บอกได้แค่ว่าการเชื่อมต่อปลอดภัย ไม่ได้รับรองว่าเจ้าของเว็บน่าไว้ใจ

ลองเปิด Terminal แล้วรันคำสั่ง openssl ข้างบนกับเว็บที่คุณใช้บ่อยสักเว็บ ดูว่าใครเป็น issuer ใบรับรองหมดอายุวันไหน และ http:// ของเว็บนั้น redirect ไป https:// หรือเปล่า ห้านาทีที่ได้ลงมือดูของจริงจะทำให้เรื่องนี้ไม่ใช่แค่คำศัพท์อีกต่อไป

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

Facebook: Superdev Academy Thailand (https://www.facebook.com/superdev.academy.th)

YouTube: Superdev Academy Channel (https://www.youtube.com/@SuperdevAcademy)

Instagram: @superdevacademy (https://www.instagram.com/superdevacademy/)

TikTok: @superdevacademy (https://www.tiktok.com/@superdevacademy?lang=th-TH)

FAQ: คำถามที่พบบ่อยเกี่ยวกับบทความนี้

รวมคำถามและคำตอบที่ช่วยให้คุณเข้าใจเนื้อหาในบทความนี้ได้ดียิ่งขึ้น