Apache: ตรวจสอบความน่าเชื่อถือ SSL เชนเพื่อป้องกันการโจมตี MITM?

ฉันเพิ่งตระหนักว่าการโจมตี SSL แบบคนกลางนั้นเป็นเรื่องปกติมากกว่าที่ฉันคิดโดยเฉพาะในสภาพแวดล้อมขององค์กร ฉันได้ยินและเห็นตัวเองหลายองค์กรที่มีพร็อกซีเซิร์ฟเวอร์ SSL ที่โปร่งใส ไคลเอนต์ทั้งหมดได้รับการกำหนดค่าให้เชื่อถือใบรับรองพร็อกซีนี้ สิ่งนี้หมายความว่าผู้ว่าจ้างในทางทฤษฎีสามารถดักจับการรับส่งข้อมูล SSL ที่เข้ารหัสโดยไม่มีคำเตือนใด ๆ ในเบราว์เซอร์ที่โผล่ขึ้นมา ดังกล่าวข้างต้นลูกค้ามาพร้อมกับใบรับรองที่เชื่อถือได้ สิ่งนี้สามารถเปิดเผยได้โดยการตรวจสอบความถูกต้องของใบรับรองที่ใช้อยู่เท่านั้น

สำหรับฉันดูเหมือนว่านายจ้างใช้ตำแหน่งที่เหนือกว่าของเขาเพื่อสอดแนมการรับส่งข้อมูล SSL ของพนักงาน สำหรับฉันนี่ทำให้แนวคิดทั้งหมดของ SSL ที่ไม่น่าเชื่อถือ ฉันได้ทดสอบการตั้งค่าที่คล้ายกันสำเร็จแล้วโดยใช้ mitmproxy และสามารถอ่านการสื่อสารระหว่างลูกค้ากับเซิร์ฟเวอร์ธนาคารทางอิเล็กทรอนิกส์ของฉันได้ นี่คือข้อมูลที่ไม่ควรเปิดเผยต่อใคร

ดังนั้นคำถามของฉันค่อนข้างง่าย: ฉันจะตรวจสอบ chain of trust บนฝั่งเซิร์ฟเวอร์ได้อย่างไร ฉันต้องการตรวจสอบให้แน่ใจว่าลูกค้าใช้ใบรับรองของเซิร์ฟเวอร์ของฉันและเชื่อถือได้เพียงหนึ่งเชน ฉันสงสัยว่าการตั้งค่า SSL ของ Apache สามารถทำได้หรือไม่ สิ่งนี้จะสะดวกเนื่องจากสามารถนำไปใช้กับแอปพลิเคชันมากมายได้อย่างง่ายดาย หากเป็นไปไม่ได้มีใครรู้วิธีการทำเช่นนี้ใน PHP หรือไม่? หรือคุณมีข้อเสนอแนะอื่น ๆ

ฉันคิดว่าคำถามนี้เหมาะสมกว่าสำหรับsecurity.stackexchange.comซึ่งหัวข้อของ MITM ถูกกล่าวถึงในคำถามมากมาย แต่อย่างไรก็ตาม:

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

ในกรณีของการสกัดกั้น SSL ไคลเอนต์ TLS จากมุมมองของเซิร์ฟเวอร์คือการสกัดกั้น SSL / ไฟร์วอลล์ ดังนั้นปัญหาที่ฝั่งเซิร์ฟเวอร์คือการตรวจสอบว่ามีการพูดคุยกับลูกค้าที่คาดหวัง (เบราว์เซอร์) หรือไม่ (ไฟร์วอลล์ / AV) วิธีที่ปลอดภัยที่สุดในการทำเช่นนี้คือการใช้ใบรับรองไคลเอ็นต์เพื่อรับรองความถูกต้องของไคลเอ็นต์ - และในความเป็นจริงการสกัดกั้น SSL จะไม่ทำงานหากใช้การตรวจสอบสิทธิ์ไคลเอ็นต์เช่นการจับมือ TLS จะล้มเหลวเนื่องจาก MITM ไม่สามารถมอบใบรับรองไคลเอ็นต์ที่คาดหวัง

