HomeThủ Thuật ChungHệ Điều HànhUbuntuHướng dẫn Nginx – Phần 3: Cài đặt SSLHướng dẫn Nginx – Phần 3
Last updated
Last updated
Sofsog 17/05/2018 Database, Thiết kế web, Ubuntu, Wordpress Không có phản hồiĐánh giá của người xem[Phiếu bầu: 0 Xếp hạng: 0/5]
Bài này hoặc loạt bài hướng dẫn nginx này (nếu mình có thời gian) mình thực hiện bằng cách vừa học vừa viết lại , nguồn từ internet, chủ yếu mình lược dịch lại từ các trang web nước ngoài. Mục đích vừa để chia sẻ vừa để lại lưu trữ (sau này mình quên có thể vào để xem lại).
Nên đọc Hướng dẫn Nginx – Phần 1 và 2 trước:
Hướng dẫn Nginx – Phần 1: Các khái niệm cơ bản
Hướng dẫn Nginx – Phần 2: Performance
Tiếp tục phần 3:
SSL (standing for Socket Secure Layer) là một giao thức cung cấp kết nối an toàn qua HTTP.SSL 1.0 được phát triển bởi Netscape và không bao giờ được phát hành công khai do các lỗi bảo mật nghiêm trọng. SSL 2.0 được phát hành vào năm 1995, cũng có một số vấn đề, dẫn đến việc ra đời SSL 3.0, được phát hành vào năm 1996Phiên bản đầu tiên của TLS (Transport Layer Security) được viết dưới dạng bản nâng cấp lên SSL 3.0. Sau đó, TLS 1.1 và 1.2 xuất hiện. Thời điểm hiện tại, TSL 1.3 sắp ra mắt (đây thực sự là điều đáng để chờ đợi).
Về mặt kỹ thuật, SSL và TLS là khác nhau (vì mỗi thứ mô tả phiên bản khác nhau của một giao thức) – nhưng mọi người thường dùng chung tên của chúng.
Để xử lý lưu lượng HTTPS, bạn cần có chứng chỉ SSL / TLS. Thường tốn phí, hoặc bạn có thể sử dụng chứng chỉ miễn phí thông qua Let’s encrypt (Bên dưới có hướng dẫn đăng ký)
Khi bạn có chứng chỉ, bạn có thể chỉ cần bật HTTPS bằng cách:
bắt đầu lắng nghe trên cổng 443
(cổng mặc định mà trình duyệt sẽ sử dụng khi bạn nhập https://sofsog.com
)
cung cấp chứng chỉ và key của nó
1234567
server { listen 443 ssl default_server; listen [::]:443 ssl default_server; ssl_certificate /etc/nginx/ssl/sofsog.crt; ssl_certificate_key /etc/nginx/ssl/sofsog.key;}
Chúng ta cũng có thể chỉnh cấu hình:
chỉ sử dụng giao thức TLS. Tất cả các phiên bản SSL không được sử dụng nữa do các lỗ hổng nổi tiếng
sử dụng mật mã máy chủ bảo mật được xác định trước (trường hợp tương tự như với các giao thức – những ngày đó chỉ một vài mật mã được coi là an toàn)
Hãy nhớ rằng các cài đặt ở trên luôn thay đổi. Bạn nên xem lại chúng thường xuyên.
1234567891011
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:!MD5;ssl_prefer_server_ciphers on; server { listen 443 ssl default_server; listen [::]:443 ssl default_server; ssl_certificate /etc/nginx/ssl/sofsog.crt; ssl_certificate_key /etc/nginx/ssl/sofsog.key;}
Sử dụng HTTPS, đặt TLS handshake ở đầu trang của TCP. Điều này tăng đáng kể thời gian, trước khi truyền dữ liệu thực tế được thực hiện. Giả sử bạn đang yêu cầu /image.jpg từ Warsaw và kết nối với máy chủ gần nhất ở Berlin:
123456789101112131415161718
Open connection TCP Handshake:Warsaw ->------------------ synchronize packet (SYN) ----------------->- BerlinWarsaw -<--------- synchronise-acknowledgement packet (SYN-ACK) ------<- BerlinWarsaw ->------------------- acknowledgement (ACK) ------------------->- Berlin TLS Handshake:Warsaw ->------------------------ Client Hello ---------------------->- BerlinWarsaw -<------------------ Server Hello + Certificate ---------------<- BerlinWarsaw ->---------------------- Change Ciper Spec -------------------->- BerlinWarsaw -<---------------------- Change Ciper Spec --------------------<- Berlin Data transfer:Warsaw ->---------------------- /image.jpg --------------------------->- BerlinWarsaw -<--------------------- (image data) --------------------------<- Berlin Close connection
Để lưu 1 vòng trong khi TLS handshake, và chi phí tính toán để tạo ra một key mới, chúng ta có thể sử dụng lại các tham số phiên (session parameters) trong yêu cầu đầu tiên (first request). Máy khách (client) và máy chủ (server) có thể lưu trữ các thông số phiên (session parameters) phía sau Session ID key
1234
server { ssl_session_cache shared:SSL:10m; ssl_session_timeout 1h;}
Chứn chỉ SSL có thể bị thu hồi bất kỳ lúc nào. Để trình duyệt biết liệu chứng chỉ đã cho không còn hợp lệ, cần phải thực hiện truy vấn bổ sung qua Giao thức trạng thái chứng chỉ trực tuyến (OCSP). Thay vì yêu cầu người dùng thực hiện truy vấn OCSP đã cho, chúng ta có thể thực hiện nó trên máy chủ, lưu trữ kết quả và phục vụ phản hồi OCSP cho khách hàng, trong quá trình TLS handshake. Nó được gọi là OCSP stapling
12345678
server { ssl_stapling on; ssl_stapling_verify on; # Xác minh phản hồi OCSP ssl_trusted_certificate /etc/nginx/ssl/lemonfrog.pem; # khai báo cho nginx vị trí của tất cả các chứng chỉ trung gian resolver 8.8.8.8 8.8.4.4 valid=86400s; # độ phân giải của tên máy chủ phản hồi OCSP resolver_timeout 5s;}
Dưới đây là một số header, đáng để bật tính bảo mật. Để biết thêmheader và thông tin chi tiết, bạn chắc chắn nên xem OWASP Secure Headers Project.
Ciết tắt HSTS, thực thi tác user-agent để gửi tất cả yêu cầu đến nguồn gốc (origin) qua HTTPS.
1
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
Cho biết liệu trình duyệt có nên hiển thị hay không một trang trong khung (frame), một thẻ iframe hoặc một thẻ đối tượng (object)
1
add_header X-Frame-Options DENY;
Điều này sẽ ngăn các trình duyệt khỏi đánh hơi các file, loại trừ loại file. File sẽ được hiểu là điều được khai báo trong Content-Type header.
1
add_header X-Content-Type-Options nosniff;
Một phương pháp hay khác là ẩn thông tin về máy chủ web của bạn, trong trường response header HTTP:
1
Server : nginx/1.13.2
Điều này có thể được thực hiện bằng cách tắt server_tokens directive
1
server_tokens off;
Cập nhật mới nhất có thể tìm thấy ở đây
Đối với mục đích thử nghiệm sử dụng staging environment, để không phải exhaust rate limits.
123
certbot certonly --webroot --webroot-path /var/www/netguru/current/public/ \ -d foo.netguru.co \ -d bar.netguru.co
Hãy chắc chắn rằng nó có thể được gia hạn đúng cách
1
certbot renew --dry-run
Đảm bảo bạn đã thêm gia hạn tự động vào crontab. Chạy crontab -e và thêm dòng sau:
1
0 3 * * * /usr/bin/certbot renew --quiet --renew-hook "/usr/sbin/nginx -s reload"
Kiểm tra xem SSL có hoạt động bình thường không thông qua ssllabs
Cảm ơn các bạn đã đọc đến đây. Loạt bài này sẽ không thể có được nếu không có số lượng lớn tài nguyên được tìm thấy trên internet. Dưới đây là một số trang web tuyệt vời mà mình thấy đặc biệt hữu ích khi viết loạt bài này: