Giới thiệu

Bảo mật giao thức lớp truyền tải (TLS) là nền tảng của lưu lượng web an toàn, nhưng nhiều nhà phát triển vẫn bám vào những hiểu lầm lỗi thời có thể làm yếu đi triển khai Nginx của họ. Là một trưởng nhóm DevOps, bạn có thể đã nghe những phát biểu như "TLS 1.3 là phiên bản duy nhất bạn cần" hoặc "chứng chỉ tự ký luôn không an toàn". Bài viết này sẽ vạch trần những hiểu lầm phổ biến nhất và cung cấp một cấu hình Nginx sẵn sàng cho sản xuất, cân bằng giữa bảo mật, khả năng tương thích và hiệu suất.

Hiểu lầm #1 – TLS 1.3 là phiên bản duy nhất đáng sử dụng

Mặc dù TLS 1.3 mang lại cải tiến về tốc độ và quyền riêng tư, việc loại bỏ hoàn toàn các phiên bản cũ có thể làm hỏng các khách hàng cũ (ví dụ: các phiên bản Android hoặc Windows cũ). Cách tiếp cận hợp lý là hỗ trợ TLS 1.2 và TLS 1.3, chỉ tắt các phiên bản TLS 1.0/1.1 không an toàn.

ssl_protocols TLSv1.2 TLSv1.3;

Hiểu lầm #2 – Chứng chỉ tự ký là không an toàn

Chứng chỉ tự ký thường bị bỏ qua vì chúng thiếu chuỗi tin cậy công khai. Thực tế, chúng có độ an toàn về mặt mã hóa; rủi ro nằm ở quản lý độ tin cậy. Đối với các dịch vụ nội bộ, một PKI riêng hoặc một chứng chỉ tự ký ngắn hạn (ví dụ: thông qua certbot --standalone --register-unsafely-without-email) có thể hoàn toàn an toàn nếu bạn phân phối chứng chỉ CA cho các khách hàng của mình.

Hiểu lầm #3 – OCSP Stapling là một tính năng hiệu suất tùy chọn

OCSP stapling giảm độ trễ bằng cách cho phép máy chủ cung cấp trạng thái thu hồi, nhưng nhiều người nghĩ rằng nó chỉ là một tính năng “tốt để có”. Thực tế, bật OCSP stapling là thiết yếu cho cả hiệu suất và bảo mật vì nó ngăn các trình duyệt thực hiện các cuộc gọi mạng bổ sung có thể bị chặn hoặc trì hoãn.

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;

Hiểu lầm #4 – Bất kỳ bộ mã hóa hiện đại nào cũng an toàn

Lựa chọn bộ mã hóa không phải là một nhiệm vụ “chọn bất kỳ cái nào hiện đại”. Một số bộ vẫn bộc lộ các điểm yếu đã biết (ví dụ: lỗ hổng chế độ CBC). Cách an toàn nhất là sử dụng các khuyến nghị của Trình tạo cấu hình SSL Mozilla cho khả năng tương thích “Trung gian”, cân bằng giữa bảo mật và khả năng tiếp cận của khách hàng.

ssl_ciphers \
  'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:' \
  'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:' \
  'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;

Hiểu lầm #5 – HSTS chỉ dành cho các trang lớn

HTTP Strict Transport Security (HSTS) buộc các trình duyệt sử dụng HTTPS trong một khoảng thời gian xác định, ngăn chặn các cuộc tấn công hạ cấp. Ngay cả một cổng nội bộ nhỏ cũng có lợi từ HSTS vì nó loại bỏ khả năng tiếp xúc HTTP không mong muốn.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Danh sách kiểm tra tăng cường TLS cho Nginx

1. Lấy chứng chỉ
   • Sử dụng Let’s Encrypt cho các dịch vụ công khai (tự động hóa certbot).
   • Đối với các dịch vụ nội bộ, tạo một chứng chỉ tự ký và phân phối CA.
