MySQL qua VPN: xác minh máy chủ, không chỉ mã hóa
Mã hóa đến sai máy chủ vẫn là sai. So sánh các giá trị ssl-mode, sau đó chạy một kết nối nêu tên máy chủ bạn định đến và chứng minh điều đó.
Bạn lưu một kết nối đến 10.20.4.15, VPN rớt, và máy khách vẫn kết nối. Đó không phải tin tốt. Địa chỉ riêng là một vị trí bên trong bất kỳ ngữ cảnh định tuyến nào bạn đang ở, và nhiều mạng dùng cùng dải. Máy khách đã đến một máy chủ MySQL, chỉ là có thể không phải của bạn.
Cách khắc phục có hai nửa, và chỉ một nửa liên quan đến mạng. Giữ kết nối trên đường dự định và buộc máy khách xác thực máy chủ mà nó đang nói chuyện. Nửa đầu là nơi VPN giúp ích; nửa sau phải được cấu hình.
Mã hóa đến cái gì, chính xác?
TLS bảo vệ cuộc trò chuyện khỏi bất kỳ ai ở giữa và không nói gì về việc điểm cuối tự nhận là ai, trừ khi máy khách kiểm tra. Một chứng chỉ được xác thực với một tổ chức tin cậy chứng minh rằng chứng chỉ đến từ tổ chức đó. Nó không chứng minh rằng chứng chỉ được cấp cho tên máy chủ mà bạn định đến, và đó là những câu hỏi khác nhau.
Đây không phải lỗ hổng lý thuyết. Cổng captive, lỗi VRF sai và các kế hoạch địa chỉ chồng chéo đều tạo ra một máy chủ hoàn toàn sẵn sàng thương lượng TLS với bạn. Nếu máy khách chỉ yêu cầu mã hóa, phiên là riêng tư nhưng hướng đến sai cơ sở dữ liệu.
Vì vậy câu hỏi liên quan không phải là kết nối có được mã hóa hay không, mà là nó có được mã hóa đến danh tính bạn định hay không. Trong máy khách MySQL, sự khác biệt đó nằm hoàn toàn trong cài đặt ssl-mode.
Năm giá trị ssl-mode trong thực tế
Có năm giá trị, và chỉ một trong số đó trả lời câu hỏi của hướng dẫn này. Bảng liệt kê những gì mỗi giá trị thực sự bảo đảm, thay vì những gì tên của nó gợi ý.
| 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 |
Chỉ hàng cuối cùng trả lời câu hỏi trong bài viết này. PREFERRED đáng được nêu riêng, vì một máy khách lặng lẽ rơi xuống văn bản thuần còn tệ hơn một máy khách từ chối: bạn tin rằng mình có mã hóa và bản chụp gói tin không đồng ý.
Một kết nối bạn có thể chạy hôm nay
Lệnh bên dưới là hình thức cần dùng, với hai chỗ giữ: tên cơ sở dữ liệu đã được phê duyệt và tệp CA lấy qua một kênh được phê duyệt. Không nên lấy cái nào từ những gì máy chủ đề nghị ở lần tiếp xúc đầu tiên.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password
--password không có giá trị sẽ nhắc nhập, điều này giữ bí mật ngoài danh sách tiến trình và ngoài lịch sử shell của bạn. Đó là một thói quen nhỏ với lợi ích lớn trên các máy chủ nhảy dùng chung, nơi dòng lệnh hiển thị với người dùng khác.
Khi điều này thất bại, văn bản lỗi phân biệt các trường hợp tốt hơn trực giác. Lỗi CA nghĩa là chuỗi không xác thực được và bạn nên xem CA nào đã ký chứng chỉ máy chủ. Lỗi tên máy chủ nghĩa là chuỗi ổn và tên không khớp, điều này thường có nghĩa là bạn đã kết nối đến đúng máy chủ với sai tên chứ không phải đến sai máy chủ.
Việc một lời nhắc xuất hiện không phải bằng chứng rằng mật khẩu đã được gửi, và một kết nối thất bại không chứng minh rằng không có gì rời khỏi máy khách. Nếu bạn đang dựng lại một sự kiện trong quá khứ, hãy xác định máy khách, cấu hình của nó, plugin xác thực và giai đoạn đã thất bại. Ước tính mức phơi nhiễm từ thông báo lỗi cuối cùng là phỏng đoán.
Khi tên đến từ một đường hầm
Chuyển tiếp cổng cục bộ phá vỡ kiểm tra danh tính theo cách khiến người ta ngạc nhiên. Nếu bạn chuyển tiếp một cổng cục bộ đến cơ sở dữ liệu và kết nối đến localhost, máy khách xác thực chứng chỉ với localhost, và không có chứng chỉ nào được cấp cho tên đó. Kết nối có thể hoàn toàn an toàn và việc xác minh vẫn sẽ thất bại, đó là việc kiểm tra hoạt động như dự định.
Có hai câu trả lời trung thực. Đặt cho điểm cuối được chuyển tiếp một tên phân giải đến địa chỉ loopback và xuất hiện trong chứng chỉ máy chủ, hoặc dùng tên máy chủ từ đầu đến cuối để máy khách xác minh danh tính thật. Cách đầu tiên thuận tiện cho nhà phát triển và cần công việc chứng chỉ; cách thứ hai dễ lý luận hơn và thường là mặc định đúng cho tự động hóa. Tắt xác minh để chuyển tiếp hoạt động là vứt bỏ thuộc tính bạn đang cố thêm vào.
Chấp nhận là ba điều kiện
Viết bài kiểm tra chấp nhận thành ba tuyên bố riêng biệt: kết nối đã dùng tuyến dự định, mã hóa là bắt buộc chứ không phải tùy chọn, và danh tính máy chủ đã được xác minh với tài liệu tin cậy. Một biểu tượng VPN xanh không thiết lập điều nào trong số đó.
Với máy khách GUI và MariaDB, hãy kiểm tra tài liệu của chính nhà cung cấp thay vì giả định cách viết cờ được giữ nguyên. Tài liệu MySQL về kết nối mã hóa bao gồm sự khác biệt giữa các chế độ và yêu cầu phân phối CA, và đó là tài liệu tham khảo cần kiểm tra trước khi bạn thay đổi chuỗi kết nối sản xuất.