คงไม่มีใครปฏิเสธได้ครับว่า SSL คือเทคโนโลยีหนึ่งที่สำคัญมากแบบขาดเสียไม่ได้ ทั้งในด้านธุรกรรมการเงิน การส่งต่อข้อมูลความลับต่างๆ ซึ่งเหตุผลหลักคือเพื่อป้องกันการโจมตีจากเหล่าบรรดาแฮกเกอร์ แต่เมื่อไม่นานมานี้ได้มีการเปิดเผยว่า SSL เมื่อถูกใช้งานในบางสถานการณ์นั้นอาจไม่ปลอดภัยอย่างที่เคยคิดกัน
เมื่อไม่นานมานี้ได้มีงานประชุม ACM Conference on Computer and Communications Security (CCS2012) ที่จัดเสร็จสิ้นในวันที่ 16-18 ตุลาคมที่ผ่านมา ซึ่งเป็นงานรวมตัวของนักพัฒนาโปรแกรม ผู้เชี่ยวชาญด้านความปลอดภัยทั้งจากภาครัฐ สถานศึกษา และเอกชน ได้เข้ามานำเสนอถึงทฤษฎีหรืองานวิจัยต่างๆ โดยหลังจากจบงานและเปเปอร์งานวิจัยต่างๆ ได้ขึ้นเว็บแล้วที่เว็บของ CCS 2012
ในงานนี้ได้มีงานวิจัยชิ้นหนึ่งที่สำคัญมาก ซึ่งจัดทำโดยนักวิจัยจากมหาวิทยาลัยเทคซัสในเมืองออสตินและมหาวิทยาลัยสแตนฟอร์ด ได้ระบุว่า SSL ที่ไม่ได้มีการใช้งานผ่านเว็บเบราว์เซอร์มีความเสี่ยงจะถูกโจมตีแบบ man-in-the-middle attack ได้ (อ่านคำอธิบายเพิ่มได้ที่ท้ายข่าว) โดยการใช้งานที่ไม่ได้ผ่านเว็บเบราว์เซอร์ ในงานวิจัยได้ยกตัวอย่างดังนี้
อย่างไรก็ตามไม่ได้หมายความว่าโค้ดที่ถูกเขียนบนระบบที่กล่าวมาจะถูกเขียนแบบผิดพลาด ในความเป็นจริงนั้นได้เขียนถูกต้องด้วยซ้ำ แต่เพราะโค้ดดังกล่าวจะมีการติดต่อผ่านไลบรารี่ที่ใช้ควบคุมการส่งข้อมูล เช่น Apache HttpClient หรือ cURL ซึ่งปัญหาเกิดจากนักพัฒนาเกิดความเข้าใจผิดทั้งการกำหนดพารามิเตอร์หรือการตรวจสอบค่าย้อนกลับ ทำให้กระบวนการยืนยัน SSL certificate มักจะล้มเหลวในท้ายที่สุด
เท่าที่ผมอ่านงานวิจัยคร่าวๆ ขอสรุปว่าสำหรับนักพัฒนาโปรแกรมด้วยภาษา JAVA และ PHP ที่ได้มีการใช้งานระบบใดระบบหนึ่งที่ได้กล่าวถึงไปหรือมีการใช้งาน SSL ในกระบวนการติดต่อเบื้องหลัง สมควรอ่านงานวิจัยนี้เพื่อแก้ไขหรือหาทางออก เพราะในงานได้มีบอกไว้ว่าจุดใดคือความเสี่ยงครับ
งานวิจัยดังกล่าวสามารถโหลดอ่านได้ที่นี้ Full paper
ที่มา - The Applied Crypto Group of Stanford University
คำอธิบายเพิ่ม
man-in-the-middle attack เป็นการโจมตีโดยการเบี่ยงเบนการเดินทางของข้อมูลที่ควรจะเดินทางระหว่างคอมพิวเตอร์ผู้ใช้งานกับเครื่องแม่ของผู้ให้บริการ ให้เดินทางมายังเครื่องของแฮกเกอร์แทนด้วยการหลอกทั้งเครื่องผู้ใช้งานและเครื่องแม่ว่าเครื่องตัวเองเป็นเครื่องของอีกฝ่ายที่กำลังติดต่อด้วย เป้าหมายคือการดักจับข้อมูลที่ถูกเข้ารหัสไว้หรือการปลอมแปลงข้อมูลให้ผิดไปจากเดิม
Comments
ข่าวนี้ผมเขียนตามประสาคนเขียน PHP คล่องแต่ Java อยู่ในระดับถูไถขี่ไคลถลอก สำหรับคนเขียนภาษา JAVA คล่องๆ อ่านเปเปอร์ได้ไงก็พิมพ์บอกบ้างนะครับ
ผมเขียนผิดก็บอกด้วยนะครับ ไม่ได้เขียนข่าวนานมาก
มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB
นอกเรื่องนิด..ชื่อคุณคือ "อิไตโซน" ใช่มั้ยครับ ^o^ (ตัวดุ๊กดิ๊กน่ารักดี)
มันก็คงอ่านได้แบบนั้นครับ (มั้ง?)
มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB
เข้าไปอ่านดูละ นี่มันเป็นความกากของคนเขียน library นี่หว่า
มันพยายามจะ validate อยู่ทุกครั้งที่มีการติดต่อครับ แต่สุดท้ายเกือบทุกครั้งที่ี่มีการติดต่อ มันกลับเลือกจะเพิกเฉยต่อการ validate ไปซะงั้น เป็นการเลือกแบบไม่ให้ความสำคัญต่อการตรวจสอบ แล้วก็ทำงานอื่นตามปกติครับ
ในงานนี้ยกตัวอย่าง cURL นี้ (ใช้ใน Paypal กับ Amazon)
ตัวเลือก CURLOPT_SSL_VERIFYHOST ซึ่งใช้ยืนยันว่าข้อมูลถูกส่งมาจากโฮสถูกตัวไหม สำหรับโปรแกรมเมอร์หลายคนมักต้องกำหนดค่าเป็น boolean ว่า TRUE แต่ใน cURL กลับกันว่าค่าที่ควรกำหนดเพื่อให้ทำงานคือ 2 พอเรากำหนดเป็น TRUE แปลงเป็น integer ก็ได้ 1 มันก็เลยชิบหายเลยครับ
อันนี้ก็อบจากเว็บ php.net พูดถึงการตั้งค่า CURLOPT_SSL_VERIFYHOST
1 to check the existence of a common name in the SSL peer certificate. 2 to check the existence of a common name and also verify that it matches the hostname provided. In production environments the value of this option should be kept at 2 (default value).
มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB
จะว่าไปแบบนี้ก็เข้าข่าย user error นะครับ (user ในที่นี้หมายถึง library user ซึ่งก็คือ developer) เพราะเท่าที่ดู docs ก็ชัดเจนอยู่
ใช่เลย ประเด็นคือผิดตั้งแต่ SDK เลยน่ะครับ งานนี้ควรย้อนกลับไปคนเขียน SDK ที่ Paypal ที่ Amazon ด้วย
ส่วนเราเป็นคนใช้ SDK ก็ให้ความเชื่อถือมากไปว่าโปรแกรมเมอร์ที่ Paypal ที่ Amazon นั้นจะเก่งจนไม่ผิดพลาด แต่ในความจริงคนทุกคนมันพลาดกันได้
มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB
อ่านแล้วดูแปลกๆ อาจใช้คำว่า "เมื่อถูกใช้งานในบางสถานการณ์นั้นอาจไม่ปลอดภัยอย่างที่เคยคิดกัน" ก็น่าจะโอเคนะครับ
parameters น่าจะใช้คำไทยทับศัพท์ได้นะครับ
อยู่ๆ นึกได้แบบลวกจากคำที่เคยอ่านเจอในหนังสือเกี่ยวกับ security ที่เคยอ่านมาน่ะครับ แต่แบบนี้ก็ดีครับ ชัดเจนได้ใจความ
มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB
หลายคนมักจะคิดว่าแค่ใช้ SSL ก็ปลอดภัยแล้ว แต่ผิดละ ถ้าใช้ SSL แต่หน้ามืดตามัวกด OK/Add Exception/Ignore/บลาๆ แหลกโดยไม่ดูอะไรก็ไม่ปลอดภัยอยู่ดี
โปรแกรมเมอร์ที่เขียนโค๊ดก็เหมือนกัน เกือบทั้งหมดจะสั่งปิดการ Validation ของ Certificate ทั้งหมด แต่ก็คงจะปรกติ เพราะน้อยคนนักที่จะรู้ว่าใช้ SSL อย่างไรถึงจะปลอดภัย
จริงๆ แล้วการเข้ารหัสเฉยๆ ก็ให้ผลที่ดีมากอยู่แล้วครับ
เรื่องพวกนี้สิ่งสำคัญคือ ความคุ้มค่าในการ hack ครับ เป็นเรื่องทางเศรษฐศาสตร์อีกอย่างหนึ่งด้วย คือถ้าผลประโยชน์มันไม่สูงพอที่จะแฮก โอกาสที่จะโดนแฮกก็จะต่ำลงมาก
ถ้ากรณีเว็บบอร์ด แม้จะไม่มีการ validate ก็ "อาจจะ" ดีพอแล้ว เพราะแอคเคาท์เว็บบอร์ดไม่มีมูลค่าอะไร สร้างความเสียหายได้จำกัด แต่ถ้าเป็นบริการการเงิน ของพวกนี้ละเว้นไม่ได้
lewcpe.com, @wasonliw
ขอถามประสาคนไม่รู้หน่อยครับ ถ้าผมใช้งานหน้า https อยู่ ซึ่งจะทำการซื้อสินค้า online โดยใช้รหัสบัตรเครดิต
ถ้าผมใส่ค่าอะไรบางอย่างแล้ว submit ไป (เช่น 1234xxx)
ด้วยการทำงานของ https แล้ว, จะมีการเข้ารหัสก่อนหรือไม่ หรือว่า server จะรู้ว่าเราส่ง 1234xxx มาตรง ๆ เลยครับ?
(กรณีถ้า server รู้ว่าเราส่ง 1234xxx มาตรง ๆ เลย แบบนี้ทางเจ้าของระบบก็สามารถเอารหัสบัตรของเราไปใช้จ่ายได้แบบสบายใจเฉิบเลย ถูกต้องไหมครับ)
SSL ออกแบบสำหรับป้องกันคนอื่นๆดังฟังข้อมูล และมีพื้นฐานช่วยให้มั่นใจว่าทั้งฝั่งเครื่องแม่ข่ายเป็นตัวจริง (digital certificate)
สำหรับผู้ใช้งาน การใช้ SSL ตั้งใจให้ผู้ประสงค์ร้ายโดยทั่วไปไม่สามารถดังฟังข้อมูลแล้วถอดเอาข้อมูลสำคัญที่ส่งผ่าน เช่น หมายเลขบัตรเครดิต, รหัสผ่าน ไปได้ เพราะเครื่องแม่ข่ายสามารถเห็นเนื้อข้อมูลและสามารถนำข้อมูลพวกนี้ไปใช้งานต่อ เช่นการทำธุรกรรมได้
แต่ก็ไม่ได้หมายความว่าใช้ SSL แล้วจะเป็นยันต์คุ้มภัย นอกจากเจอกรณีผู้ดูแลระบบที่ชั่วร้ายอย่างที่ว่าก็จอด หรืออย่างเจ้าของระบบเก็บข้อมูล sensitive พวกนี้ไว้ตรงๆ ก็ยังมีโอกาสที่มีผู้หวังดีเจาะที่ฐานข้อมูล,หรือเข้าถึง log file ได้อีกต่อหนึ่งครับ
ขอบคุณมากครับ
ช่วยอธิบายเกี่ยวกับข่าวนี้หน่อยได้มั้ยคับ
อยากรู้อะ
แต่อ่านแล้วไม่ค่อยเข้าใจอะคับ อยากให้ระเอียดกว่านี้อะคับ
แบบสรุปก้อได้คับ
พอดีจะเอาไปส่งอาจารย์อะคับ
^^
ช่วยตอบทีคับ
ผมว่าผมเขียนละเอียดพอสำหรับข่าวนี้แล้วครับ (ลองอ่านอีกรอบแล้ว)
ถ้าไม่เข้าใจต้องย้อนกลับไปศึกษากระบวนการทำงานของ SSL ครับ
มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB