MySQL ผ่าน VPN: ตรวจสอบเซิร์ฟเวอร์ ไม่ใช่แค่การเข้ารหัส
การเข้ารหัสไปยังโฮสต์ผิดก็ยังผิด เปรียบเทียบค่า ssl-mode แล้วรันการเชื่อมต่อที่ระบุชื่อเซิร์ฟเวอร์ที่คุณตั้งใจและพิสูจน์ได้
คุณบันทึกการเชื่อมต่อไปยัง 10.20.4.15 VPN หลุด และไคลเอนต์ยังคงเชื่อมต่อ นั่นไม่ใช่ข่าวดี ที่อยู่ส่วนตัวคือตำแหน่งภายในบริบทการกำหนดเส้นทางใดก็ตามที่คุณอยู่ และเครือข่ายจำนวนมากใช้ช่วงเดียวกัน ไคลเอนต์ไปถึงเซิร์ฟเวอร์ MySQL เพียงแต่อาจไม่ใช่ของคุณ
การแก้ไขมีสองส่วน และมีเพียงส่วนเดียวที่เกี่ยวกับเครือข่าย รักษาการเชื่อมต่อให้อยู่บนเส้นทางที่ตั้งใจไว้ และทำให้ไคลเอนต์ตรวจสอบเซิร์ฟเวอร์ที่มันคุยด้วย ส่วนแรกคือที่ที่ VPN ช่วย ส่วนที่สองต้องกำหนดค่า
เข้ารหัสไปยังอะไรกันแน่
TLS ปกป้องบทสนทนาจากใครก็ตามที่อยู่ตรงกลาง และไม่บอกอะไรเลยว่าใครที่ปลายทางอ้างว่าตนเป็น เว้นแต่ไคลเอนต์จะตรวจสอบ ใบรับรองที่ตรวจสอบกับหน่วยงานที่เชื่อถือได้พิสูจน์ว่าใบรับรองมาจากหน่วยงานนั้น มันไม่ได้พิสูจน์ว่าใบรับรองออกให้กับชื่อโฮสต์ที่คุณตั้งใจจะไปถึง และนี่เป็นคำถามที่ต่างกัน
นี่ไม่ใช่ช่องว่างทางทฤษฎี พอร์ทัล captive ข้อผิดพลาด VRF ที่ผิด และแผนที่อยู่ที่ทับซ้อนกันล้วนสร้างเซิร์ฟเวอร์ที่พร้อมจะเจรจา TLS กับคุณอย่างสมบูรณ์ หากไคลเอนต์กำหนดให้มีการเข้ารหัสเท่านั้น เซสชันจะเป็นส่วนตัวแต่ชี้ไปยังฐานข้อมูลที่ผิด
ดังนั้นคำถามที่เกี่ยวข้องจึงไม่ใช่การเชื่อมต่อถูกเข้ารหัสหรือไม่ แต่เป็นการเข้ารหัสไปยังตัวตนที่คุณตั้งใจไว้หรือไม่ ในไคลเอนต์ของ MySQL ความแตกต่างนั้นอยู่ในค่าตั้ง ssl-mode ทั้งหมด
ค่า ssl-mode ทั้งห้าในทางปฏิบัติ
มีห้าค่า และมีเพียงค่าเดียวที่ตอบคำถามของคู่มือนี้ ตารางแสดงสิ่งที่แต่ละค่ามีการรับประกันจริง ไม่ใช่สิ่งที่ชื่อบอกเป็นนัย
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
มีเพียงแถวสุดท้ายที่ตอบคำถามในบทความนี้ PREFERRED ควรได้รับการกล่าวถึงแยกต่างหาก เพราะไคลเอนต์ที่เงียบ ๆ ตกไปเป็นข้อความธรรมดานั้นแย่กว่าตัวที่ปฏิเสธ คุณเชื่อว่ามีการเข้ารหัสและการดักจับแพ็กเก็ตไม่เห็นด้วย
การเชื่อมต่อที่คุณรันได้วันนี้
คำสั่งด้านล่างคือรูปแบบที่ควรใช้ โดยมีตัวแทนสองตัว คือชื่อฐานข้อมูลที่อนุมัติและไฟล์ CA ที่ได้รับผ่านช่องทางที่อนุมัติ ไม่ควรนำมาจากสิ่งที่เซิร์ฟเวอร์เสนอให้ในการติดต่อครั้งแรก
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password ที่ไม่มีค่าจะถามหาการป้อนข้อมูล ซึ่งเก็บความลับไว้นอกรายการโปรเซสและนอกประวัติเชลล์ของคุณ เป็นนิสัยเล็ก ๆ ที่ให้ผลตอบแทนมากบน jump host ที่ใช้ร่วมกัน ซึ่งบรรทัดคำสั่งมองเห็นได้โดยผู้ใช้อื่น
เมื่อสิ่งนี้ล้มเหลว ข้อความแสดงข้อผิดพลาดแยกแยะกรณีได้ดีกว่าสัญชาตญาณ ความล้มเหลวของ CA หมายความว่าห่วงโซ่ไม่ผ่านการตรวจสอบ และคุณควรดูว่า CA ใดลงนามในใบรับรองของเซิร์ฟเวอร์ ความล้มเหลวของชื่อโฮสต์หมายความว่าห่วงโซ่ถูกต้องและชื่อไม่ตรง ซึ่งโดยปกติหมายความว่าคุณเชื่อมต่อกับเซิร์ฟเวอร์ที่ถูกต้องด้วยชื่อที่ผิด ไม่ใช่กับเซิร์ฟเวอร์ที่ผิด
การปรากฏของพรอมต์ไม่ใช่หลักฐานว่ารหัสผ่านถูกส่งไปแล้ว และการเชื่อมต่อที่ล้มเหลวไม่ได้พิสูจน์ว่าไม่มีอะไรออกจากไคลเอนต์ หากคุณกำลังสร้างเหตุการณ์ในอดีตขึ้นใหม่ ให้ระบุไคลเอนต์ การกำหนดค่า ปลั๊กอินการตรวจสอบสิทธิ์ และขั้นตอนที่ล้มเหลว การประเมินการเปิดเผยจากข้อความข้อผิดพลาดสุดท้ายเป็นการเดา
เมื่อชื่อมาจากอุโมงค์
การส่งต่อพอร์ตภายในทำให้การตรวจสอบตัวตนเสียหายในลักษณะที่ทำให้ผู้คนประหลาดใจ หากคุณส่งต่อพอร์ตภายในไปยังฐานข้อมูลและเชื่อมต่อกับ localhost ไคลเอนต์จะตรวจสอบใบรับรองกับ localhost และไม่มีใบรับรองใดออกให้กับชื่อนั้น การเชื่อมต่ออาจปลอดภัยอย่างสมบูรณ์และการตรวจสอบก็ยังคงล้มเหลว ซึ่งเป็นการตรวจสอบที่ทำงานตามที่ตั้งใจไว้
มีคำตอบที่ซื่อสัตย์สองข้อ ให้ชื่อกับปลายทางที่ส่งต่อซึ่งแก้ไขเป็นที่อยู่ลูปแบ็กและปรากฏในใบรับรองของเซิร์ฟเวอร์ หรือใช้ชื่อโฮสต์ตั้งแต่ต้นจนจบเพื่อให้ไคลเอนต์ตรวจสอบตัวตนจริง วิธีแรกสะดวกสำหรับนักพัฒนาและต้องทำงานกับใบรับรอง วิธีที่สองคิดได้ง่ายกว่าและมักเป็นค่าเริ่มต้นที่ถูกต้องสำหรับระบบอัตโนมัติ การปิดการตรวจสอบเพื่อให้การส่งต่อทำงานได้คือการทิ้งคุณสมบัติที่คุณพยายามเพิ่ม
การยอมรับคือสามเงื่อนไข
เขียนการทดสอบการยอมรับเป็นสามข้อความแยกกัน การเชื่อมต่อใช้เส้นทางที่ตั้งใจไว้ การเข้ารหัสเป็นข้อกำหนดไม่ใช่การตั้งค่า และตัวตนของเซิร์ฟเวอร์ได้รับการตรวจสอบกับวัสดุที่เชื่อถือได้ ไอคอน VPN สีเขียวไม่ได้สร้างสิ่งใดในนั้น.
สำหรับไคลเอนต์ GUI และ MariaDB ให้ตรวจสอบเอกสารของผู้ขายเองแทนที่จะถือว่าการสะกดแฟล็กส่งต่อเหมือนเดิม เอกสาร MySQL เกี่ยวกับการเชื่อมต่อที่เข้ารหัส ครอบคลุมความแตกต่างระหว่างโหมดและข้อกำหนดการกระจาย CA และเป็นเอกสารอ้างอิงที่ต้องตรวจสอบก่อนเปลี่ยนสตริงการเชื่อมต่อสำหรับการผลิต