HTTPS in a nutshell

🤔 ไม่ได้ปลอดภัยเหมือนที่เราคิด อธิบายหมดเปลือกแบบภาษาชาวบ้าน

😥 ปัญหา

เวลาที่เราเข้าเว็บอะไรก็ตามที่ต้องใส่ ข้อมูลบัตรเครดิต หรือ ข้อมูลที่เราไม่อยากให้ใครรู้ เราจะมั่นใจได้ไงว่า ข้อมูลของเราโดนส่งให้คนรับถูกคน? และ ไม่มีคนอื่นแอบอ่านข้อมูลลับของเราอยู่?

แนะนำให้อ่าน บทความนี้เป็นส่วนหนึ่งของคอร์ส 👦 Security พื้นฐาน ถ้าเพื่อนๆสนใจอยากรู้หลักในการรักษาความปลอดภัยตั้งแต่เริ่มต้นเลย ก็กดอ่านที่ตัวสีฟ้าๆได้เลยนะ

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

แอบอ่านระหว่างทาง ทำให้คนร้ายเห็นความลับทุกอย่างที่ส่งออกไป เช่น ข้อมูลบัตรเครดิต รหัสผ่าน รหัสประชาชน หรืออะไรก็ตามแต่ที่เราไม่อยากให้เขารู้

ปลอมเป็นผู้รับ โดยคนร้ายหลอกว่าฉันนี่แหละคือคนที่เธอต้องการคุยด้วย แล้วเมื่อคนร้ายได้ความลับของเรามา คนร้ายจะสามารถเปลี่ยนแปลงคำสั่งของเราได้อีกด้วย เช่น เราสั่งโอนเงิน 100 บาท ไปบัญชี A เมื่อคนร้ายเห็นก็หวานหมูเลย เพราะเขาอาจจะแก้คำสั่งของเราเป็น เราสั่งโอนเงิน 100,000 บาท ไปบัญชีคนร้ายแทน ทำให้ตัวนี้ร้ายแรงกว่าแบบแรกอีก

การโจมตีแบบนี้จริงๆมีตัวอย่างอีกหลายแบบมาก ซึ่งส่วนใหญ่คนร้ายจะแอบเข้ามาอยู่ตรงกลางระหว่างเรากับเซิฟเวอร์ ดังนั้นเราเลยนิยมเรียกการโจมตีพวกนี้ว่า Man-in-the-middle Attack หรือ MITM งุยล่า (จริงๆวิธีการโจมตีแต่ละแบบก็จะมีชื่อเรียกของมันอยู่นะ)

😄 วิธีแก้ปัญหา

ปัญหาเกิดจากคนร้ายแอบเสียบตัวเองเข้ามาคั่นการสนทนา ดังนั้นเราก็แค่ ใส่เกราะป้องกันช่องทางการสนทนา เพียงแค่นี้คนร้ายก็จะแอบแทรกระหว่างกลางไม่ได้แล้วนั่นเอง

วิธีการใส่เกราะป้องกันมีหลายวิธี แต่วิธีที่นิยมและใช้กันแพร่หลายที่สุดคือการทำ HTTPS ไงล่ะ แต่ว่า หลายคนเข้าใจผิดคิดว่าแค่ใส่ HTTPS เข้าไปอย่างเดียวมันจะปลอดภัย ซึ่งจริงๆมันไม่ใช่แบบนั้น เพราะอย่างที่บอกของทุกอย่างย่อมมีรูรั่วอยู่เสมอ ซึ่ง HTTPS ก็มีเช่นกัน

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

🔥 Http vs Https

เวลาที่เราเข้าเว็บอะไรก็ตามเราจะเห็นตัวเว็บขึ้นต้นด้วย http:// หรือไม่ก็ https://อยู่เสมอชิมิ นั่นคือหนึ่งในช่องทางที่ให้คอมมันคุยกันได้ ซึ่งสิ่งสำคัญที่เราต้องรู้คือ

HTTP

เจ้าตัว http (ย่อจาก HyperText Transfer Protocol) เวลามันส่งข้อมูลออกไป ข้อมูลพวกนั้นจะเป็นข้อความธรรมดา (Plain Text) นั่นหมายความว่า ถ้ามีคนใช้โปรแกรมดักจับข้อมูล (Packet Sniffer) แล้วจับข้อมูลของเราได้ เขาก็จะอ่านทุกอย่างที่เราส่งออกไปได้นั่นเอง

