on
Koen Rouwhorst วิศวกรซอฟต์แวร์ของเว็บ Blendle แกะโปรแกรม NOW TV ของเครือข่าย Sky แล้วพบว่ามีใบรับรองของโดเมน drmlocal.cisco.com พร้อมกับกุญแจลับฝังอยู่ในตัวโปรแกรม แนวทางเช่นนี้ทำให้แฮกเกอร์สามารถสร้างเว็บ https://drmlocal.cisco.com/ ได้เหมือนเป็นเซิร์ฟเวอร์ของซิสโก้เอง และหากมีคุกกี้จากโดเมนอื่นที่ตั้ง scope ไว้เป็น cisco.com แฮกเกอร์ก็จะสามารถดึงคุกกี้ออกไปได้
ผู้ออกใบรับรองนี้คือ HydrantID แม้จะไม่ได้ทำผิดพลาดด้วยตัวเอง แต่ต้องรีบยกเลิกใบรับรองที่รู้ว่ารั่วไหลออกไปแล้วโดยเร็ว ล่าสุด CRL ของ HydrantID ก็ประกาศยกเลิกใบรับรองนี้แล้ว
Rouwhorst ไม่ได้เปิดเผยกุญแจลับออกมาโดยตรง แต่ยืนยันด้วยการสร้างไฟล์ข้อความและไฟล์ลายเซ็นที่ยืนยันความถูกต้องโดยใบรับรองของโดเมน drmlocal.cisco.com ได้
ใบรับรองออกมาตั้งแต่เดือนพฤศจิกายน 2016 หรือประมาณครึ่งปีแล้ว
ที่มา - mozilla.dev.security.policy
ทำไมเค้าถึงต้องติดกุญแจมากับต
KuLiKo Tue, 20/06/2017 - 06:15
ทำไมเค้าถึงต้องติดกุญแจมากับตัวเล่นวิดีโอมาด้วยหรอครับ ใครพออธิบายได้มั้ย แล้วมันหลุดมาแบบไม่ตั้งใจได้ยังไงครับ ผมงงระบบ SSL มาก
น่าจะอิมพลีเมนต์เทสแล้วหลุดหร
Hadakung Tue, 20/06/2017 - 08:36
In reply to ทำไมเค้าถึงต้องติดกุญแจมากับต by KuLiKo
น่าจะอิมพลีเมนต์เทสแล้วหลุดหรือคนเขียนไม่ค่อยเข้าใจระบบครับ เพราะในกระบวนการเข้ารหัสแบบไม่สมมาตร จะมีคู่คีย์ที่เข้ารหัสแล้วจะใช้คู่ตัวเองถอดได้เท่านั้นดังนั้น private keyต้องอยู่เก็บกับเซิร์ฟเวอร์อย่างเดียวเท่านั้น ฝั่งไคเอนต์ไม่มีสิทธิ์ถือคีย์นี้ได้เลยครับ เพราะข้อมูลจะต้องใช้ private key เข้ารหัสแล้วปลายทางถอดด้วย public key เพื่อยืนยันความถูกต้องของข้อมูลเท่านั้นนะครับยังไม่ถึงกระบวนการเข้ารหัสลับข้อมูล
ถ้าเป็นกระบวนการเข้ารหัสลับจะต้องเอา public key ของปลายทางมาเข้ารหัสแล้วส่งให้ปลายทางใช้ private key แกะออก ซึ่งถ้าระบบเป็นการคุยกันระหว่าง server-client ฝั่ง client จะไม่มีคู่คีย์ เพราะ server จะไม่เชื่อถือถือจากไคเอนต์ แต่เซิร์ฟเวอร์จะใช้วิธีส่ง session key มาให้ไคเอนต์แล้วเวลาคุยกันเป็นเข้ารหัสลับจะไคลเอนต์จะใช้ public key ของเซิร์ฟเวอร์ เข้ารหัสตัวเองให้ข้อมูลเป็นความลับ และใช้ session key ที่เป็น private key เข้ารหัสทับอีกครั้งเพื่อยืนยันว่ามาจากไคลเอนต์คนนี้ เพราะเวลาเซิร์ฟเวอร์แกะ จะเอา session key ที่เป็น public key ของไคเอนต์นั้นๆแกะก่อนเพื่อยืนยัว่าข้อมูลมาจากไคเอนต์จริงแล้วค่อยเอา private key ของตนเองแกะข้อมูลมาใช้ครับ
ส่วนเรื่อง SSL ที่งงๆว่าใบ cert คืออะไร จริงๆแล้วใบ cert ก็ใช้การเข้ารหัสแบบไม่สมมาตร(ใช้แบบสมมาตรด้วยแต่ไม่ใช้ก็ได้) แล้วทับกันเป็นทอดๆครับ จาก root แล้วลงมาเป็นลำดับชั้น โดยใบที่ใช้กันเนี่ยจะยืนยันจากใบ cert ที่สูงกว่าขึ้นไปเรื่อยๆจนถึง root ครับ เพราะอุปกรณ์ไคเอนต์ส่วนใหญ่ผู้ผลิตจะเลือกให้เชื่อถือ root มาตรฐานทั่วโลกที่ผ่านมาตรฐานความปลอดภัยอยู่แล้ว
ถ้ายังงที่ผมอธิบายรบกวนมาอ่านต่อครับที่ https://www.blognone.com/node/45433 พิมในมือถือมันยาก
กราบครับ พอจะเข้าใจคร่าวๆ
KuLiKo Tue, 20/06/2017 - 11:55
In reply to น่าจะอิมพลีเมนต์เทสแล้วหลุดหร by Hadakung
กราบครับ พอจะเข้าใจคร่าวๆ แล้ว
ขออนุญาตนะครับ
jedi Wed, 21/06/2017 - 08:28
In reply to น่าจะอิมพลีเมนต์เทสแล้วหลุดหร by Hadakung
ขออนุญาตนะครับ มีแปร่งๆอยู่ในบางจุดครับ เช่น
อันนี้ถ้าหมายถึงใบ cert ฝั่งไคลเอ็นต์นั้น จริงๆแล้วสามารถมีได้ครับ เรียกว่า client-side certificate เพื่อที่ไคลเอ็นต์จะได้ใช้ authenticate ตัวเองเพื่อเข้าใช้เซิร์ฟเวอร์ได้ ซึ่งหากถูกคอนฟิกไว้เซิร์ฟเวอร์ก็สามารถทำการ validate ใบ cert ฝั่งไคลเอ็นต์ในทำนองเดียวกับที่ไคลเอ็นต์ทำการ validate ใบ cert ของเซิร์ฟเวอร์ได้ครับ เพียงแต่มันไม่ค่อยมีการใช้งานกันเท่าไหร่ในเว็บทั่วๆไป เพราะส่วนมากเราจะ authenticate กันด้วยวิธีอื่น เช่น username/password และ/หรือ OTP และ/หรือ security token ตัวอย่างเว็บที่บังคับใช้ client certificate เพื่อการ authenticate ก็เช่น https://auth.startssl.com/ ซึ่งถ้าไม่มีก็จะเข้าใช้งานไม่ได้
ปกติคำว่า session key จะหมายถึงกุญแจแบบสมมาตรที่ใช้สำหรับการเข้า-ถอดรหัสข้อมูลจริงๆของทั้งสองฝ่าย ซึ่ง session key นี้ก็จะได้จากการทำ key negotiation หรือ key exchange กันในช่วงแรกซึ่งเป็นกระบวนการที่ต้องใช้ public-key encryption และกุญแจแบบไม่สมมาตรเข้ามาเกี่ยวข้องนั่นเอง
ทีนี้สมมติว่าตัดคำว่า session ออกไป เหลือไว้แต่คำว่า key ก็จะดีขึ้นมาหน่อยแต่ก็ยังไม่ค่อยถูกอยู่ดี เช่นคำว่า เวลาคุยกัน ตรงนี้จะไม่ใช่การและเปลี่ยนข้อมูลจริงๆกัน แต่ขั้นตอนที่พูดนี้เป็นกระบวณการทำ key exchange และที่บอกว่า เข้ารหัสทับอีกครั้งเพื่อยืนยัน*ว่ามาจากไคลเอนต์คนนี้* ตรงนี้นั้นจริงๆคือการทำ authentication โดยการ sign หรือการลงลายมือชื่อหรือลายเซ็น ไม่ใช่การเข้ารหัส encrypt ข้อมูลใดๆ(ที่เคย encrypt แล้ว)ซ้ำอีกที
และกระบวนการที่ยกตัวอย่างมานั้น เป็นกระบวณการทำ key exchange แบบ RSA เท่านั้น ไม่ใช่แบบ Diffie-Hellman หรือ DH ซึ่งมีกระบวนการที่แตกต่างกันออกไป
ลองดูสองรูปข้างล่างนี้เปรียบเทียบกันครับ เอามาจากบล็อก Keyless SSL: The Nitty Gritty Technical Details ของ Cloudflare ซึ่งส่วนตัวเห็นว่าเป็นรูปที่อธิบายกระบวนการทำ SSL handshake ที่ดีและเห็นภาพชัดเจนที่สุดเท่าที่เคยเห็นมาทั้งของแบบ RSA และ DH เหมาะสำหรับใช้ศึกษาเรื่องนี้เพื่อความเข้าใจที่ถูกต้องครับ หมายเหตุ: ตัดคำว่า Without Keyless SSL ไปก่อนนะครับ
SSL Handshake แบบ RSA
SSL Handshake แบบ Diffie-Hellman
