คงไม่มีใครปฏิเสธได้ครับว่า SSL คือเทคโนโลยีหนึ่งที่สำคัญมากแบบขาดเสียไม่ได้ ทั้งในด้านธุรกรรมการเงิน การส่งต่อข้อมูลความลับต่างๆ ซึ่งเหตุผลหลักคือเพื่อป้องกันการโจมตีจากเหล่าบรรดาแฮกเกอร์ แต่เมื่อไม่นานมานี้ได้มีการเปิดเผยว่า SSL เมื่อถูกใช้งานในบางสถานการณ์นั้นอาจไม่ปลอดภัยอย่างที่เคยคิดกัน
เมื่อไม่นานมานี้ได้มีงานประชุม ACM Conference on Computer and Communications Security (CCS2012) ที่จัดเสร็จสิ้นในวันที่ 16-18 ตุลาคมที่ผ่านมา ซึ่งเป็นงานรวมตัวของนักพัฒนาโปรแกรม ผู้เชี่ยวชาญด้านความปลอดภัยทั้งจากภาครัฐ สถานศึกษา และเอกชน ได้เข้ามานำเสนอถึงทฤษฎีหรืองานวิจัยต่างๆ โดยหลังจากจบงานและเปเปอร์งานวิจัยต่างๆ ได้ขึ้นเว็บแล้วที่เว็บของ CCS 2012
ในงานนี้ได้มีงานวิจัยชิ้นหนึ่งที่สำคัญมาก ซึ่งจัดทำโดยนักวิจัยจากมหาวิทยาลัยเทคซัสในเมืองออสตินและมหาวิทยาลัยสแตนฟอร์ด ได้ระบุว่า SSL ที่ไม่ได้มีการใช้งานผ่านเว็บเบราว์เซอร์มีความเสี่ยงจะถูกโจมตีแบบ man-in-the-middle attack ได้ (อ่านคำอธิบายเพิ่มได้ที่ท้ายข่าว) โดยการใช้งานที่ไม่ได้ผ่านเว็บเบราว์เซอร์ ในงานวิจัยได้ยกตัวอย่างดังนี้
- JAVA library ของ Amazon EC2
- SDK ระบบซื้อขายของ Amazon และ Paypal (เฉพาะ Paypal นี้ SDK จะถูกใช้เชื่อมกับ osCommerce, ZenCart, Ubercart และ PrestaShop)
- AdMob ผู้ให้บริการโฆษณาบนมือถือ ที่ Google เป็นเจ้าของ
- ระบบ Mobile Banking ของ Chase.com
- โปรแกรมสำหรับทำ web service ที่เขียนด้วยภาษา JAVA รวมถึง Apache Axis, Axis 2,
Codehaus XFire, และ Pusher library สำหรับ Android - รวมถึงโปรแกรมอะไรก็ตามที่ทำหน้าที่เป็นตัวกลางในการติดต่อผ่าน SSL
อย่างไรก็ตามไม่ได้หมายความว่าโค้ดที่ถูกเขียนบนระบบที่กล่าวมาจะถูกเขียนแบบผิดพลาด ในความเป็นจริงนั้นได้เขียนถูกต้องด้วยซ้ำ แต่เพราะโค้ดดังกล่าวจะมีการติดต่อผ่านไลบรารี่ที่ใช้ควบคุมการส่งข้อมูล เช่น Apache HttpClient หรือ cURL ซึ่งปัญหาเกิดจากนักพัฒนาเกิดความเข้าใจผิดทั้งการกำหนดพารามิเตอร์หรือการตรวจสอบค่าย้อนกลับ ทำให้กระบวนการยืนยัน SSL certificate มักจะล้มเหลวในท้ายที่สุด
เท่าที่ผมอ่านงานวิจัยคร่าวๆ ขอสรุปว่าสำหรับนักพัฒนาโปรแกรมด้วยภาษา JAVA และ PHP ที่ได้มีการใช้งานระบบใดระบบหนึ่งที่ได้กล่าวถึงไปหรือมีการใช้งาน SSL ในกระบวนการติดต่อเบื้องหลัง สมควรอ่านงานวิจัยนี้เพื่อแก้ไขหรือหาทางออก เพราะในงานได้มีบอกไว้ว่าจุดใดคือความเสี่ยงครับ
งานวิจัยดังกล่าวสามารถโหลดอ่านได้ที่นี้ Full paper
ที่มา - The Applied Crypto Group of Stanford University
คำอธิบายเพิ่ม
man-in-the-middle attack เป็นการโจมตีโดยการเบี่ยงเบนการเดินทางของข้อมูลที่ควรจะเดินทางระหว่างคอมพิวเตอร์ผู้ใช้งานกับเครื่องแม่ของผู้ให้บริการ ให้เดินทางมายังเครื่องของแฮกเกอร์แทนด้วยการหลอกทั้งเครื่องผู้ใช้งานและเครื่องแม่ว่าเครื่องตัวเองเป็นเครื่องของอีกฝ่ายที่กำลังติดต่อด้วย เป้าหมายคือการดักจับข้อมูลที่ถูกเข้ารหัสไว้หรือการปลอมแปลงข้อมูลให้ผิดไปจากเดิม
on
ข่าวนี้ผมเขียนตามประสาคนเขียน
EThaiZone Tue, 23/10/2012 - 21:37
ข่าวนี้ผมเขียนตามประสาคนเขียน PHP คล่องแต่ Java อยู่ในระดับถูไถขี่ไคลถลอก สำหรับคนเขียนภาษา JAVA คล่องๆ อ่านเปเปอร์ได้ไงก็พิมพ์บอกบ้างนะครับ
ผมเขียนผิดก็บอกด้วยนะครับ ไม่ได้เขียนข่าวนานมาก
นอกเรื่องนิด..ชื่อคุณคือ
KNPKT Wed, 24/10/2012 - 11:54
In reply to ข่าวนี้ผมเขียนตามประสาคนเขียน by EThaiZone
นอกเรื่องนิด..ชื่อคุณคือ "อิไตโซน" ใช่มั้ยครับ ^o^ (ตัวดุ๊กดิ๊กน่ารักดี)
มันก็คงอ่านได้แบบนั้นครับ
EThaiZone Thu, 10/01/2013 - 07:27
In reply to นอกเรื่องนิด..ชื่อคุณคือ by KNPKT
มันก็คงอ่านได้แบบนั้นครับ (มั้ง?)
เข้าไปอ่านดูละ
lancaster Tue, 23/10/2012 - 21:39
เข้าไปอ่านดูละ นี่มันเป็นความกากของคนเขียน library นี่หว่า
มันพยายามจะ validate
EThaiZone Tue, 23/10/2012 - 21:48
In reply to เข้าไปอ่านดูละ by lancaster
มันพยายามจะ 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).
จะว่าไปแบบนี้ก็เข้าข่าย user
lancaster Tue, 23/10/2012 - 22:50
In reply to มันพยายามจะ validate by EThaiZone
จะว่าไปแบบนี้ก็เข้าข่าย user error นะครับ (user ในที่นี้หมายถึง library user ซึ่งก็คือ developer) เพราะเท่าที่ดู docs ก็ชัดเจนอยู่
ใช่เลย ประเด็นคือผิดตั้งแต่
EThaiZone Tue, 23/10/2012 - 23:01
In reply to จะว่าไปแบบนี้ก็เข้าข่าย user by lancaster
ใช่เลย ประเด็นคือผิดตั้งแต่ SDK เลยน่ะครับ งานนี้ควรย้อนกลับไปคนเขียน SDK ที่ Paypal ที่ Amazon ด้วย
ส่วนเราเป็นคนใช้ SDK ก็ให้ความเชื่อถือมากไปว่าโปรแกรมเมอร์ที่ Paypal ที่ Amazon นั้นจะเก่งจนไม่ผิดพลาด แต่ในความจริงคนทุกคนมันพลาดกันได้
ทำให้ความมั่นคงในการป้องกันข้
sunback Tue, 23/10/2012 - 22:03
อ่านแล้วดูแปลกๆ อาจใช้คำว่า "เมื่อถูกใช้งานในบางสถานการณ์นั้นอาจไม่ปลอดภัยอย่างที่เคยคิดกัน" ก็น่าจะโอเคนะครับ
parameters น่าจะใช้คำไทยทับศัพท์ได้นะครับ
อยู่ๆ
EThaiZone Tue, 23/10/2012 - 22:07
In reply to ทำให้ความมั่นคงในการป้องกันข้ by sunback
อยู่ๆ นึกได้แบบลวกจากคำที่เคยอ่านเจอในหนังสือเกี่ยวกับ security ที่เคยอ่านมาน่ะครับ แต่แบบนี้ก็ดีครับ ชัดเจนได้ใจความ
หลายคนมักจะคิดว่าแค่ใช้ SSL
UltimaWeapon Tue, 23/10/2012 - 22:22
หลายคนมักจะคิดว่าแค่ใช้ SSL ก็ปลอดภัยแล้ว แต่ผิดละ ถ้าใช้ SSL แต่หน้ามืดตามัวกด OK/Add Exception/Ignore/บลาๆ แหลกโดยไม่ดูอะไรก็ไม่ปลอดภัยอยู่ดี
โปรแกรมเมอร์ที่เขียนโค๊ดก็เหมือนกัน เกือบทั้งหมดจะสั่งปิดการ Validation ของ Certificate ทั้งหมด แต่ก็คงจะปรกติ เพราะน้อยคนนักที่จะรู้ว่าใช้ SSL อย่างไรถึงจะปลอดภัย
จริงๆ แล้วการเข้ารหัสเฉยๆ
lew Wed, 24/10/2012 - 08:05
In reply to หลายคนมักจะคิดว่าแค่ใช้ SSL by UltimaWeapon
จริงๆ แล้วการเข้ารหัสเฉยๆ ก็ให้ผลที่ดีมากอยู่แล้วครับ
เรื่องพวกนี้สิ่งสำคัญคือ ความคุ้มค่าในการ hack ครับ เป็นเรื่องทางเศรษฐศาสตร์อีกอย่างหนึ่งด้วย คือถ้าผลประโยชน์มันไม่สูงพอที่จะแฮก โอกาสที่จะโดนแฮกก็จะต่ำลงมาก
ถ้ากรณีเว็บบอร์ด แม้จะไม่มีการ validate ก็ "อาจจะ" ดีพอแล้ว เพราะแอคเคาท์เว็บบอร์ดไม่มีมูลค่าอะไร สร้างความเสียหายได้จำกัด แต่ถ้าเป็นบริการการเงิน ของพวกนี้ละเว้นไม่ได้
ขอถามประสาคนไม่รู้หน่อยครับ
OammieR Wed, 24/10/2012 - 14:21
ขอถามประสาคนไม่รู้หน่อยครับ ถ้าผมใช้งานหน้า https อยู่ ซึ่งจะทำการซื้อสินค้า online โดยใช้รหัสบัตรเครดิต
ถ้าผมใส่ค่าอะไรบางอย่างแล้ว submit ไป (เช่น 1234xxx)
ด้วยการทำงานของ https แล้ว, จะมีการเข้ารหัสก่อนหรือไม่ หรือว่า server จะรู้ว่าเราส่ง 1234xxx มาตรง ๆ เลยครับ?
(กรณีถ้า server รู้ว่าเราส่ง 1234xxx มาตรง ๆ เลย แบบนี้ทางเจ้าของระบบก็สามารถเอารหัสบัตรของเราไปใช้จ่ายได้แบบสบายใจเฉิบเลย ถูกต้องไหมครับ)
SSL
tekkasit Wed, 24/10/2012 - 14:54
In reply to ขอถามประสาคนไม่รู้หน่อยครับ by OammieR
SSL ออกแบบสำหรับป้องกันคนอื่นๆดังฟังข้อมูล และมีพื้นฐานช่วยให้มั่นใจว่าทั้งฝั่งเครื่องแม่ข่ายเป็นตัวจริง (digital certificate)
สำหรับผู้ใช้งาน การใช้ SSL ตั้งใจให้ผู้ประสงค์ร้ายโดยทั่วไปไม่สามารถดังฟังข้อมูลแล้วถอดเอาข้อมูลสำคัญที่ส่งผ่าน เช่น หมายเลขบัตรเครดิต, รหัสผ่าน ไปได้ เพราะเครื่องแม่ข่ายสามารถเห็นเนื้อข้อมูลและสามารถนำข้อมูลพวกนี้ไปใช้งานต่อ เช่นการทำธุรกรรมได้
แต่ก็ไม่ได้หมายความว่าใช้ SSL แล้วจะเป็นยันต์คุ้มภัย นอกจากเจอกรณีผู้ดูแลระบบที่ชั่วร้ายอย่างที่ว่าก็จอด หรืออย่างเจ้าของระบบเก็บข้อมูล sensitive พวกนี้ไว้ตรงๆ ก็ยังมีโอกาสที่มีผู้หวังดีเจาะที่ฐานข้อมูล,หรือเข้าถึง log file ได้อีกต่อหนึ่งครับ
ขอบคุณมากครับ
OammieR Wed, 24/10/2012 - 15:22
In reply to SSL by tekkasit
ขอบคุณมากครับ
ช่วยอธิบายเกี่ยวกับข่าวนี้หน่
pomcoe Tue, 06/11/2012 - 13:15
ช่วยอธิบายเกี่ยวกับข่าวนี้หน่อยได้มั้ยคับ
อยากรู้อะ
แต่อ่านแล้วไม่ค่อยเข้าใจอะคับ อยากให้ระเอียดกว่านี้อะคับ
แบบสรุปก้อได้คับ
พอดีจะเอาไปส่งอาจารย์อะคับ
^^
ช่วยตอบทีคับ
pomcoe Sat, 10/11/2012 - 12:18
In reply to ช่วยอธิบายเกี่ยวกับข่าวนี้หน่ by pomcoe
ช่วยตอบทีคับ
ผมว่าผมเขียนละเอียดพอสำหรับข่
EThaiZone Thu, 10/01/2013 - 07:29
In reply to ช่วยอธิบายเกี่ยวกับข่าวนี้หน่ by pomcoe
ผมว่าผมเขียนละเอียดพอสำหรับข่าวนี้แล้วครับ (ลองอ่านอีกรอบแล้ว)
ถ้าไม่เข้าใจต้องย้อนกลับไปศึกษากระบวนการทำงานของ SSL ครับ