สมมุติว่าเราส่งข้อความจีบสาวด้วย HTTP ธรรมดาละก็ ฟามลับก็อาจจะไม่ใช่ฟามลับอีกต่อปาย

ซ้ำร้ายกว่านั้นด้วย HTTP ธรรมดา เราจะไม่รู้เลยว่าอีกฝั่งที่เราคุยด้วย ใช่คนๆนั้นจริงๆหรือเปล่า

HTTPS

เจ้าตัว https (ย่อจาก HyperText Transfer Protocol Secure) ซึ่งเวลามันส่งข้อมูลออกไป ข้อมูลพวกนั้นจะถูกเข้ารหัสลับที่ทำให้ไม่สามารถอ่านได้เอาไว้ ซึ่งจะมีแค่คนที่มีกุญแจลับเท่านั้นถึงจะอ่านมันออก และโดยปรกติกุญแจลับจะอยู่กับคู่สนทนาทั้ง 2 ฝั่งเท่านั้น

แถมเจ้า HTTPS ยังช่วยตรวจให้ว่า ฝั่งที่คุยด้วยเป็นคนที่เราอยากจะคุยด้วยจริงๆอะป่าว ดังนั้นคนร้ายไม่มีโอกาสแทรกเข้ามาเบย

โว้วๆๆๆๆ เหมือนเจ้า HTTPS จะเป็นดุจบร๊ะเจ้าเลยนิ แล้วไหงว่ามันมีข้อเสียอ่ะ? งั้นเราลองซูมเข้าไปดูการทำงานลึกๆของมันต่อดีกั่ว

🔐 SSL/TLS

เจ้า HTTPS มันมีหน้าที่ป้องกันการคุยกันให้เรา โดยเบื้องหลังของมันคือสิ่งที่เรียกว่า SSL/TLS โดยในตอนแรกมันใช้ชื่อว่า SSL ย่อจาก Secure Sockets Layer แล้วก็ถูกอัพเกรดมาเรื่อยๆ ปัจจุบันมันชื่อว่า TLS ย่อจาก Transport Layer Security นั่นเอง ซึ่งเราจะเจอคำว่า SSL/TLS ตลอดเวลาแม้ว่า SSL จะตกยุคไปแล้วก็ตาม เพราะในวงการ Security นั้นมันมีการเปลี่ยนแปลงบ่อยมาก มันต้องไล่อุดรูรั่วตลอดเวลา ดังนั้นไม่ต้องแปลกใจที่จะเห็นคนบางกลุ่มยังใช้ของที่มันไม่ปลอดภัยแล้ว หรือใช้ยังวิธีการแบบเก่าๆอยู่ และบ่อยครั้งที่จะเจอว่าวันนี้บอกว่าใช้ตัวนี้ แล้วผ่านไปซักพักก็จะบอกว่าอย่าใช้ตัวนั้นนะ ดังนั้นจำไว้เลยวงการนี้ไม่แน่นอนต้องตามอัพเดทตลอด โดย TLS ล่าสุดคือเวอร์ชั่น 1.3

แนะนำให้อ่าน หากใครสนใจอยากรู้หลักการทำงานแบบเจาะลึกแบบฝุดๆ ให้ไปอ่านที่ลิงค์นี้ได้เลย The Transport Layer Security (TLS) Protocol Version 1.3

🤫 กุญแจลับ

เพื่อให้เข้าใจ TLS เราจำเป็นต้องเข้าใจเรื่อง 🔑 กุญแจลับ ที่ใช้ในการเข้ารหัสเพื่อทำให้ข้อมูลกลายเป็นความลับ เพราะมันอ่านไม่ออกนั่นเอง โดยให้จำง่ายๆว่ามันมี 2 แบบคือ Symmetric Key กับ Asymmetric Key

🔑 Symmetric Key