มีใช้ใบรับรองไคลเอ็นต์เท่านั้น นอกจากนี้การจับมือ TLS ที่ล้มเหลวไม่ได้หมายความว่าลูกค้าสามารถสื่อสารกับเซิร์ฟเวอร์โดยไม่มีการสกัดกั้น SSL แต่ลูกค้าไม่สามารถสื่อสารกับเซิร์ฟเวอร์ได้เลย อีกทางเลือกหนึ่งคือใช้ฮิวริสติกในการตรวจจับชนิดของไคลเอนต์ TLS โดยใช้ลายนิ้วมือของ TLS handshake เช่นชนิดและคำสั่งของยันต์ใช้ส่วนขยายเฉพาะ ... ในขณะที่พร็อกซี SSL สกัดกั้นในทางทฤษฎีอาจจำลองต้นฉบับ ลูกค้าส่วนใหญ่ไม่ได้สมบูรณ์แบบ ดูเพิ่มเติมตรวจหาคน-in-the-กลางในฝั่งเซิร์ฟเวอร์สำหรับ HTTPSหรือส่วนที่สาม TLS ดำเนิน Heuristicsในความปลอดภัยผลกระทบของ HTTPS สกัดกั้น

สำหรับฉันดูเหมือนว่านายจ้างใช้ตำแหน่งที่เหนือกว่าของเขาเพื่อสอดแนมการรับส่งข้อมูล SSL ของพนักงาน สำหรับฉันนี่ทำให้แนวคิดทั้งหมดของ SSL ที่ไม่น่าเชื่อถือ

ปัญหาไม่ได้อยู่ในแนวคิดของ SSLหรือในการใช้งานด้านเทคนิค แต่มีคนอื่นที่มีการควบคุมเต็มรูปแบบผ่านจุดปลายหนึ่งของการเชื่อมต่อนั่นคือเวิร์กสเตชันของคุณ
นั่นคือรากของความเสี่ยงด้านความปลอดภัยที่แท้จริง ...

จากมุมมองด้านความปลอดภัยมันเป็นเวิร์กสเตชันของคุณที่ถูกทำลายซึ่งทำลายความเชื่อมั่นซึ่งในสถานการณ์ปกติจะป้องกันไม่ให้ MITM ประสบความสำเร็จ

ฉันจะตรวจสอบ chain of trust บนฝั่งเซิร์ฟเวอร์ได้อย่างไร?

คุณทำไม่ได้ นั่นคือฝั่งไคลเอ็นต์

ขึ้นอยู่กับกรณีการใช้งานของคุณสิ่งที่คุณสามารถทำได้คือRFC 7469 HTTP Public Key Pinningที่คุณส่งส่วนหัวเพิ่มเติมให้กับลูกค้าพร้อมกับรายการ (แฮช) ใบรับรอง SSL จริงของคุณหรือ CA ที่คุณใช้

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

คุณCOULD (ชนิดของ) แต่คำถามที่แท้จริงคือไม่ว่าคุณควร

แต่ระวังมันไม่มีที่ไหนง่ายเหมือนการเปลี่ยนธงใน apache.conf

นอกจากนี้ในฐานะ "ผู้บุกรุก" (เช่น. นายจ้าง) ควบคุมคอมพิวเตอร์ไคลเอนต์ที่พวกเขาสามารถเสมอฟอยล์ความพยายามของคุณหากพวกเขามีแนวโน้มที่จะลงทุนความพยายามมากพอ (ด้านสว่างจนกว่าคุณจะได้ปลาตัวใหญ่มากพวกเขาส่วนใหญ่อาจจะไม่ได้ เอียงดังนั้นคุณจะบรรลุเป้าหมายที่ผู้ใช้ของคุณจะไม่สามารถเชื่อมต่อกับคุณเว้นแต่จะปลอดภัย))

• คุณสามารถปรับใช้ TLS อีกครั้งใน javascriptและทำการตรวจสอบที่นั่นหากใบรับรองที่ลูกค้าเชื่อมต่ออยู่คือใบรับรองของเว็บไซต์ของคุณ

• หากคุณโชคดีผู้ใช้อาจใช้เบราว์เซอร์ที่ Javascript ฝั่งไคลเอ็นต์สามารถรับข้อมูลเกี่ยวกับใบรับรองระยะไกลที่ใช้ (และตรวจสอบได้ง่ายจากค่าฮาร์ดโค้ดของใบรับรองเซิร์ฟเวอร์ของคุณ)

• คุณสามารถใช้ JavaScript เพื่อให้ทำงานการเข้ารหัสของคุณเอง ดังนั้นแม้ว่า TLS MiTM ที่ชั่วร้ายของ บริษัท จะประสบความสำเร็จ แต่ก็ยังคงไม่สามารถเข้าถึงข้อมูลของคุณได้ แน่นอนหากมีความสนใจเพียงพอ (และเนื่องจากพวกเขาควบคุมลูกค้า) พวกเขาสามารถเพียงแค่เปลี่ยนจาวาสคริปต์ที่ปลอดภัยของคุณด้วยตัวเองซึ่งจะบันทึก (หรือเปลี่ยนแปลง) ข้อมูลทั้งหมดที่อยู่ระหว่างการขนส่ง

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