Archive for the ‘Security’ Category

0216 | ความเข้าใจผิดเกี่ยวกับ SSL

Friday, August 7th, 2015 Posted in IP Network, Security | No Comments »

บางครั้งการเห็นอะไรจากประโยคโฆษณาก็ทำให้เราเข้าใจผิดกันได้ครับ ที่สำคัญคือประโยคโฆษณาส่วนมากจะสั้นๆ อ่านแล้วชวนให้เคลิ้ม แต่เบื้องหลังมันมีอะไรมากกว่านั้นอีกเยอะ

SSL ช่วยให้เว็บไม่โดน hack

  • ไม่จริง !
  • SSL มีประโยชน์แค่ “การป้องกันการดักข้อมูล” เท่านั้นครับ เนื่องจากโดยปกติการรับส่งข้อมูลบนอินเทอร์เน็ตจะไม่ได้เข้ารหัสไว้ ทำให้ใครที่อยู่ระหว่างทางก็สามารถอ่านข้อมูลข้างในได้ว่าเรารับ/ส่งอะไรกัน
  • การดักข้อมูล ในแง่นึงถ้าดักได้รหัสผ่าน admin ก็ทำให้บุกรุกเข้าระบบได้ก็จริง แต่ส่วนใหญ่ hacker ไม่ได้มานั่งดักข้อมูลหรอกครับ มันยากมากเพราะต้องไปอยู่ในเครือข่ายเดียวกับผู้ใช้งาน ซึ่งถ้าอยู่ในเครือข่ายเดียวกันแล้ว ต่อให้ติด SSL ไปก็ช่วยอะไรได้ไม่มากครับ
  • 90% ของการโดนเจาะเกิดจากเว็บไซต์มีช่องโหว่เอง ซึ่ง SSL ไม่ได้ช่วยอะไร เพราะ hacker ก็ยังสามารถเข้าเว็บผ่าน SSL ได้ตามปกติ และ SSL ไม่ได้มีประโยชน์ในการช่วยป้องกันช่องโหว่พวกนั้นครับ

SSL ยิ่งแพงยิ่งปลอดภัย

  • ไม่จริง !
  • ราคาถูกแพงมีผลแค่เรื่องความน่าเชื่อถือ เนื่องจากใบ certificate ที่แพงกว่ามักจะใช้วิธีการตรวจสอบยืนยันตัวตนที่เข้มงวดกว่า แง่นี้รวมถึง EV SSL green bar แบบที่เว็บธนาคารใช้ด้วย
  • วิธีการเข้ารหัส (ซึ่งก็คือความปลอดภัยของข้อมูล) ขึ้นอยู่กับการคุยกันระหว่าง client กับ server ตอนเชื่อมต่อเข้าหากัน ซึ่งสามารถตั้งค่าได้ทุกแบบ ไม่ได้ถูกจำกัดด้วยใบ certificate แต่อย่างใด

SSL ให้เป็น https แบบไหนก็ปลอดภัยต่อการถูกดักฟัง

  • ไม่จริง ! (อ้าว)
  • วิธีการเข้ารหัสหลายตัวได้ถูกพิสูจน์แล้วว่าปลอดภัยต่ำ ง่ายต่อการโจมตีและการถอดรหัส
  • SSLv3 ก็เพิ่งโดนเจาะไปไม่นาน
  • การเข้ารหัสแบบ RC4 ก็มีรายงานจุดอ่อนออกมาเรื่อยๆ จนตอนนี้มีประกาศไม่แนะนำให้ใช้งานขึ้นมาแล้ว
  • การตั้งค่าการเข้ารหัสบน server จึงต้องระบุด้วยว่า ยอมให้ใช้วิธีการเข้ารหัสแบบที่ (ยังคง)ปลอดภัย และติดตามข่าวสารช่องโหว่และความปลอดภัยเกี่ยวกับ SSL เสมอ

Tags: ,

0199 | อีกขั้นของความปลอดภัยกับ HTTPS Certificate Pinning

Tuesday, January 13th, 2015 Posted in IP Network, Security | No Comments »

เชื่อว่าคนที่ตามอ่านบล็อกผม (ที่เป็นบล็อกมีสาระ) คงเป็นคนที่รู้จัก https อยู่บ้างแล้วนะครับ จะได้ไม่ต้องอธิบายซ้ำ ส่วนคนที่อยากรู้ว่ามันคืออะไร ถ้าอยากอ่านเต็มๆ ลองดูตามนี้ครับ