Symmetric Key หรือ กุญแจสมมาตร เป็นกุญแจที่สามารถใช้ได้ทั้ง เข้ารหัส และ ถอดรหัส ภายในดอกเดียวกัน ซึ่งถ้าเราเข้ารหัสด้วยกุญแจที่เป็น Symmetric ดอกไหนไป เมื่อจะถอดรหัสก็ต้องใช้กุญแจดอกเดิมในการถอดรหัสเท่านั้น ตามรูปด้านล่าง

เกร็ดความรู้ ปรกติ Symmetric Key นั้นควรจะมีความยาวขั้นต่ำที่ 128 bits แต่ถ้าจะให้ดีควรเป็น 256 bits ซึ่งในปัจจุบันถ้ามันต่ำกว่า 80 bits ในวงการ security ถือว่าไม่ปลอดภัยแล้ว

🔑 Asymmetric Key

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 อยู่ตลอดเวลาถ้าไม่จำเป็นนั่นเอง

ซึ่งเจ้าพวกกุญแจพวกนี้ถ้าเปิดดูมันก็จะเป็นตัวอักษรยึกๆยือๆอ่านไม่ออก ตามตัวอย่างด้านล่าง

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20200923"
AAAAB3NzaC1yc2EAAAABJQAAAQEAth/DV1CxXjus3l64YMz3kMsvpOzXbh0acKNh
XxVap3WtUvpeYI3Gk+4h4iEsVurAwRpKt4xq5aeKDG9u+5A0PiB9TFz0GUcIASey
dzwidLMOKxeQvF81ebyZQL7FLVUtjrS8ZDwa3t8SkCFbtkiaMcw40n4Q+THCcIGy
rmr/dCKEZS49GtpJrgTMO44z4JY6mvtBUmNLvk6aDtMsJi0MjnUUkoaaXPMpBrrm
svt40q5gL9a/vuA9+oMbtpnXm/QScz2yKmupE9MqQGKNsaO8f5MIBhMlGkZx6iq/
/8wCRIyAJGcyw8HxbKd5MM1LW5BZ8yci93iYtKoqAQkLL75u4Q==
---- END SSH2 PUBLIC KEY ----

🤔 TLS ทำงานไง?

เวทมนต์ที่ทำให้ HTTPS ถูกป้องกันไม่ให้มีคนมาแอบแซกแซงได้นั้นคือ ให้คู่สนทนาทั้ง 2 ฝั่งตรวจสอบซึ่งกันและกันก่อนที่จะคุยความลับกัน โดยเราเรียกมันว่า 🤝 การจับมือ หรือ 🤝 Handshake ซึ่งรายละเอียดของมันจริงๆค่อนข้างเยอะและซับซ้อนมาก ดังนั้นจะขออธิบายแบบรวบรัดหน่อยนึง (แต่ถ้าอยากดูแบบเต็มให้กดที่ลิงค์นี้ TLS Protocal)

