HTTPS in a nutshell
🤔 ไม่ได้ปลอดภัยเหมือนที่เราคิด อธิบายหมดเปลือกแบบภาษาชาวบ้าน
Last updated
Was this helpful?
🤔 ไม่ได้ปลอดภัยเหมือนที่เราคิด อธิบายหมดเปลือกแบบภาษาชาวบ้าน
Last updated
Was this helpful?
เวลาที่เราเข้าเว็บอะไรก็ตามที่ต้องใส่ ข้อมูลบัตรเครดิต หรือ ข้อมูลที่เราไม่อยากให้ใครรู้ เราจะมั่นใจได้ไงว่า ข้อมูลของเราโดนส่งให้คนรับถูกคน? และ ไม่มีคนอื่นแอบอ่านข้อมูลลับของเราอยู่?
แนะนำให้อ่าน บทความนี้เป็นส่วนหนึ่งของคอร์ส ถ้าเพื่อนๆสนใจอยากรู้หลักในการรักษาความปลอดภัยตั้งแต่เริ่มต้นเลย ก็กดอ่านที่ตัวสีฟ้าๆได้เลยนะ
ในวงการคอมพิวเตอร์การที่ คอม 2 เครื่องจะคุยกันแบบปลอดภัยจริงๆนั้นทำได้ยาก เพราะตัวระบบต่างๆย่อมมีช่องโหว่อยู่เสมอ ทำให้คนร้ายใช้ช่องโหว่เหล่านั้นเข้ามาโจมตีได้ตลอดเวลา เช่น แอบอ่านข้อมูลระหว่างทาง หรือ ปลอมตัวเป็นผู้รับเสียเอง ตามรูปด้านล่าง
ปัญหาเกิดจากคนร้ายแอบเสียบตัวเองเข้ามาคั่นการสนทนา ดังนั้นเราก็แค่ ใส่เกราะป้องกันช่องทางการสนทนา เพียงแค่นี้คนร้ายก็จะแอบแทรกระหว่างกลางไม่ได้แล้วนั่นเอง
วิธีการใส่เกราะป้องกันมีหลายวิธี แต่วิธีที่นิยมและใช้กันแพร่หลายที่สุดคือการทำ HTTPS ไงล่ะ แต่ว่า หลายคนเข้าใจผิดคิดว่าแค่ใส่ HTTPS เข้าไปอย่างเดียวมันจะปลอดภัย ซึ่งจริงๆมันไม่ใช่แบบนั้น เพราะอย่างที่บอกของทุกอย่างย่อมมีรูรั่วอยู่เสมอ ซึ่ง HTTPS ก็มีเช่นกัน
ดังนั้นในบทความนี้เราจะมาเรียนรู้หลักในการทำงานของ HTTPS ตั้งแต่ต้นจนจบประบวนการ แล้วมาดูกันว่า เขาจะโจมตี HTTPS นี้ได้ยังไง? รวมทั้งข้อเสียของการใช้ HTTPS มีอะไรบ้าง? กันดีก่า
เวลาที่เราเข้าเว็บอะไรก็ตามเราจะเห็นตัวเว็บขึ้นต้นด้วย http:// หรือไม่ก็ https://อยู่เสมอชิมิ นั่นคือหนึ่งในช่องทางที่ให้คอมมันคุยกันได้ ซึ่งสิ่งสำคัญที่เราต้องรู้คือ
สมมุติว่าเราส่งข้อความจีบสาวด้วย HTTP ธรรมดาละก็ ฟามลับก็อาจจะไม่ใช่ฟามลับอีกต่อปาย
ซ้ำร้ายกว่านั้นด้วย HTTP ธรรมดา เราจะไม่รู้เลยว่าอีกฝั่งที่เราคุยด้วย ใช่คนๆนั้นจริงๆหรือเปล่า
แถมเจ้า HTTPS ยังช่วยตรวจให้ว่า ฝั่งที่คุยด้วยเป็นคนที่เราอยากจะคุยด้วยจริงๆอะป่าว ดังนั้นคนร้ายไม่มีโอกาสแทรกเข้ามาเบย
โว้วๆๆๆๆ เหมือนเจ้า HTTPS จะเป็นดุจบร๊ะเจ้าเลยนิ แล้วไหงว่ามันมีข้อเสียอ่ะ? งั้นเราลองซูมเข้าไปดูการทำงานลึกๆของมันต่อดีกั่ว
Symmetric Key หรือ กุญแจสมมาตร เป็นกุญแจที่สามารถใช้ได้ทั้ง เข้ารหัส และ ถอดรหัส ภายในดอกเดียวกัน ซึ่งถ้าเราเข้ารหัสด้วยกุญแจที่เป็น Symmetric ดอกไหนไป เมื่อจะถอดรหัสก็ต้องใช้กุญแจดอกเดิมในการถอดรหัสเท่านั้น ตามรูปด้านล่าง
เกร็ดความรู้ ปรกติ Symmetric Key นั้นควรจะมีความยาวขั้นต่ำที่ 128 bits แต่ถ้าจะให้ดีควรเป็น 256 bits ซึ่งในปัจจุบันถ้ามันต่ำกว่า 80 bits ในวงการ security ถือว่าไม่ปลอดภัยแล้ว
Asymmetric Key หรือ กุญแจไม่สมมาตร ปรกติเรานิยมเรียกว่า กุญแจคู่ เพราะตอนที่สร้างกุญแจนั้น เราจะได้ออกมา 2 ดอก ซึ่งถ้าเราใช้ดอกไหนเข้ารหัสไป เมื่อจะถอดรหัสจะต้องใช้อีกดอกในการถอดรหัสเท่านั้น ตามรูปด้านล่าง
เจ้ากุญแจทั้ง 2 ดอกนี้มีชื่อเรียกของมันคือ Public Key กับ Private Key ซึ่งปรกติการใช้งานเราจะ
เก็บ Private key ให้ไม่ให้ใครเห็นเด็ดขาด รักษายิ่งชีพ
แจกจ่าย Public Key ให้กับคนที่เราอยากให้เขาคุยกับเราได้ หรือ เอาไว้ตรวจสอบเราเอง
เกร็ดความรู้ ปรกติ Asymmetric Key นั้นควรจะมีความยาวขั้นต่ำที่ 1024 bits แต่ถ้าจะให้ดีควรเป็น 2048 bits
ข้อควรระวัง โดยปรกติเจ้าตัว Asymmetric Key นั้น ตัวกุญแจทั้ง 2 ดอกมันมีความเกี่ยวข้องกันโดยสมการคณิตศาสตร์ฝังอยู่ (แต่ไม่สามารถคำนวณเพื่อสร้างกุญแจดอกตรงข้ามได้) เนื่องจากมันมีความเกี่ยวข้องกันเลยทำให้มันมีขนาดที่ใหญ่กว่า Symmetric Key มาก ดังนั้นตัว Asymmetric Key จะใช้การคำนวณมากกว่า Symmetric Key ราวๆ 1000 เท่า (ช้าโฮ๊กๆในเชิงคอมพิวเตอร์ แต่กระพริบตาก็เสร็จละ) ดังนั้นเราไม่ควรจะตะบี้ตะบันใช้ Asymmetric Key อยู่ตลอดเวลาถ้าไม่จำเป็นนั่นเอง
ซึ่งเจ้าพวกกุญแจพวกนี้ถ้าเปิดดูมันก็จะเป็นตัวอักษรยึกๆยือๆอ่านไม่ออก ตามตัวอย่างด้านล่าง
จากกระบวนการทั้งหมดมันจะทำให้มันตรวจสอบได้ว่า ฝั่งที่คุยด้วยเป็นคนที่เราอยากคุยด้วยจริงๆหรือเปล่า (โดยการตรวจ Certificate) และ มีแค่คู่สนทนานี้เท่านั้นที่จะคุยกันรู้เรื่อง (เพราะคนอื่นไม่มีกุญแจเอาไว้ถอดรหัส) แต่ก็ยังมีคำถามต่อว่า เราจะเชื่อตัวใบรับรอง (Cerificate) ที่ส่งมาจากขั้นตอนที่ 3 ได้ยังไง? เพราะถ้ามันเป็นของปลอม เราก็จะถูกหลอกทำ TLS กับคนที่เราไม่ได้อยากคุยด้วยได้ง่ายๆเลยนั่นเอง ดังนั้นเราก็ต้องรู้จักกับสิ่งที่เรียกว่า CA ต่อนั่นเอง
เกร็ดความรู้ การสร้างกุญแจลับสามารถทำได้หลายแบบ และหนึ่งในนั้นคือการใช้ข้อมูลที่เรามีไปสร้างกุญแจลับอันใหม่ และเราเรียกมันว่าการทำ Key Derivation ซึ่งปรกติถ้าเราใช้ ข้อมูลเดียวกันไปสร้างกุญแจลับอันใหม่ เราก็จะได้กุญแจลับแบบเดียวกันออกมา ดังนั้นในรูปด้านบน ขั้นตอนที่ 5 กับ 7 เมื่อ Client กับ Server มีข้อมูลเหมือนกัน และทั้ง 2 ฝั่งก็รู้ว่าจะใช้ Key Derivation แบบไหน ดังนั้นทั้ง 2 ฝั่งก็จะสามารถสร้าง Session Key ออกมาได้เป็นตัวเดียวกันนั่นเอง
เมื่อฝั่งอัศวินได้รับ Chain-of-trust มาก็จะ ตะกุยหา Root Certificate ว่ามีคนรับรองที่ถูกต้องหรือเปล่า ซึ่งหาก Root มีคนรับรองที่ถูกต้องก็หมายความว่า สามารถเชื่อใจได้ว่าอีกฝั่งคือคนที่เราอยากคุยด้วยจริงๆตามรูปด้านล่าง
ตัว Certificate แต่ละใบจะถูกเข้ารหัสจาก Certificate ก่อนหน้า และมีการอ้างถึงใบที่สร้างมัน ทำให้เราสามารถเช็คย้อนกลับไปหา Root ได้ ตามโครงสร้างด้านล่าง
ดังนั้นเมื่อคนร้ายแอบปลอมตัวมา โดยทั่วไปคนร้ายจะไม่มี Certificate ที่ถูกยอมรับ ดังนั้นเขาก็จะต้องสร้าง Ceritifcate ของเขาเอง ดังนั้นในกระบวนการตรวจสอบก็จะแจ้งเตือนว่ามันไม่เป็นที่ยอมรับนะ นี่เลยเป็นหนึ่งในเหตุผลที่ Self-Sign ที่เราทำเองเซ็นเองถึงโดนแจ้งเตือนไปด้วย ตามรูปด้านล่าง
Self-Sign คือการออกใบรับรองเองเซ็นเอง ไม่ได้มีใครที่ไหนมารับรู้และยอมรับให้นั้น ปรกติเราจะ ใช้แค่ภายในของเราเอง หรือ ใช้ทดสอบ Security Development เท่านั้น ไม่เหมาะสมที่จะเอาไปใช้ในวงที่เป็น Public เพราะใครก็ปลอมเป็นคุณได้
โดยปรกติเวลาที่เราเข้าเว็บอะไรก็ตาม เจ้าตัว Web Browser ก็จะมีการบอกอยู่แล้วว่าปลอดภัยหรือเปล่า โดยมีรูปสัญลักษณ์ 🔒 กุญแจอยู่ ซึ่งเราสามารถกดเข้าไปดูรายละเอียดได้ เช่น Encryption ที่ใช้ ตัว Certificate ต่างๆที่ส่งมาตามรูปด้านล่างนั่นเอง
กระบวนการทั้งหมดถ้าการจับมือเสร็จสิ้นไปแล้วนับแทบจะพูดได้ว่าโดนโจมตีไม่ได้เลยก็ได้ นอกจากตัว client/server โดนโจมตีภายในทำให้ secret หลุดไป ซึ่งคนร้ายก็รู้ดีว่าการโจมตีแบบนั้นไม่ใช่เรื่องง่าย ดังนั้นสิ่งที่เขาจะเลือกทำก็คือ หลอกฝั่ง Client ก่อนที่จะทำ Handshake เพราะมันง่ายกว่าวิธีแรกมาก
เนื่อจากการโจมตีฝั่ง Server ไม่ใช่เรื่องง่ายเลย แต่การโจมตีฝั่ง Client นั้นกลับทำได้ง่ายเสียกว่า เพราะโดยปรกติฝั่ง Client จะไม่ค่อยระวังตัว ชอบทำอะไรเปิ่นๆ ติดตั้งโปรแกรมมั่วซั่ว เข้า Wifi สาธารณะ ดังนั้นการโจมตีฝั่ง client เพื่อไปเอา secret หรือดักจับข้อมูลต่างๆจะทำได้ง่ายกว่า และที่สำคัญโปรแกรมส่วนใหญ่ที่อยู่ในตัว client นั้นจะเก็บรักษาของที่เป็น security ได้ค่อนข้างยาก และคนส่วนใหญ่ที่ไม่ได้ระวังก็อาจจะเอา secret data ไปเก็บไว้ในของที่ไม่สมควร เช่น cookie (ต่อให้เป็น secure cookie ก็ยังมีประเด็น) ดังนั้นให้ระวังฝั่ง client ไว้ให้ดี
จากทั้งหมดที่เขียนไว้ก็น่าจะพอเข้าใจการทำงานของ HTTPS มากขึ้นแล้วชิมิ? ดังนั้นเมื่อไหร่ก็ตามที่เราจะต้องส่งข้อมูลที่มีความลับ หรือที่เราเรียกกันว่า Sentitive Information ไปหาใครก็ตาม เราควรจะต้องทำผ่าน HTTPS เพื่อป้องกันคนแอบเข้ามาป่วนเรานั่นเอง แต่ไม่ใช่แค่เราใช้ HTTPS แล้วก็จะนอนตีพุงสบายใจแฮได้นะ เพราะการจัดการที่ฝั่ง Client ก็มีผลสูงมากเหมือนกัน ซึ่งอย่างที่บอกไปว่า เหล่าคนร้ายเลือกที่จะโจมตี Client ก่อนเสมอ เพราะมันง่ายงุยล่ะ
การโจมตีแบบนี้จริงๆมีตัวอย่างอีกหลายแบบมาก ซึ่งส่วนใหญ่คนร้ายจะแอบเข้ามาอยู่ตรงกลางระหว่างเรากับเซิฟเวอร์ ดังนั้นเราเลยนิยมเรียกการโจมตีพวกนี้ว่า หรือ MITM งุยล่า (จริงๆวิธีการโจมตีแต่ละแบบก็จะมีชื่อเรียกของมันอยู่นะ)
เจ้าตัว http (ย่อจาก ) เวลามันส่งข้อมูลออกไป ข้อมูลพวกนั้นจะเป็นข้อความธรรมดา (Plain Text) นั่นหมายความว่า ถ้ามีคนใช้โปรแกรมดักจับข้อมูล (Packet Sniffer) แล้วจับข้อมูลของเราได้ เขาก็จะอ่านทุกอย่างที่เราส่งออกไปได้นั่นเอง
เจ้าตัว https (ย่อจาก ) ซึ่งเวลามันส่งข้อมูลออกไป ข้อมูลพวกนั้นจะถูกเข้ารหัสลับที่ทำให้ไม่สามารถอ่านได้เอาไว้ ซึ่งจะมีแค่คนที่มีกุญแจลับเท่านั้นถึงจะอ่านมันออก และโดยปรกติกุญแจลับจะอยู่กับคู่สนทนาทั้ง 2 ฝั่งเท่านั้น
เจ้า HTTPS มันมีหน้าที่ป้องกันการคุยกันให้เรา โดยเบื้องหลังของมันคือสิ่งที่เรียกว่า โดยในตอนแรกมันใช้ชื่อว่า SSL ย่อจาก Secure Sockets Layer แล้วก็ถูกอัพเกรดมาเรื่อยๆ ปัจจุบันมันชื่อว่า TLS ย่อจาก Transport Layer Security นั่นเอง ซึ่งเราจะเจอคำว่า SSL/TLS ตลอดเวลาแม้ว่า SSL จะตกยุคไปแล้วก็ตาม เพราะในวงการ Security นั้นมันมีการเปลี่ยนแปลงบ่อยมาก มันต้องไล่อุดรูรั่วตลอดเวลา ดังนั้นไม่ต้องแปลกใจที่จะเห็นคนบางกลุ่มยังใช้ของที่มันไม่ปลอดภัยแล้ว หรือใช้ยังวิธีการแบบเก่าๆอยู่ และบ่อยครั้งที่จะเจอว่าวันนี้บอกว่าใช้ตัวนี้ แล้วผ่านไปซักพักก็จะบอกว่าอย่าใช้ตัวนั้นนะ ดังนั้นจำไว้เลยวงการนี้ไม่แน่นอนต้องตามอัพเดทตลอด โดย TLS ล่าสุดคือเวอร์ชั่น 1.3
แนะนำให้อ่าน หากใครสนใจอยากรู้หลักการทำงานแบบเจาะลึกแบบฝุดๆ ให้ไปอ่านที่ลิงค์นี้ได้เลย
เพื่อให้เข้าใจ TLS เราจำเป็นต้องเข้าใจเรื่อง 🔑 กุญแจลับ ที่ใช้ในการเข้ารหัสเพื่อทำให้ข้อมูลกลายเป็นความลับ เพราะมันอ่านไม่ออกนั่นเอง โดยให้จำง่ายๆว่ามันมี 2 แบบคือ กับ
เวทมนต์ที่ทำให้ HTTPS ถูกป้องกันไม่ให้มีคนมาแอบแซกแซงได้นั้นคือ ให้คู่สนทนาทั้ง 2 ฝั่งตรวจสอบซึ่งกันและกันก่อนที่จะคุยความลับกัน โดยเราเรียกมันว่า 🤝 การจับมือ หรือ 🤝 Handshake ซึ่งรายละเอียดของมันจริงๆค่อนข้างเยอะและซับซ้อนมาก ดังนั้นจะขออธิบายแบบรวบรัดหน่อยนึง (แต่ถ้าอยากดูแบบเต็มให้กดที่ลิงค์นี้ )
ตัวใบรับรอง (Certificate) แต่ละอันจะมี ฝั่ง 3rd party ทำหน้าที่ในการตรวจสอบความถูกอีกที เพื่อรองรับว่า Certificate นั้นถูกต้องหรือไม่ โดยเจ้าสิ่งนี้เราเรียกว่า Certificate Authority หรือ CA นั่นเอง ซึ่งโดยปรกติจะมีมาตรฐานที่ชื่อว่า เอาไว้ควบคุมว่า เช่น CA ไหนได้รับการยอมรับแล้ว หรือ CA ไหนโดนเพิกถอนการยอมรับ เพราะอาจจะหมดอายุหรือประพฤติไม่เหมาะสมก็จะไม่เชื่อใจ CA พวกนั้นอีกต่อไป
ตัว Certificate ที่ส่งมาให้เราตรวจ มันมาเป็นชุด โดยแต่ละใบรับรองจะถูกสร้างจากใบก่อนหน้าลิงค์กันมาเรื่อยๆ เราเรียกตัวนี้ว่า เพราะใบแต่ละใบสามารถพิจูนจ์ได้ว่าใครเป็นคนสร้างและใบก่อนหน้าคืออะไร ซึ่งใบแรกเริ่มเราจะเรียกมันว่า Root Certificate หรืออีกชื่อของมันคือ ตามรูปเลย
จากที่ร่ายมายาวเหยียดเราก็พอจะเห็นภาพคร่าวๆแล้วว่าการทำ HTTPS จะช่วยให้ป้องกันการโจมตีแบบ ได้ แต่ตัวมันเองนั้นก็มีจุดอ่อนเช่นกัน ดังนั้นมาไล่กันแบบคร่าวๆดีกั่ว
ตัวมาตรฐานในการดูแลเรื่อง CA หรือที่เราเรียกว่า นั้นมีช่องโหว่อยู่ที่ CA สามารถออก Certificate ให้ Domain ไหนก็ได้ ซึ่งโดยปรกติเขาก็จะตรวจความถูกต้องต่างๆนาๆก่อนที่จะออกใบรับรองแหละ แต่จะเกิดอะไรขึ้นถ้า CA ตั้งใจจะโกงเอง? CA ตรวจสอบผิดพลาดหรือถูกหลอก? หรือซ้ำร้ายไปกว่านั้นคือโดนโจมตีใน DNS ว่า domain นั้นยังไม่ถูกจอง หรือตัว domain พลาดในการตรวจสอบเสียเอง
หากมีเนื้อหาในจุดไหนผิดพลาด ตกหล่น หรืออ่านแล้วไม่ชอบ อยากหอมแก้มแมวน้ำ ก็ไปติดตามต่อได้ที่เพจ ได้เบย จะได้คุยกันต่อ และไม่พลาดอัพเดทใหม่กันฮ๊าฟ