โดยคร่าวๆ คือเชื่อมต่อการสื่อสาร “เพิ่มเติม” จากปกติด้วยโปรโตคอล SSL/TLS ซึ่งประกอบไปด้วยสี่ส่วนประกอบกันคือ

  • กระบวนการแลกเปลี่ยนคีย์สำหรับเข้ารหัส (key exchange)
  • กระบวนการยืนยันตัวตน (certificate validation) ว่าคนที่เรากำลังติดต่อด้วยเป็นตัวจริง
  • กระบวนการเข้ารหัสด้วยคีย์สมมาตร (symmetric key encryption)
  • กระบวนการตรวจสอบความถูกต้อง (hash function)

ทั้งสี่ส่วนนี้เมื่อประกอบกันแล้วจะทำให้การสื่อสารที่ได้ปลอดภัยต่อการดักฟังได้ด้วยกระบวนการเข้ารหัสที่ซับซ้อน (อ่านเพิ่มได้ที่ cloudflare keyless ssl) ร่วมกับการยืนยันตัวตน ซึ่งกระบวนการที่มีจุดอ่อนมากที่สุดคือ ‘กระบวนการยืนยันตัวตน’ จากใบรับรองนี่เอง (certificate) ครับ

ตัวกระบวนการเอง โดยสภาพปกติ (แบบไม่ได้เปิด client certificate validation) เป็นการทำงานที่ฝั่งไคลเอนต์ที่เชื่อมต่อเข้าไป โดยไคลเอนต์จะได้รับข้อมูลใบรับรอง พร้อมลายเซ็นที่ถูกเซ็นด้วยกุญแจลับ (private key) ของเครื่องเซิร์ฟเวอร์ โดยกระบวนการนี้อาศัย “สายการรับรอง” (certificate chain) ว่าใบรับรองนี้ถูกรับรองโดยหน่วยงานใด (A) แล้วหน่วยงานนั้นๆ ถูกรับรองโดยหน่วยงานใด (B) อีกบ้าง ไปเรื่อยๆ จนเจอหน่วยงานที่ฝั่งไคลเอนต์ “รู้จัก และเชื่อถือ” (trusted root)

ตัวอย่างเช่นใบรับรองของ THZ Hosting ที่ได้รับการรับรองจาก Comodo Domain Validation CA ซึ่งถูกรับรองผ่าน Comodo RSA CA โดยมี AddTrust External CA Root เป็นใบรับรองที่ฝั่งไคลเอนต์รู้จักและเชื่อถือ (สังเกตจากคำว่า In trust store)

upic.me

ซึ่งหากใบรับรองดังกล่าวไม่สมบูรณ์ เช่นว่าสายการรับรองขาดหายไป , ไม่รู้จักผู้ออกใบรับรอง , หมดอายุ หรือยังไม่เริ่มอนุญาต , ชื่อไม่ตรงกับเว็บที่เข้า หรือแม้กระทั่งการถูกปลอมใบรับรอง ก็จะทำให้ขึ้นหน้าจอแจ้งเตือนประมาณนี้ เพื่อเตือนให้ผู้ใช้ทราบว่าใบรับรองนั้นมีปัญหาแล้วนะ … (อันนี้ผมจำลองขึ้นมาเฉยๆ นะครับ)

upic.me

แต่สุดท้ายแล้ว ผู้ใช้งานก็ยังสามารถกด “ข้าม” การแจ้งเตือน และยินยอมเชื่อมต่ออย่าง(อาจจะ)ไม่ปลอดภัยต่อไปได้อยู่ดี … และนี่คือจุดอ่อนใหญ่ที่สุดของ HTTPS เลยครับ

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

เบื้องต้นมาตรฐานนี้ยังคงเป็นร่างอยู่ (http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21) แต่สำหรับเว็บไซต์ใหญ่ๆ (เช่น google และ twitter) ในเบราว์เซอร์อย่าง Chrome และ Firefox ก็ได้มีการบังคับผูกใบรับรองไว้ให้เรียบร้อยแล้วครับ ทำให้หากมีการใช้ใบรับรองปลอมกับเว็บดังกล่าวจะถูกขึ้นข้อความแจ้งเตือนและห้ามการเชื่อมต่ออย่างเด็ดขาด เพื่อให้ผู้ใช้ปลอดภัย (แต่เข้าไม่ได้) ไปเลยครับ

Tags: ,