อธิบายขั้นตอนทั้งหมด 🤠 ขั้นตอนทั้งหมดอย่างน้อยควรจะอ่านถึงข้อ 3 ก็จะพอเข้าใจประเด็นคร่าวๆเพื่อไปหัวข้อถัดไปได้ละ แต่ถ้าสนุกจะอ่านจนจบเลยกะได๊ โดยเริ่มต้นที่ฝั่งอัศวิน (Client) ที่ต้องการคุยกับเจ้าหญิง (Server) มันจะต้องทำขั้นตอนตามนี้

  1. ฝ่ายที่ต้องการคุย (อัศวิน) จะเป็นฝ่ายเริ่มก่อนโดยส่ง TLS เวอร์ชั่นของตัวเอง และ รูปแบบการเข้ารหัสที่ตัวเขารองรับ (Cipher Suites) ไปให้อีกฝั่ง โดยขั้นตอนนี้เราเรียกว่า Client Hello

  2. ฝั่งเจ้าหญิงรู้ว่ามีคนอยากคุยด้วย ก็จะเลือกว่าตัวเองควรจะเข้ารหัสแบบไหนดี เพื่อจะได้สะดวกทั้งสองฝั่ง ซึ่งเมื่อเลือกได้ก็จะส่งใบรับรอง (Certificate) ว่าฉันเป็นเจ้าหญิงที่เธอต้องการคุยด้วยจริงๆนะกลับไป ซึ่งภายในนั้นจะมี 🔑 Public key อยู่ โดยขั้นตอนนี้เราเรียกว่า Server Hello

  3. เมื่ออัศวินได้รับข้อความตอบกลับมา ก็จะเอาใบรับรองมาตรวจ (Certificate) ไปดูว่าใช่เจ้าหญิงคนที่จะคุยจริงๆป่ะ ซึ่งถ้าตรวจแล้วถูกต้อง อัศวินก็จะสร้างกุญแจ 🔑 Premaster secret ขึ้นมา

  4. ตัวอัศวินก็จะนำ 🔑 Public Key ที่ได้จากขั้นตอนที่ 2 ไปเข้ารหัสตัว 🔒 Premaster secret ทำให้มันอ่านไม่ออก แล้วค่อยส่งไปให้อีกฝั่ง เราเรียกขั้นตอนนี้ว่า Key Exchange

  5. ฝั่งเจ้าหญิงเมื่อได้รับข้อมูลมา ก็จะเอา 🔑 Private Key ของตัวเองไปถอดรหัสตัว Premaster secret ออกมา แล้วนำข้อมูลทั้งหมดที่เคยคุยกันไปสร้างสิ่งที่เรียกว่า 🔑 Session Key

  6. ตอนนี้เจ้าหญิงมีกุญแจลับที่เอาไว้เข้ารหัสละ ดังนั้นฝั่งเจ้าหญิงก็จะลองส่งข้อความที่เข้ารหัสไปทดสอบฝั่งอัศวิน เพื่อทดสอบว่าเขาสามารถสร้างกุญแจลับแบบเดียวกันได้หรือเปล่า

  7. เมื่ออัศวินได้รับข้อความลับมา เขาก็ต้องสร้างกุญแจลับ (🔑Session Key) ด้วยวิธีการเดียวกับที่ฝั่งเจ้าหญิงทำ เพื่อจะได้อ่านข้อความของเจ้าหญิง แล้วตอบกลับไปได้ว่าฉันอ่านเธอรู้เรื่องนะ

  8. อัศวินทำการตอบข้อความเจ้าหญิงกลับไป โดยเข้ารหัสด้วยกุญแจที่พึ่งสร้าง ซึ่งถ้าเจ้าหญิงได้รับ และสามารถอ่านรู้เรื่อง ก็จะเป็นการยืนยันว่าทั้ง 2 ฝั่งสามารถคุยกันได้โดยที่ไม่มีคนแอบอ่านข้อความของทั่ง 2 ฝั่งได้ละนั่นเอง

จากกระบวนการทั้งหมดมันจะทำให้มันตรวจสอบได้ว่า ฝั่งที่คุยด้วยเป็นคนที่เราอยากคุยด้วยจริงๆหรือเปล่า (โดยการตรวจ Certificate) และ มีแค่คู่สนทนานี้เท่านั้นที่จะคุยกันรู้เรื่อง (เพราะคนอื่นไม่มีกุญแจเอาไว้ถอดรหัส) แต่ก็ยังมีคำถามต่อว่า เราจะเชื่อตัวใบรับรอง (Cerificate) ที่ส่งมาจากขั้นตอนที่ 3 ได้ยังไง? เพราะถ้ามันเป็นของปลอม เราก็จะถูกหลอกทำ TLS กับคนที่เราไม่ได้อยากคุยด้วยได้ง่ายๆเลยนั่นเอง ดังนั้นเราก็ต้องรู้จักกับสิ่งที่เรียกว่า CA ต่อนั่นเอง

เกร็ดความรู้ การสร้างกุญแจลับสามารถทำได้หลายแบบ และหนึ่งในนั้นคือการใช้ข้อมูลที่เรามีไปสร้างกุญแจลับอันใหม่ และเราเรียกมันว่าการทำ Key Derivation ซึ่งปรกติถ้าเราใช้ ข้อมูลเดียวกันไปสร้างกุญแจลับอันใหม่ เราก็จะได้กุญแจลับแบบเดียวกันออกมา ดังนั้นในรูปด้านบน ขั้นตอนที่ 5 กับ 7 เมื่อ Client กับ Server มีข้อมูลเหมือนกัน และทั้ง 2 ฝั่งก็รู้ว่าจะใช้ Key Derivation แบบไหน ดังนั้นทั้ง 2 ฝั่งก็จะสามารถสร้าง Session Key ออกมาได้เป็นตัวเดียวกันนั่นเอง