2. Cấu hình giao thức
   nginx Copy

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_prefer_server_ciphers on;

3. Chọn các bộ mã hóa mạnh
   • Sao chép dòng ssl_ciphers từ trình tạo của Mozilla.
4. Bật Bảo mật Tiến hóa
   • Đảm bảo có mặt các bộ ECDHE; chúng cung cấp bảo mật tiến hóa hoàn hảo.
5. Thiết lập OCSP Stapling
   nginx Copy

   ssl_stapling on;
   ssl_stapling_verify on;
   resolver 1.1.1.1 1.0.0.1 valid=300s;

6. Triển khai HSTS
   nginx Copy

   add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

7. Bật HTTP/2 (cần thiết TLS)
   nginx Copy

   listen 443 ssl http2;

8. Thêm thông số Diffie-Hellman an toàn (tùy chọn nhưng được khuyến nghị)
   bash Copy

   openssl dhparam -out /etc/nginx/dhparam.pem 4096

   nginx Copy

   ssl_dhparam /etc/nginx/dhparam.pem;

9. Kiểm tra cấu hình của bạn
   • Sử dụng sslscan hoặc testssl.sh để xác minh hỗ trợ giao thức và bộ mã hóa.
   • Chạy curl -I https://yourdomain.com và kiểm tra tiêu đề Strict-Transport-Security.
10. Theo dõi và thay đổi thường xuyên
    • Thiết lập một cron job để gia hạn chứng chỉ Let’s Encrypt (certbot renew --quiet).
    • Lên lịch quét định kỳ để phát hiện các điểm yếu mới được phát hiện.

Tác động hiệu suất của các thiết lập TLS đúng cách

Một nỗi sợ thường gặp là việc thắt chặt TLS sẽ làm giảm hiệu suất. Thực tế, việc bật TLS 1.3 và các bộ mã hóa hiện đại giảm độ trễ bắt tay nhờ vào việc giảm số lần round-trip và mã hóa AEAD tích hợp. Bật HTTP/2 trên TLS cũng cho phép các luồng đa dạng, có thể giảm tới 30% thời gian tải trang cho các trang chứa nhiều tài nguyên.

Thử nghiệm nhanh

Những con số này chỉ mang tính chất minh họa; kết quả thực tế phụ thuộc vào điều kiện mạng và phần cứng của khách hàng, nhưng chúng chứng minh rằng bảo mật và tốc độ không phải là hai thứ đối lập.

Những cạm bẫy phổ biến cần tránh

• Để TLS 1.0/1.1 được bật – chúng dễ bị tấn công POODLE và BEAST.
• Sử dụng ssl_ciphers “HIGH:!aNULL:!MD5” – chuỗi cũ này có thể vẫn cho phép các bộ mã hóa yếu.
• Quên nạp lại Nginx sau khi gia hạn chứng chỉ – tự động hóa với systemctl reload nginx trong hook gia hạn của bạn.
• Bỏ qua xác minh OCSP stapling – nếu không có ssl_stapling_verify, bạn có thể phục vụ dữ liệu thu hồi đã cũ.

Kết luận

Bằng cách loại bỏ những hiểu lầm lỗi thời và áp dụng quy trình tăng cường TLS có kỷ luật, bạn có thể bảo vệ máy chủ Nginx của mình mà không phải hy sinh hiệu suất. Danh sách kiểm tra trên cung cấp cho bạn một quy trình làm việc có thể lặp lại từ một blog trên máy ảo đơn lẻ đến một loạt các dịch vụ vi mô cân bằng tải.

Nếu bạn đang tìm kiếm thêm các hướng dẫn thực tế về hạ tầng web, nhóm tại lacidaweb.com thường xuyên xuất bản các bài viết và hướng dẫn sâu về chủ đề này để giúp bạn đi trước một bước trong lĩnh vực bảo mật.