Cấu hình tối ưu NGINX tăng tốc và bảo mật Website dùng HTTPS

Tại sao bạn vẫn dùng HTTP ? Câu trả lời của đại đa số Web Master là “HTTPS chậm hơn HTTP”.

Quả thực vậy, trong HTTPS quá trình đàm phán khởi tạo kết nối dài hơn, việc trao đổi Key và Data được mã hóa làm tiêu tốn nhiều tài nguyên giữa Client và Server.

Tuy nhiên chúng ta hoàn toàn có thể tối ưu NGINX Server để khắc phục được yếu điểm này. Bạn gần như sẽ không thấy sự khác nhau giữa việc sử dụng HTTP và HTTPS một số phương pháp được nói đến trong bài: HTTP/2, Cipher Suite, Protocol, Cache SSL/TLS Session, HSTS và OCSP Stapling.

Chỉ cần cấu hình theo đúng hướng dẫn này bạn dễ dàng đạt A+ trên ssllabs.com

Đạt A+ trên ssllabs.com

Mình sẽ làm demo trên hệ thống LEMP Stack.

• Dùng VPS chạy CentOS 7.
• NGINX 1.11.3 bản mới nhất.
• Và sử dụng Certificate Free tại Let’s Encrypt.

Ngoài ra, nếu cần chứng chỉ Comodo PositiveSSL thương hiệu bạn có thể mua của Namecheap hoặc GogetSSL chỉ với khoảng $3, cách cấu hình tối ưu SSL cũng tương tụ như chứng chỉ free của Let’s Encrypt thôi.

Hướng dẫn mua chứng chỉ SSL giá rẻ

1. HTTP/2 – H2

Đầu tiên chúng ta phải nói đến giao thức HTTP/2 – Hypertext Transfer Protocol Version 2.

Tài liệu về HTTP/2 trên mạng nhiều các bạn tự search thêm. Trong bài này các bạn chỉ cần biết đây là một tiêu chuẩn mới được công nhận vào năm 2015. HTTP/2 được Google cho ra đời để khắc phục khiếm khuyết của HTTP/1.x (năm 1989) và SPDY (năm 2009) đem lại tốc độ bá đạo cho trang web của bạn.

HTTP/2 có những đặc điểm mà bạn cần biết.

• HTTP/2 truyền data ở dạng nhị phân (binary) không phải text như HTTP/1, nên cực kỳ nhanh.
• Một connection có thể xử lý được nhiều request cùng lúc. Với HTTP/1 cùng một connection các request phải chờ để được xử lý.
• Header Compression, header được nén làm giảm tổng dùng lượng data gửi đi.
• Data được mã hóa bởi giao thức SSL/TLS mạnh mẽ.

Chính những lý do trên nên HTTP/2 chỉ hoạt động với website dùng SSL/TLS. Ai chưa biết cách cấu hình SSL/TLS trên NGINX thì đọc lại các bài viết trên THUY SYS DOT COM để rõ hơn.

Nếu dùng web NGINX từ bản 19.5 trở lên thì mặc định nó đã hỗ trợ HTTP/2 rồi, bạn chỉ cẩn thêm đoạn cấu hình bên dưới vào block server {…} là xong.

#Kích hoạt HTTP/2 trên NGINX
listen 443 ssl http2;

Bạn chưa tin tốc độ xử lý siêu tốc của HTTP Version 2 thì xem demo tại đây.

2. Protocol

Mình nói qua một chút về SSL và TLS để mọi người không bị nhầm lẫn.

TLS là Transport Layer Security và SSL là Secure Sockets Layer người ta vẫn thường gọi chung là “SSL”. Đây là hai giao thức khác nhau nhằm mục đích bảo mật dữ liệu. Khi kết hợp với giao thức HTTP ta có HTTPS ( HTTP over SSL và HTTP over TLS).

Sau khi lỗ hổng Heartbleed được công bố năm 2014 SSLv1, SSLv2 thậm trí SSLv3 cũng được khuyến cáo không nên dùng mà chuyển sang dùng giao thức TLS.

Muốn được điểm A+ trên ssllabs.com hãy dùng HTTP over TLS, trên NGINX thêm vào dòng sau.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Bước cấu hình này ảnh hưởng đến toàn cục, bạn cần chú ý để chọn cho mình protocol phù hợp tuy đơn giản mà có ý nghĩa rất lớn tới tính toàn vẹn dữ liệu.

3. TLS Session

TLS được xây dựng dựa trên nền tảng của TCP nên nó là giao thức truyền tin tin cậy, tuy nhiên TLS phức tạp hơn và không phải chỉ có 3 bước.

Full TLS Handshake – https://hpbn.co

Nhìn hình các bạn cũng đã hiểu tại sao HTTPS lại chậm hơn HTTP rồi chứ ?

Trong TLS Handshake, sau khi kết thúc đàm phán 3 bước TCP ( SYN, SYN/ACK, ACK) là đến đàm phán TLS. Tổng thời gian đàm phán đến khi trao đổi dữ liệu sẽ mất khoản ~220ms gấp 4 lần so với TCP Protocol truyền thống.

Nhằm rút ngắn thời gian tăng performance cho HTTPS chúng ta có thể áp dụng kỹ thuật Cache TLS Session.

Trên NGINX Server bạn thêm đoạn cấu hình sau:

ssl_session_cache shared: SSL: 5m;
ssl_session_timeout 20m;

Theo NGINX 1m (megabyte) lưu được 4000 sessions với 5m sẽ cache được 20000 session và session tồn tại trong 20 phút. Với trang web vài nghìn truy cập thế là đủ, thời gian timeout cần linh hoạt cho website vì tần suất một người truy cập lại trên mỗi website là khác nhau.

Sau khi cache lại TLS Session thời gian đàm phán giảm đi đáng kể, khoảng ~60ms

TLS Session Cache – https://hpbn.co

Nếu trên server có nhiều website bạn có thể thêm cấu hình trên vào block http {…} của NGINX để áp dụng cho toàn bộ Virtual Host có trên server.

Để tìm hiểu sâu hơn thì đọc thêm tài liệu này.

4. HSTS

HSTS hay còn gọi là HTTP Strict Transport Security nó có tác dụng ép trình duyệt tương tác với Web Server bằng HTTPS.

HSTS hoạt động thế nào ?

Như các bạn đã biết để chuyển từ HTTP sang HTTPS chúng ta sẽ cấu hình Redirect URL trên Web Server.

Cách hoạt động của Redirect như này:

Trên thực tế gần như 100% người dùng gõ địa chỉ trang web như thế, không mấy ai gõ đầy đủ https://www.thuysys.com. Điều đó sẽ làm Web Browser và Server mất thêm thời gian, tài nguyên trong quá trình khởi tạo kết nối.

HSTS là giải pháp cho vấn đề này. HSTS hoạt động giống như cache trên Web Browser. Lần đầu truy cập website Web Browser vẫn gửi HTTP Request như bình thường và cache lại truy cập này. Từ lần thứ 2, thứ 3. .. truy cập nó sẽ gửi HTTPS Request luôn, hay nói cách khác HSTS thực hiện Redirect 301 ngay tại Browser của bạn.

Khi HSTS được Enable tốc dộ truy cập Web Site sẽ tăng lên đáng kể. Cái quan trọng nhất nó sẽ ngăn chặn hacker tấn công Middle Attack tại bước trao đổi HTTP Request giữa Web Browser và Web Server . Hiện tại kiến trúc Protocol SSLv3 và TLS 1.0 đều dính lỗi này. Theo mình với các web thương mại điện tử nên dùng Protocol TLSv1.1, TLSv1.2 cho an toàn.

Để kích hoạt HSTS trên NGINX bạn thêm vào block server {…} đoạn bên dưới.

#Thời gian cache là 1 năm bao gồm cả subdomain
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

HSTS là tiêu chí được ssllabs.com đánh giá rất cao, nếu muốn có điểm A+ thì phải cấu hình HSTS cho Website.

5. Cipher Suite

Cipher là bộ mã hóa được dùng để tham gia đàm phán TLS Handshake. Có nhiều thuật toán được dùng cho Cipher suite, để tốt nhất bạn dùng thuật bên dưới, cũng thêm cấu hình vào block server {…} như ở trên.

ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