🗃️ Certificate Authority

ตัวใบรับรอง (Certificate) แต่ละอันจะมี ฝั่ง 3rd party ทำหน้าที่ในการตรวจสอบความถูกอีกที เพื่อรองรับว่า Certificate นั้นถูกต้องหรือไม่ โดยเจ้าสิ่งนี้เราเรียกว่า Certificate Authority หรือ CA นั่นเอง ซึ่งโดยปรกติจะมีมาตรฐานที่ชื่อว่า X.509 เอาไว้ควบคุมว่า เช่น CA ไหนได้รับการยอมรับแล้ว หรือ CA ไหนโดนเพิกถอนการยอมรับ เพราะอาจจะหมดอายุหรือประพฤติไม่เหมาะสมก็จะไม่เชื่อใจ CA พวกนั้นอีกต่อไป

ตัว Certificate ที่ส่งมาให้เราตรวจ มันมาเป็นชุด โดยแต่ละใบรับรองจะถูกสร้างจากใบก่อนหน้าลิงค์กันมาเรื่อยๆ เราเรียกตัวนี้ว่า Chain-of-trust เพราะใบแต่ละใบสามารถพิจูนจ์ได้ว่าใครเป็นคนสร้างและใบก่อนหน้าคืออะไร ซึ่งใบแรกเริ่มเราจะเรียกมันว่า Root Certificate หรืออีกชื่อของมันคือ Trust Anchor ตามรูปเลย

เมื่อฝั่งอัศวินได้รับ Chain-of-trust มาก็จะ ตะกุยหา Root Certificate ว่ามีคนรับรองที่ถูกต้องหรือเปล่า ซึ่งหาก Root มีคนรับรองที่ถูกต้องก็หมายความว่า สามารถเชื่อใจได้ว่าอีกฝั่งคือคนที่เราอยากคุยด้วยจริงๆตามรูปด้านล่าง

ตัว Certificate แต่ละใบจะถูกเข้ารหัสจาก Certificate ก่อนหน้า และมีการอ้างถึงใบที่สร้างมัน ทำให้เราสามารถเช็คย้อนกลับไปหา Root ได้ ตามโครงสร้างด้านล่าง

ดังนั้นเมื่อคนร้ายแอบปลอมตัวมา โดยทั่วไปคนร้ายจะไม่มี Certificate ที่ถูกยอมรับ ดังนั้นเขาก็จะต้องสร้าง Ceritifcate ของเขาเอง ดังนั้นในกระบวนการตรวจสอบก็จะแจ้งเตือนว่ามันไม่เป็นที่ยอมรับนะ นี่เลยเป็นหนึ่งในเหตุผลที่ Self-Sign ที่เราทำเองเซ็นเองถึงโดนแจ้งเตือนไปด้วย ตามรูปด้านล่าง

Self-Sign คือการออกใบรับรองเองเซ็นเอง ไม่ได้มีใครที่ไหนมารับรู้และยอมรับให้นั้น ปรกติเราจะ ใช้แค่ภายในของเราเอง หรือ ใช้ทดสอบ Security Development เท่านั้น ไม่เหมาะสมที่จะเอาไปใช้ในวงที่เป็น Public เพราะใครก็ปลอมเป็นคุณได้

โดยปรกติเวลาที่เราเข้าเว็บอะไรก็ตาม เจ้าตัว Web Browser ก็จะมีการบอกอยู่แล้วว่าปลอดภัยหรือเปล่า โดยมีรูปสัญลักษณ์ 🔒 กุญแจอยู่ ซึ่งเราสามารถกดเข้าไปดูรายละเอียดได้ เช่น Encryption ที่ใช้ ตัว Certificate ต่างๆที่ส่งมาตามรูปด้านล่างนั่นเอง

😷 จุดอ่อน

