ในโลกของการเข้าถึงระยะไกลอย่างปลอดภัย SSH (Secure Shell) ถูกมองว่าเป็นมาตรฐานทองคำของการสื่อสารที่มีการเข้ารหัสมาอย่างยาวนาน แต่ภายใต้ชื่อเสียงนี้กลับมีความจริงที่ไม่น่าพอใจที่ผู้เชี่ยวชาญด้านความปลอดภัยและผู้ดูแลระบบกำลังพูดคุยกันอย่างเปิดเผยในขณะนี้: ผู้ใช้ส่วนใหญ่ยอมรับ SSH host keys อย่างสุ่มสี่สุ่มห้าโดยไม่มีการยืนยัน สร้างช่องโหว่ด้านความปลอดภัยที่สำคัญซึ่งเป็นที่ยอมรับกันอย่างกว้างขวางแต่แทบไม่เคยได้รับการแก้ไข
การอภิปรายนี้ได้รับแรงผลักดันเมื่อผู้เชี่ยวชาญด้านเทคนิคได้แบ่งปันประสบการณ์ของพวกเขาเกี่ยวกับการจัดการ SSH key ซึ่งเผยให้เห็นทั้งความท้าทายในทางปฏิบัติและผลกระทบที่อาจเกิดขึ้นจากการละเลยด้านความปลอดภัยที่แพร่หลายนี้
ช่องว่างการยืนยันในทางปฏิบัติ
ในขณะที่ SSH ถูกออกแบบมาพร้อมกับความปลอดภัยที่แข็งแกร่ง แต่ปัจจัยด้านมนุษย์กลับกลายเป็นจุดอ่อนที่สุด กระบวนการยืนยันต้องการให้ผู้ใช้เปรียบเทียบลายนิ้วมือเลขฐานสิบหกที่ยาว—งานที่ทั้งน่าเบื่อและมีโอกาสผิดพลาดสูง ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุเกี่ยวกับการดำเนินงาน SFTP ขององค์กรของพวกเขา: เซิร์ฟเวอร์ SFTP องค์กรของฉันซึ่งถูกบังคับให้ใช้เมื่อหลายปีก่อนแสดงคีย์หลายอัน เห็นได้ชัดว่าเพราะมันอยู่บน DNS round robin ความซับซ้อนในโลกแห่งความจริงเช่นนี้มักนำผู้ใช้ไปสู่การยอมรับคีย์ใดๆ ก็ตามที่เซิร์ฟเวอร์นำเสนอ โดยเฉพาะเมื่อต้องจัดการกับเซิร์ฟเวอร์หลายตัวหรือสภาพแวดล้อมที่มีการกระจายโหลด
ปัญหานี้ขยายไปไกลกว่าความไม่สะดวกง่ายๆ เมื่อ host keys เปลี่ยนแปลงไปอย่างไม่คาดคิด—ไม่ว่าจะเนื่องจากการรีอิมเมจเซิร์ฟเวอร์ การเปลี่ยนแปลงการกำหนดค่า หรือการโจมตีที่อาจเกิดขึ้น—ผู้ใช้จะเผชิญกับภาวะกลืนไม่เข้าคายไม่ออก พวกเขาจะลงทุนเวลาในการยืนยัน หรือเพียงแค่ยอมรับคีย์ใหม่และทำงานต่อไป? ส่วนใหญ่เลือกอย่างหลัง สร้างโอกาสสำหรับการโจมตีแบบ man-in-the-middle
Host keys เป็นความคิดที่โง่เขลาที่สุดในประวัติศาสตร์ของสิ่งที่เรียกว่าความปลอดภัยของคอมพิวเตอร์
ความรู้สึกนี้สะท้อนไปทั่วชุมชน ซึ่งเน้นย้ำถึงความหงุดหงิดกับกลไกความปลอดภัยที่ในทางทฤษฎีควรทำงานได้อย่างสมบูรณ์แบบ แต่ในทางปฏิบัติกลับล้มเหลวเนื่องจากปัจจัยของมนุษย์และความซับซ้อนในการนำไปใช้
ความท้าทายด้านความปลอดภัยของ SSH ที่พบบ่อย
- ปัจจัยด้านมนุษย์: ผู้ใช้มักประสบปัญหาในการตรวจสอบลายนิ้วมือแบบเลขฐานสิบหกที่ยาวได้อย่างถูกต้อง
- การจัดการคีย์: คีย์ของโฮสต์เปลี่ยนแปลงเนื่องจากการติดตั้งเซิร์ฟเวอร์ใหม่ การอัปเกรด หรือการเปลี่ยนแปลงการกำหนดค่า
- ช่องทางการโจมตี: การปลอมแปลง DNS การเปลี่ยนเส้นทาง ARP และเครื่องมือโจมตีแบบ man-in-the-middle เช่น ssharpd
- ความซับซ้อนในการนำไปใช้: เซิร์ฟเวอร์ที่มีการกระจายโหลดมักแสดงคีย์หลายตัว ทำให้ผู้ใช้สับสน
- นโยบายขององค์กร: ข้อกำหนดด้านความปลอดภัยที่แตกต่างกันในอุตสาหกรรมและกรณีการใช้งานต่างๆ
ความปลอดภัยขององค์กรกับการใช้งานในชีวิตประจำวัน
ภาพรวมการยืนยันเผยให้เห็นความแตกแยกที่ชัดเจนระหว่างผู้ใช้ประเภทต่างๆ สถาบันการเงินและองค์กรที่จัดการข้อมูลสำคัญ เช่น ไฟล์ ACH (การชำระเงินอิเล็กทรอนิกส์รวมถึงเงินเดือน) มักจะดำเนินขั้นตอนการยืนยันที่เข้มงวด ดังที่ผู้เชี่ยวชาญที่จัดการธุรกรรมทางธนาคารอธิบาย: เราโอนย้ายไฟล์ ACH ผ่าน SSH ไปยังธนาคารหลายแห่ง คุณเชื่อได้เลยว่าฉันตรวจสอบคีย์ องค์กรเหล่านี้มักจะมีกระบวนการที่เป็นทางการสำหรับการหมุนเวียนและยืนยันคีย์ โดยมีธนาคารหนึ่งที่ถูกกล่าวถึงว่าบังคับใช้การหมุนเวียนคีย์ทุกสองปีพร้อมกับการยืนยันที่ обязаต้องทำ
อย่างไรก็ตาม สำหรับผู้ใช้ทั่วไปส่วนใหญ่และแม้แต่สภาพแวดล้อมขององค์กรหลายแห่ง ความเป็นจริงกลับต่างออกไป แนวทาง trust on first use (TOFU) ในตอนแรก กลายเป็นการเชื่อใจในทุกครั้งที่ใช้ เนื่องจากผู้ใช้เบื่ออย่างรวดเร็วกับข้อความแจ้งให้ยืนยัน สิ่งนี้สร้างโมเดลความปลอดภัยที่การเชื่อมต่อครั้งแรกมีความสำคัญอย่างยิ่ง—หากผู้โจมตีสามารถดักจับการจับมือครั้งแรกนั้นได้ พวกเขาสามารถสร้างตำแหน่ง man-in-the-middle ที่คงอยู่ได้
วิธีแก้ไขทางเทคนิคและข้อจำกัดของมัน
การอภิปรายในชุมชนเผยให้เห็นหลายแนวทางในการแก้ไขปัญหาเกี่ยวกับการยืนยัน SSH ซึ่งแต่ละวิธีก็มีข้อได้เปรียบเสียเปรียบของตัวเอง SSH certificates ที่ลงนามโดย Certificate Authority (CA) เสนอทางออกหนึ่ง ซึ่งอนุญาตให้องค์กรสร้างสายโซ่แห่งความเชื่อมั่น ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุ: เอกสารดังกล่าวได้กล่าวถึงว่าคุณสามารถให้คีย์ ssh ของคุณลงนามโดย ca ได้ ดังนั้นในบริษัท พนักงานฝ่าย IT จึงสามารถกำหนดค่า OS ของทุกคนให้เชื่อถือเฉพาะคีย์ ssh ที่ลงนามโดยองค์กรเท่านั้น
อย่างไรก็ตาม แนวทางนี้ก็นำมาซึ่งความเสี่ยงของมันเอง CA ที่รวมศูนย์กลายเป็นจุดล้มเหลวเดียว—หากถูกบุกรุก มันอาจทำให้เกิดการโจมตีอย่างกว้างขวางทั่วทั้งองค์กร บางบริการ เช่น GitHub ได้ใช้แนวทางที่แตกต่างออกไปโดยการเผยแพร่ลายนิ้วมือ SSH ของพวกเขาผ่านช่องทางที่ปลอดภัย ใช้ประโยชน์จากโครงสร้างพื้นฐาน TLS ที่มีอยู่เพื่อกระจายข้อมูลคีย์อย่างน่าเชื่อถือ
อีกวิธีแก้ปัญหาที่ถูกเสนอเกี่ยวข้องกับการออกแบบประสบการณ์ผู้ใช้ที่ดีขึ้น แทนที่จะคาดหวังให้ผู้ใช้ยืนยันสตริงเลขฐานสิบหกด้วยตนเอง ระบบสามารถให้คำเตือนที่ชัดเจนยิ่งขึ้นและวิธีการยืนยันที่ใช้งานง่ายกว่า สำหรับการหมุนเวียนคีย์ที่มีการวางแผนไว้ เซิร์ฟเวอร์สามารถลงนามคีย์ใหม่ด้วยคีย์เก่าได้ ซึ่งอนุญาตให้อัปเดตไฟล์ known_hosts โดยอัตโนมัติ
การเปรียบเทียบวิธีการตรวจสอบ Host Key ของ SSH
| วิธีการ | ระดับความปลอดภัย | ความสะดวกในการใช้งาน | กรณีการใช้งานทั่วไป |
|---|---|---|---|
| การตรวจสอบ Fingerprint ด้วยตนเอง | สูง | ต่ำ | สถาบันการเงิน สภาพแวดล้อมที่มีความปลอดภัยสูง |
| Trust On First Use (TOFU) | ปานกลาง | สูง | วัตถุประสงค์ทั่วไป สภาพแวดล้อมการพัฒนา |
| Certificate Authority (CA) Signed | สูง | ปานกลาง-สูง | สภาพแวดล้อมองค์กร โครงสร้างพื้นฐานที่มีการจัดการ |
| Published Fingerprints | ปานกลาง-สูง | ปานกลาง | บริการสาธารณะ (เช่น GitHub) การตั้งค่าที่มีเอกสารประกอบ |
| ไม่มีการตรวจสอบ | ต่ำ | สูงมาก | การทดสอบ สถานการณ์ที่มีความเสี่ยงต่ำ |
ผลกระทบด้านความปลอดภัยในภาพรวม
ปัญหาเกี่ยวกับการยืนยันคีย์ SSH สะท้อนให้เห็นถึงประเด็นที่ใหญ่กว่าในความปลอดภัยของคอมพิวเตอร์ ดังที่ผู้แสดงความคิดเห็นหนึ่งชี้ให้เห็น: การจับมือครั้งแรกมักจะเต็มไปด้วยปัญหาด้านความปลอดภัย ความท้าทายนี้ไม่ได้มีเฉพาะใน SSH—ปัญหาที่คล้ายกันมีอยู่ใน TLS/SSL ถึงแม้ว่าโมเดล web PKI (Public Key Infrastructure) จะให้แนวทางที่แตกต่างในการสร้างความไว้วางใจก็ตาม
การอภิปรายยังกล่าวถึงความแตกต่างระหว่างโมเดลการยืนยันตัวตนของ SSH และเว็บ ในขณะที่ SSH รองรับการยืนยันตัวตนสองทาง (ทั้งเซิร์ฟเวอร์และไคลเอ็นต์สามารถยืนยันซึ่งกันและกันได้) แอปพลิเคชันเว็บส่วนใหญ่พึ่งพาการยืนยัน TLS แบบทางเดียว การเกิดขึ้นของ WebAuthn และ passkeys แสดงถึงความพยายามที่จะนำการยืนยันตัวตนที่แข็งแกร่งยิ่งขึ้นมาสู่เว็บ แม้ว่าเทคโนโลยีเหล่านี้จะเผชิญกับความท้าทายในการนำไปใช้ของตัวเองก็ตาม
สิ่งที่ทำให้สถานการณ์ของ SSH น่ากังวลเป็นพิเศษคือธรรมชาติของการเข้าถึงที่มีมูลค่าสูงซึ่งมันให้มา ไม่เหมือนกับการท่องเว็บที่เซสชันอาจมีความเสี่ยงที่จำกัด การเชื่อมต่อ SSH มักจะให้สิทธิ์การเข้าถึงในระดับผู้ดูแลระบบแก่ระบบที่สำคัญ การโจมตีแบบ man-in-the-middle ที่สำเร็จสามารถทำให้โครงสร้างพื้นฐานทั้งหมดเสียหายได้
ก้าวไปข้างหน้า: ความปลอดภัยในทางปฏิบัติในโลกที่ไม่สมบูรณ์แบบ
แม้จะมีความเสี่ยงในทางทฤษฎี หลายองค์กรยังคงดำเนินงานได้สำเร็จด้วยโมเดลความปลอดภัย SSH ในปัจจุบัน แนวทาง trust on first use แม้จะไม่สมบูรณ์แบบ แต่ก็พิสูจน์แล้วว่าเพียงพอสำหรับกรณีการใช้งานหลายอย่าง ดังที่ผู้แสดงความคิดเห็นหนึ่งสังเกตอย่างสมจริง: มันเป็นเรื่องธรรมดามากที่จะตรวจสอบ host keys เปรียบเทียบได้กับการล็อกประตูแม้จะไม่มีเหตุการณ์ลักขโมยเกิดขึ้นเมื่อไม่นานนี้
ฉันทามติของชุมชนชี้ให้เห็นว่าในขณะที่ความปลอดภัยที่สมบูรณ์แบบอาจเป็นไปไม่ได้ แต่การปรับปรุงในทางปฏิบัติก็เป็นไปได้ เครื่องมือที่ดีขึ้น อินเทอร์เฟซผู้ใช้ที่ชัดเจนขึ้น และนโยบายขององค์กรสามารถลดความเสี่ยงได้อย่างมีนัยสำคัญ สำหรับสภาพแวดล้อมที่มีความปลอดภัยสูง แนวทางแบบใช้ใบรับรองหรือขั้นตอนการยืนยันที่เข้มงวดยังคงมีความจำเป็น
การอภิปรายอย่างต่อเนื่องเกี่ยวกับการยืนยันคีย์ SSH ทำหน้าที่เป็นเครื่องเตือนใจว่าความปลอดภัยเป็นเรื่องของปัจจัยของมนุษย์ไม่น้อยไปกว่าความแข็งแกร่งของการเข้ารหัส ในขณะที่ภูมิทัศน์ทางเทคโนโลยีพัฒนาขึ้น การหาความสมดุลที่เหมาะสมระหว่างความปลอดภัยและความสะดวกในการใช้งานยังคงเป็นหนึ่งในความท้าทายพื้นฐานในด้านความปลอดภัยทางไซเบอร์
อ้างอิง: Do Users Verify SSH Keys?