Đây chỉ là bước chọn thuật toán mã hóa, muốn khắt khe hơn bạn có thể dùng bộ thuật toán bên dưới. Hiển nhiên mã hóa càng mạnh thì càng mất nhiều tài nguyên xử lý và mức độ tương thích với hệ điều hành và trình duyệt càng bị thu hẹp.

ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

6. OCSP Stapling

Chúng ta điểm lại cách hoạt động của HTTPS một chút.

1. Khi người dùng truy cập trang web bằng HTTPS  Web Server sẽ gửi Certificate của nó cho Web Browser, tuy nhiêu cũng không có gì đảm bảo Certificate này không bị giả mạo. Để chắc chắn Web Browser sẽ gửi thông tin của Certificate này cho bên thứ 3 được gọi là CA – đơn vị cung cấp Certificate cho Web Server. Quá trình kiểm tra đó gọi là OCSP hay Online Certificate Status Protocol một giao thức để kiểm tra “tính hợp lệ” của Certificate qua internet.
2.  Hệ thống chứng chỉ toàn cầu được phân cấp theo hình cây. Root CA là mức cao nhất sau đó đến Intermediate CA. Comodo, GlobalSign, Verisign, Let’s Encrypt … chỉ ở cấp Intermediate CA thôi.

Muốn xem thông tin về OCSP bạn mở certificate của website trên Web Browser ra xem phần Authority Infomation Access.

Online Certificate Status Protocol

Với cách hoạt động ở trên, mỗi khi truy cập web bằng HTTPS, Web Browser sẽ kết nối OCSP của CA để kiểm tra “tính hợp lệ” của Certificate. Đó là vấn đề lớn với OCSP khi một site nào đó có lượng truy cập khủng, nó sẽ tiêu tốn lượng tài nguyên rất lớn của OCSP.

Không chỉ có thế, khi gặp sự cố mất kết nối đường truyền dẫn đến không xác minh được “tính hợp lệ” thì kết nối HTTPS có nguy cơ bị phá vỡ, cũng từ nguyên nhân đó hacker hoàn toàn có thể lợi dụng để DoS làm OCSP Server tê liệt.

Và OCSP Stapling là giải pháp cho vấn đề đó. Lúc này Web Server sẽ thay Web Browser kết nối đến máy chủ OCSP lấy thông tin về “tính hợp lệ” của Certificate rồi lưu trên server. Khi người dùng truy cập website, Web Server sẽ gửi Certificate kèm theo thông tin “tính hợp lệ” cho Web Browser.

Bạn hoàn toàn yên tâm thông tin mà OCSP gửi cho Web Server đã được ký bởi CA và không thể giả mạo từ phía Web Server. Bất kỳ trình duyệt nào cũng có CA Store lưu toàn bộ chứng chỉ của Root CA, Intermediate CA để kiểm tra tính chính xác của bất kỳ chứng chỉ nào.

Cấu hình SSL Stapling trên NGINX

# Enable OCSP
 ssl_stapling on;
 ssl_stapling_verify on;

#Mình dùng DNS của Linode phân giải truy vấn đến OCSP Server với timeout là 5s, bạn dùng 8.8.8.8 của google cũng được nhé.
#valid là thời gian Web Server cache lại response từ OCSP, mình để 300s.
 resolver ns1.linode.com ns2.linode.com valid=300s;
 resolver_timeout 5s;

#Dùng Let's Encrypt thì không cần dòng này.
#Chỉ cần chỉ thị ssl_certificate là cỏ đủ hết thông tin rồi.
 ssl_trusted_certificate /etc/letsencrypt/live/thuysys.com/chain.pem;

Trên đây là một số phương pháp tối ưu đơn giản giúp tăng tốc và nâng cao bảo mật cho trang web HTTPS rất hiệu quả.

Quả thật sau khi nâng cấp HTTP lên HTTPS mình không thấy truy cập chậm đi tí nào ngược lại thấy chạy mượt hơn. Bạn nào dùng HTTPS mà thấy chậm hơn thì cho ý kiến phát để anh em cùng thảo luận.

Bạn có thể kết hợp thêm cách tạo cache trên nginx để website đạt tốc độ cao nhất.

Cảm ơn và hẹn gặp lại ở bài tới.