จากที่ร่ายมายาวเหยียดเราก็พอจะเห็นภาพคร่าวๆแล้วว่าการทำ HTTPS จะช่วยให้ป้องกันการโจมตีแบบ Man-in-the-middle Attack ได้ แต่ตัวมันเองนั้นก็มีจุดอ่อนเช่นกัน ดังนั้นมาไล่กันแบบคร่าวๆดีกั่ว

📜 X.509 PKI

ตัวมาตรฐานในการดูแลเรื่อง CA หรือที่เราเรียกว่า X.509 PKI นั้นมีช่องโหว่อยู่ที่ CA สามารถออก Certificate ให้ Domain ไหนก็ได้ ซึ่งโดยปรกติเขาก็จะตรวจความถูกต้องต่างๆนาๆก่อนที่จะออกใบรับรองแหละ แต่จะเกิดอะไรขึ้นถ้า CA ตั้งใจจะโกงเอง? CA ตรวจสอบผิดพลาดหรือถูกหลอก? หรือซ้ำร้ายไปกว่านั้นคือโดนโจมตีใน DNS ว่า domain นั้นยังไม่ถูกจอง หรือตัว domain พลาดในการตรวจสอบเสียเอง

🤝 Pre-Handshake

กระบวนการทั้งหมดถ้าการจับมือเสร็จสิ้นไปแล้วนับแทบจะพูดได้ว่าโดนโจมตีไม่ได้เลยก็ได้ นอกจากตัว client/server โดนโจมตีภายในทำให้ secret หลุดไป ซึ่งคนร้ายก็รู้ดีว่าการโจมตีแบบนั้นไม่ใช่เรื่องง่าย ดังนั้นสิ่งที่เขาจะเลือกทำก็คือ หลอกฝั่ง Client ก่อนที่จะทำ Handshake เพราะมันง่ายกว่าวิธีแรกมาก

💣 Client-Side

เนื่อจากการโจมตีฝั่ง Server ไม่ใช่เรื่องง่ายเลย แต่การโจมตีฝั่ง Client นั้นกลับทำได้ง่ายเสียกว่า เพราะโดยปรกติฝั่ง Client จะไม่ค่อยระวังตัว ชอบทำอะไรเปิ่นๆ ติดตั้งโปรแกรมมั่วซั่ว เข้า Wifi สาธารณะ ดังนั้นการโจมตีฝั่ง client เพื่อไปเอา secret หรือดักจับข้อมูลต่างๆจะทำได้ง่ายกว่า และที่สำคัญโปรแกรมส่วนใหญ่ที่อยู่ในตัว client นั้นจะเก็บรักษาของที่เป็น security ได้ค่อนข้างยาก และคนส่วนใหญ่ที่ไม่ได้ระวังก็อาจจะเอา secret data ไปเก็บไว้ในของที่ไม่สมควร เช่น cookie (ต่อให้เป็น secure cookie ก็ยังมีประเด็น) ดังนั้นให้ระวังฝั่ง client ไว้ให้ดี

🎯 บทสรุป

จากทั้งหมดที่เขียนไว้ก็น่าจะพอเข้าใจการทำงานของ HTTPS มากขึ้นแล้วชิมิ? ดังนั้นเมื่อไหร่ก็ตามที่เราจะต้องส่งข้อมูลที่มีความลับ หรือที่เราเรียกกันว่า Sentitive Information ไปหาใครก็ตาม เราควรจะต้องทำผ่าน HTTPS เพื่อป้องกันคนแอบเข้ามาป่วนเรานั่นเอง แต่ไม่ใช่แค่เราใช้ HTTPS แล้วก็จะนอนตีพุงสบายใจแฮได้นะ เพราะการจัดการที่ฝั่ง Client ก็มีผลสูงมากเหมือนกัน ซึ่งอย่างที่บอกไปว่า เหล่าคนร้ายเลือกที่จะโจมตี Client ก่อนเสมอ เพราะมันง่ายงุยล่ะ

หากมีเนื้อหาในจุดไหนผิดพลาด ตกหล่น หรืออ่านแล้วไม่ชอบ อยากหอมแก้มแมวน้ำ ก็ไปติดตามต่อได้ที่เพจ Facebook Mr.Saladpuk ได้เบย จะได้คุยกันต่อ และไม่พลาดอัพเดทใหม่กันฮ๊าฟ

Last updated