SSL (Secure Sockets Layer) และ TLS (Transport Layer Security) เป็นโปรโตคอลการเข้ารหัสที่รับประกันการส่งข้อมูลอย่างปลอดภัยระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ผ่านเครือข่าย พวกเขาเข้ารหัสทราฟฟิกทั้งหมด ป้องกันการดักจับและแก้ไขข้อมูลโดยผู้ไม่หวังดี ตามรายงาน Google Transparency Report (2025) พบว่า 95% ของทราฟฟิกมือถือทั่วโลกใช้การเข้ารหัส TLS หากไม่มีโปรโตคอลนี้ ข้อมูลใด ๆ ที่ส่งผ่าน Wi-Fi สาธารณะหรือเครือข่ายมือถืออาจถูกอ่านโดยบุคคลที่สาม Cloudflare, 2024
ประเด็นสำคัญ
SSL (Secure Sockets Layer) เป็นโปรโตคอลที่พัฒนาโดย Netscape ในปี 1995 เพื่อรักษาความปลอดภัยทราฟฟิกเว็บ เวอร์ชันแรก SSL 1.0 ไม่เคยถูกเผยแพร่สู่สาธารณะ SSL 2.0 (1995) และ SSL 3.0 (1996) ถูกใช้จนถึงต้นยุค 2000 แต่มีช่องโหว่ร้ายแรง SSL ถูกสืบทอดโดย TLS (Transport Layer Security) — เวอร์ชันที่ปรับปรุงแล้วซึ่งถูกทำให้เป็นมาตรฐานโดย IETF TLS 1.0 (1999) มีพื้นฐานมาจาก SSL 3.0 ในขณะที่เวอร์ชันต่อมา TLS 1.1 (2006), TLS 1.2 (2008) และ TLS 1.3 (2018) ค่อย ๆ แยกตัวออกจากสถาปัตยกรรมดั้งเดิม เพิ่มอัลกอริทึมการเข้ารหัสใหม่และแก้ไขช่องโหว่ ปัจจุบัน SSL ถือว่าล้าสมัย และระบบสมัยใหม่ทั้งหมดใช้ TLS แม้ว่าโปรโตคอลทั้งสองมักถูกกล่าวถึงร่วมกันเป็น SSL/TLS ตามความเคยชิน
ประวัติของ SSL/TLS เริ่มต้นจากความจำเป็นในการส่งข้อมูลอย่างปลอดภัยในเว็บยุคแรก ในปี 1994 Netscape พัฒนา SSL 1.0 สำหรับเบราว์เซอร์ Navigator ของตน แต่โปรโตคอลไม่เคยถูกเผยแพร่เนื่องจากปัญหาความปลอดภัยร้ายแรง SSL 2.0 เปิดตัวในปี 1995 และถูกใช้งานจริง แต่มีช่องโหว่มากมาย: ขาดการป้องกันการโจมตีแบบ Man-in-the-Middle อัลกอริทึมการเข้ารหัสที่อ่อนแอ และความไวต่อการโจมตีแบบตัดทอน SSL 3.0 (1996) แก้ไขปัญหาส่วนใหญ่ แต่ภายในปี 2014 มีการค้นพบช่องโหว่ POODLE หลังจากนั้น IETF ประกาศอย่างเป็นทางการว่า SSL ทุกเวอร์ชันล้าสมัย TLS 1.0–1.3 ปรับปรุงความแข็งแกร่งของการเข้ารหัส ประสิทธิภาพ และความเป็นส่วนตัวอย่างต่อเนื่อง โดย TLS 1.3 ลดการจับมือจากสองรอบเหลือหนึ่งรอบ ซึ่งสำคัญอย่างยิ่งสำหรับแอปพลิเคชันมือถือที่มีการเชื่อมต่อไม่เสถียร
การจับมือ (Handshake) เป็นกระบวนการสร้างการเชื่อมต่อที่ปลอดภัยระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ประกอบด้วยหลายขั้นตอนต่อเนื่องกันซึ่งทั้งสองฝ่ายตกลงกันเกี่ยวกับเวอร์ชันโปรโตคอล เลือกอัลกอริทึมการเข้ารหัส แลกเปลี่ยนคีย์ และยืนยันตัวตนซึ่งกันและกัน ใน TLS 1.3 การจับมือใช้เพียงหนึ่งรอบเครือข่าย (1-RTT) ในขณะที่ TLS 1.2 ต้องใช้สองรอบ (2-RTT)
ขั้นตอนแรกคือไคลเอ็นต์ส่ง ClientHello — ข้อความที่มีรายการเวอร์ชัน TLS ที่รองรับ ชุดการเข้ารหัส และตัวเลขสุ่ม เซิร์ฟเวอร์ตอบกลับด้วย ServerHello ที่มีเวอร์ชันและการเข้ารหัสที่เลือก ใบรับรอง X.509 และลายเซ็นดิจิทัล ไคลเอ็นต์ตรวจสอบใบรับรองผ่านห่วงโซ่หน่วยงานออกใบรับรอง (CA) สร้างคีย์เซสชันและส่งคีย์นั้นที่เข้ารหัสด้วยคีย์สาธารณะของเซิร์ฟเวอร์จากใบรับรอง หลังจากการยืนยันจากเซิร์ฟเวอร์ การส่งข้อมูลที่ปลอดภัยก็เริ่มต้นขึ้น การจับมือทั้งหมดใช้เวลา 1–3 มิลลิวินาทีบนอุปกรณ์สมัยใหม่ ทำให้ผู้ใช้ไม่รู้สึก
พื้นฐานของ การยืนยันตัวตน TLS คือโครงสร้างพื้นฐานคีย์สาธารณะ (PKI) ที่สร้างขึ้นบนใบรับรองรูปแบบ X.509 ใบรับรองแต่ละใบประกอบด้วย: ชื่อโดเมน (Common Name หรือ Subject Alternative Name), คีย์สาธารณะของเซิร์ฟเวอร์, ชื่อผู้ออก (หน่วยงานออกใบรับรอง), วันที่หมดอายุ และลายเซ็นดิจิทัลของ CA ไคลเอ็นต์ตรวจสอบใบรับรองของเซิร์ฟเวอร์ตามห่วงโซ่ความไว้วางใจ: จากใบรับรองเซิร์ฟเวอร์ไปจนถึง CA ราก ซึ่งใบรับรองถูกฝังอยู่ในระบบปฏิบัติการ บนอุปกรณ์ Android ใบรับรองรากจะถูกเก็บไว้ในที่เก็บคีย์ของระบบ อัปเดตผ่าน Google Play Services; บน iOS — ผ่านการอัปเดต iOS หากจุดเชื่อมต่อใดในห่วงโซ่ขาด (ใบรับรองหมดอายุ, โดเมนไม่ตรงกัน, CA ไม่รู้จัก) ไคลเอ็นต์จะยกเลิกการเชื่อมต่อ สำหรับใบรับรองที่เซ็นชื่อด้วยตนเอง (ใช้ในการพัฒนา) จำเป็นต้องมีความไว้วางใจอย่างชัดแจ้ง — บน Android ผ่าน Network Security Config, บน iOS ผ่าน NSExceptionDomains ใน Info.plist กระบวนการตรวจสอบห่วงโซ่ใบรับรองรวมถึงการตรวจสอบสถานะการเพิกถอนผ่าน CRL (รายการใบรับรองที่ถูกเพิกถอน) หรือ OCSP (โปรโตคอลสถานะใบรับรองออนไลน์) แม้ว่าบนอุปกรณ์มือถือคำขอ OCSP มักถูกข้ามเพื่อเพิ่มความเร็วในการเชื่อมต่อ — นี่เป็นการแลกเปลี่ยนระหว่างความปลอดภัยและประสิทธิภาพที่สถาปนิกควรพิจารณา
แม้ว่าคำว่า SSL และ TLS มักถูกใช้แทนกันได้ แต่มีความแตกต่างทางเทคนิคพื้นฐานระหว่างพวกเขาที่ส่งผลต่อความปลอดภัยและประสิทธิภาพของแอปพลิเคชันมือถือ
| คุณลักษณะ | SSL 3.0 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|
| ปีที่เปิดตัว | 1996 | 2008 | 2018 |
| สถานะ | ล้าสมัย (RFC 7568) | ใช้งานอยู่ (แนะนำ) | ปัจจุบัน (ดีที่สุด) |
| จำนวนรอบ | 2 | 2 | 1 |
| อัลกอริทึมการแลกเปลี่ยนคีย์ | RSA | RSA, ECDHE | ECDHE (เท่านั้น) |
| การเข้ารหัสที่ผ่านการยืนยันตัวตน | ไม่ | GCM, CCM | AEAD บังคับ |
| Perfect Forward Secrecy | ไม่ | ไม่บังคับ | บังคับ |
ความแตกต่างหลักระหว่าง TLS 1.3 และเวอร์ชันก่อนหน้าคือการใช้ Perfect Forward Secrecy (PFS) ผ่านโปรโตคอล ECDHE ที่บังคับ ซึ่งหมายความว่าแม้ผู้โจมตีจะเข้าถึงคีย์ส่วนตัวของเซิร์ฟเวอร์ได้ ก็ไม่สามารถถอดรหัสทราฟฟิกที่ถูกดักจับก่อนหน้านี้ได้ สำหรับแอปพลิเคชันมือถือที่การบุกรุกเซิร์ฟเวอร์เป็นภัยคุกคามจริง TLS 1.3 กับ PFS เป็นข้อกำหนดด้านความปลอดภัยที่บังคับ
เวอร์ชันเก่าของ SSL และ TLS มีช่องโหว่ที่ได้รับการบันทึกไว้อย่างดีซึ่งทำให้ไม่เหมาะสมสำหรับการใช้งานในโปรดักชัน POODLE (CVE-2014-3566) โจมตี SSL 3.0 ผ่าน padding oracle ทำให้สามารถถอดรหัสคุกกี้เซสชันได้ใน 256 คำขอ BEAST (CVE-2011-3389) ใช้ประโยชน์จากช่องโหว่ในโหมด CBC ของ TLS 1.0 ผ่าน IV ที่คาดเดาได้ Heartbleed (CVE-2014-0160) — ไม่ใช่ช่องโหว่ของโปรโตคอล แต่เป็นบั๊กในการใช้งาน OpenSSL ที่อนุญาตให้อ่านหน่วยความจำเซิร์ฟเวอร์: ตาม Netcraft มีเซิร์ฟเวอร์มากกว่า 500,000 แห่งที่เสี่ยงในปี 2014 ตั้งแต่ Android 10 (API 29) และ iOS 13 เป็นต้นไป โปรโตคอลทั้งหมดเหล่านี้ถูกปิดใช้งานในระดับระบบ อย่างไรก็ตาม นักพัฒนาควรตรวจสอบการกำหนดค่าเซิร์ฟเวอร์ผ่าน SSL Labs Test (qualys.com) ก่อนเปิดตัวแอปพลิเคชันเพื่อให้แน่ใจว่าไม่มีชุดการเข้ารหัสที่ล้าสมัยและรองรับ TLS 1.3
ในแอปพลิเคชันมือถือ TLS ปกป้องข้อมูลในสามระดับ: การเข้ารหัสเนื้อหา (ไม่มีใครยกเว้นเซิร์ฟเวอร์สามารถอ่านข้อมูลได้), การตรวจสอบความสมบูรณ์ (ข้อมูลไม่สามารถถูกเปลี่ยนแปลงระหว่างทาง), และการยืนยันตัวตนเซิร์ฟเวอร์ (ไคลเอ็นต์มั่นใจว่ากำลังเชื่อมต่อกับเซิร์ฟเวอร์ที่ถูกต้อง) การยืนยันตัวตนมีความสำคัญเป็นพิเศษ: หากไม่มี ผู้โจมตีสามารถปลอมแปลงเป็นเซิร์ฟเวอร์ผ่านการปลอมแปลง DNS หรือจุดเชื่อมต่อ Wi-Fi ปลอม
จากการศึกษาของ Google Play Protect (2024) พบว่า 76% ของแอปพลิเคชัน Android ใช้ TLS อย่างถูกต้องด้วยการตรวจสอบใบรับรอง ส่วนที่เหลืออีก 24% ทำผิดพลาด: ปิดการตรวจสอบใบรับรองสำหรับการทดสอบ (และลืมเปิดอีกครั้งในโปรดักชัน), ใช้ใบรับรองที่เซ็นชื่อด้วยตนเองโดยไม่มีการตรวจสอบ, หรืออนุญาตโปรโตคอลที่ล้าสมัยเช่น SSL 3.0 และ TLS 1.0 Apple App Transport Security (ATS) บน iOS กำหนดให้ใช้ TLS 1.2 อย่างน้อยตั้งแต่ปี 2017 และตั้งแต่ iOS 15 เป็นต้นไป จะใช้ TLS 1.3 เป็นค่าเริ่มต้นสำหรับคำขอเครือข่ายทั้งหมด สำหรับการป้องกันเพิ่มเติม แนะนำให้นำ Certificate Pinning — การผูกกับใบรับรองเซิร์ฟเวอร์เฉพาะ — มาใช้ด้วย
มาดูตัวอย่างการกำหนดค่าการเชื่อมต่อ HTTPS ที่ปลอดภัยใน Android โดยใช้ OkHttp — หนึ่งในไลบรารีเครือข่ายที่ได้รับความนิยมมากที่สุด การกำหนดค่าที่ถูกต้องรวมถึงการบังคับใช้ TLS 1.3 และการตรวจสอบใบรับรอง
val client = OkHttpClient.Builder()
.connectionSpecs(
listOf(
ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
.tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
.cipherSuites(
CipherSuite.TLS_AES_128_GCM_SHA256,
CipherSuite.TLS_AES_256_GCM_SHA384,
CipherSuite.TLS_CHACHA20_POLY1305_SHA256
)
.build()
)
)
.hostnameVerifier { hostname, session ->
SSLSession.DefaultHostnameVerifier.verify(hostname, session)
}
.build()
ในตัวอย่างนี้ เราจำกัดชุดเวอร์ชัน TLS ที่รองรับให้เหลือเพียง 1.3 และ 1.2 โดยไม่รวม TLS 1.0/1.1 ที่ล้าสมัย ชุดการเข้ารหัสถูกเลือกจากอัลกอริทึมที่ทันสมัยด้วยโหมด AEAD และ Perfect Forward Secrecy ที่บังคับ HostnameVerifier ตรวจสอบว่าชื่อโฮสต์ตรงกับใบรับรอง บน iOS การกำหนดค่าที่คล้ายกันทำได้ผ่านการกำหนดค่า URLSession โดยตั้งค่าพารามิเตอร์ tlsMinimumSupportedProtocolVersion เป็น .TLSv13 นอกจากนี้ บน iOS สามารถตั้งค่า tlsMaximumSupportedProtocolVersion เพื่อจำกัดเวอร์ชันสูงสุด — มีประโยชน์สำหรับความเข้ากันได้กับเซิร์ฟเวอร์รุ่นเก่าที่ยังไม่ได้ย้ายไปยัง TLS 1.3 การกำหนดค่าดังกล่าวรับประกันความปลอดภัยระดับสูงสุดสำหรับการส่งข้อมูลในแอปพลิเคชันมือถือ
คำถามที่พบบ่อย
TLS เป็นเวอร์ชันที่ใหม่กว่าและปลอดภัยกว่าของโปรโตคอล SSL ล้าสมัยและไม่ควรใช้งาน (RFC 7568) ในทางปฏิบัติ ทั้งสองคำหมายถึงการเข้ารหัส HTTPS แต่ในทางเทคนิค ระบบสมัยใหม่ทั้งหมดทำงานผ่าน TLS 1.2 หรือ 1.3
ติดตั้งเครื่องมือพร็อกซีเช่น Burp Suite หรือ Charles Proxy และดักจับทราฟฟิกของแอป หากการเชื่อมต่อใช้ HTTPS และใบรับรองถูกต้อง — แอปใช้ TLS หากทราฟฟิกไปผ่าน HTTP — ไม่มีการเข้ารหัส
สำหรับบิลด์โปรดักชันอนุญาตเฉพาะ TLS 1.2 และ TLS 1.3 เท่านั้น โปรโตคอล SSL 3.0, TLS 1.0 และ TLS 1.1 ต้องถูกปิดใช้งานทั้งบนเซิร์ฟเวอร์และในแอปพลิเคชันไคลเอ็นต์ ตั้งแต่ปี 2020 แพลตฟอร์มหลัก (Android, iOS, เบราว์เซอร์) กำหนดให้ใช้ TLS 1.2 อย่างน้อย
ใช่ แนะนำให้ใช้ TLS ตรวจสอบใบรับรองผ่านห่วงโซ่หน่วยงานออกใบรับรอง แต่หาก CA ใดถูกบุกรุก (เช่นที่เกิดขึ้นกับ DigiNotar ในปี 2011) ผู้โจมตีสามารถออกใบรับรองปลอมได้ Pinning เพิ่มชั้นการตรวจสอบเพิ่มเติม
TLS 1.3 ลดเวลาในการสร้างการเชื่อมต่อจาก 2 รอบเหลือ 1 รอบ ซึ่งให้การปรับปรุง 30–50% ในการเชื่อมต่อครั้งแรก สำหรับแอปพลิเคชันมือถือที่มีการเชื่อมต่อไม่เสถียร (รถไฟใต้ดิน, รถไฟ) สิ่งนี้สำคัญอย่างยิ่งต่อความเร็วในการโหลดข้อมูล
สรุป
เราจะพัฒนาแอปพลิเคชันบนมือถือแบบครบวงจร
IT Sectr สร้างแอปพลิเคชัน iOS และ Android สำหรับสตาร์ทอัพและธุรกิจตั้งแต่ปี 2017 เราจะให้คำแนะนำและเสนอวิธีแก้ปัญหาที่ดีที่สุดแก่คุณ
อ่านเพิ่มเติม