SSL Passthrough và SSL Offloading

1. Giới thiệu

Trong thời đại internet hiện nay, việc đảm bảo bảo mật dữ liệu trong quá trình truyền tải là vô cùng quan trọng. Công nghệ SSL (Secure Sockets Layer) và kế thừa của nó là TLS (Transport Layer Security) chính là giải pháp chuẩn mực giúp mã hóa dữ liệu giữa client và server.

Khi triển khai hệ thống, đặc biệt khi sử dụng Load Balancer, có 3 phương pháp phổ biến để xử lý lưu lượng SSL: SSL PassthroughSSL Offloading.

Trong bài viết này, mình sẽ chia sẻ chi tiết ba kỹ thuật này.

2. SSL Termination là gì?

SSL Termination gần giống SSL Offloading, nhưng sau khi Load Balancer giải mã SSL từ client, nó sẽ tạo lại một kết nối SSL mới từ Load Balancer đến backend server.

Sơ đồ minh họa

Client (HTTPS)
   |
   v
Load Balancer (giải mã SSL)
   |
   v
Load Balancer (mã hóa SSL mới)
   |
   v
Backend Server (giải mã SSL)

Khi nào dùng SSL Termination?

Nếu bạn vừa cần:

  • Kiểm tra, phân tích nội dung ngay trên Load Balancer,
  • Vừa muốn bảo mật dữ liệu nội bộ giữa Load Balancer và Server.

So sánh nhanh ba phương án

Tiêu chíSSL PassthroughSSL OffloadingSSL Termination
Giải mã SSL tại LB?Không
Giữ end-to-end SSL?Không
LB có thể kiểm tra nội dung?Không
Phức tạp quản lý SSLCao (server phải tự SSL)Trung bình (LB quản lý)Cao (LB và backend đều phải SSL)

Ví dụ.

server {
    listen 80;
    listen 443 ssl;
    server_name wiki.hoanghd.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    location / {
        return 301 https://sysnote.com$request_uri;
    }
}

Giải thích:

  • listen 443 ssl;: Nginx nhận kết nối SSL/TLS tại cổng 443.
  • ssl_certificatessl_certificate_key: Khai báo chứng chỉ SSL để Nginx tự giải mã kết nối SSL từ client.
  • Khi Nginx nhận được yêu cầu HTTPS, nó giải mã yêu cầu, xử lý nội dung HTTPredirect 301 sang https://sysnote.com$request_uri.

Như vậy:

  • Client gửi HTTPS ➔ Nginx tiếp nhận ➔ Nginx giải mã SSL.
  • Sau đó, Nginx dùng HTTP để gửi lệnh chuyển hướng 301.

Đây là kiểu “SSL Termination” vì Nginx chấm dứt kết nối SSL tại chính nó — rồi sau đó nó xử lý nội dung theo cách thông thường (trong trường hợp này là redirect).

Điểm lưu ý thêm:

  • Nếu bạn chỉ giải mã tại Nginx rồi chuyển sang backend bằng HTTP không mã hóa thì hoàn toàn là SSL Offloading.
  • Nếu sau khi giải mã xong, bạn mã hóa lại và gửi tiếp đến backend (dùng HTTPS giữa Nginx và backend), thì lúc đó chính xác mới gọi là SSL Termination kiểu re-encryption.

Nhưng trong ví dụ này, do không có backend server (chỉ redirect), nên đơn giản gọi đây là SSL Termination trên Nginx.

3. SSL Passthrough là gì?

SSL Passthrough là phương pháp cho phép lưu lượng SSL (đã mã hóa) đi thẳng qua Load Balancer mà không bị giải mã hay thay đổi. Nói cách khác, Load Balancer chỉ đơn thuần là một cầu nối trung gian, không chạm vào nội dung dữ liệu.

Cách hoạt động của SSL Passthrough

  • Client gửi yêu cầu SSL đến Load Balancer.
  • Load Balancer chuyển tiếp toàn bộ lưu lượng SSL này tới Server đích mà không can thiệp vào nội dung.
  • Server đích mới là nơi giải mã SSL và xử lý yêu cầu.

Sơ đồ minh họa

Client (HTTPS) ---> Load Balancer (chỉ chuyển tiếp) ---> Server (giải mã SSL và xử lý)

Ví dụ thực tế

Bạn có một ứng dụng ngân hàng online. Vì yêu cầu bảo mật rất cao (chuẩn PCI DSS), bạn không muốn bất kỳ thành phần trung gian nào (kể cả Load Balancer) chạm vào dữ liệu nhạy cảm. Bạn chọn SSL Passthrough để đảm bảo dữ liệu được mã hóa từ trình duyệt khách hàng đến server mà không ai khác có thể xem nội dung bên trong.

Ưu điểm của SSL Passthrough

  • Bảo mật cao nhất: Dữ liệu không bị giải mã giữa đường.
  • Đơn giản cho Load Balancer: Không phải xử lý SSL handshake hay giải mã.
  • End-to-End Encryption: Mã hóa xuyên suốt từ client đến server.

Nhược điểm

  • Load Balancer không thể kiểm tra nội dung: Không thể dùng WAF, IDS, hay routing thông minh theo nội dung.
  • Quản lý SSL phức tạp hơn: Mỗi server backend đều phải có SSL certificate hợp lệ.

Quay lại ví dụ phần SSL Termination ở trên, nếu muốn chuyển ví dụ trên sang SSL Passthrough, thì Nginx không được giải mã SSL nữa.

Tức là:

  • Nginx chỉ chuyển tiếp (proxy) nguyên gói tin SSL đến backend server (là server đích, có chứng chỉ SSL).
  • Nginx không cấu hình ssl_certificate, cũng không listen ssl.
  • Mọi việc SSL handshake, mã hóa/giải mã sẽ do backend server xử lý.

Cách thực hiện:

Thông thường, Nginx bản chuẩn không hỗ trợ SSL Passthrough trực tiếp.
Để làm SSL Passthrough, bạn cần:

  • Dùng Nginx stream module (stream block) để TCP-level proxy (không HTTP-level).
  • Hoặc dùng HAProxy nếu muốn Passthrough SSL đơn giản hơn.

Ví dụ config SSL Passthrough bằng Nginx Stream:

# Cấu hình stream block để passthrough TCP kết nối SSL
stream {
    server {
        listen 443;
        proxy_pass backend_ssl_server:443;
    }
}

Giải thích:

  • listen 443: Lắng nghe TCP connection SSL từ client.
  • proxy_pass backend_ssl_server:443;: Chuyển tiếp thẳng luồng TCP đến backend (server chứa SSL certificate thật).

Trong đó backend_ssl_server có thể là IP hoặc domain backend thật sự (VD: 192.168.1.100).

Cách config backend_ssl_server là gì?

Giả sử backend server (ví dụ sysnote.com) đã có SSL certificate. Nginx chỉ chuyển tiếp TCP SSL, backend server sẽ:

  • Tiếp tục thực hiện SSL handshake với client.
  • Tự giải mã SSL.

Vậy quay lại ví dụ của bạn:

Nếu chuyển từ SSL Termination sang SSL Passthrough, thì bạn:

  • Bỏ toàn bộ ssl_certificate, ssl_certificate_keylisten 443 ssl.
  • Thay bằng stream proxy ở cấp TCP.

Sơ đồ minh họa:

Nếu là SSL Termination (ban đầu):

Client ---HTTPS---> [Nginx Giải Mã SSL] ---HTTP redirect---> sysnote.com

Nếu chuyển sang SSL Passthrough:

Client ---HTTPS---> [Nginx TCP Forwarding] ---HTTPS---> Backend server (sysnote.com)

(SSL giữ nguyên từ client tới backend, Nginx không động chạm vào gói tin)

Lưu ý thêm:

  • Stream module phải được bật (--with-stream) khi build Nginx.
  • Khi SSL Passthrough, Nginx không làm được các việc như redirect, rewrite, WAF, hay load balancing HTTP thông minh… vì chỉ xử lý TCP thôi.

4. SSL Offloading là gì?

SSL Offloading là phương pháp giải mã SSL ngay tại Load Balancer, sau đó chuyển dữ liệu dạng HTTP (không mã hóa) xuống các server backend.

Cách hoạt động của SSL Offloading

  • Client gửi yêu cầu SSL đến Load Balancer.
  • Load Balancer giải mã SSL và nhận nội dung HTTP thuần.
  • Load Balancer có thể phân tích nội dung, thực hiện routing, caching, kiểm tra bảo mật.
  • Load Balancer chuyển nội dung HTTP thuần này đến các server backend.

Sơ đồ minh họa

Client (HTTPS)
   |
   v
Load Balancer (giải mã SSL)
   |
   v
Backend Server (HTTP)

Ví dụ thực tế

Bạn điều hành một website bán hàng online, có nhu cầu kiểm tra các request để chặn các yêu cầu lạ (ví dụ: SQL Injection, XSS Attack). Bạn chọn SSL Offloading để Load Balancer có thể dễ dàng lọc nội dung requestáp dụng firewall ứng dụng web (WAF).

Ưu điểm của SSL Offloading

  • Giảm tải cho server backend: Server không cần giải mã SSL nữa.
  • Load Balancer có thể kiểm tra nội dung: Cho phép thực hiện WAF, routing theo URL, caching, v.v.
  • Tối ưu hiệu năng tổng thể.

Nhược điểm

  • Dữ liệu giữa Load Balancer và Backend server không mã hóa (nếu không dùng thêm SSL nội bộ).
  • Tiềm ẩn rủi ro nếu mạng nội bộ không được bảo vệ kỹ.

Nếu chuyển ví dụ của bạn sang SSL Offloading, thì Nginx sẽ giải mã SSL tại chính Nginx và sau khi giải mã, nó sẽ chuyển tiếp (proxy) HTTP không mã hóa tới backend server.

Cách thực hiện SSL Offloading trong ví dụ của bạn:

  • Nginx sẽ xử lý SSL handshake và giải mã SSL khi client gửi yêu cầu.
  • Sau khi SSL được giải mã, Nginx sẽ chuyển tiếp yêu cầu HTTP không mã hóa (dù là HTTPS khi đến Nginx, nhưng đã được giải mã).
  • Backend server sẽ nhận HTTP không mã hóa và xử lý thông tin bình thường.

Cấu hình ví dụ SSL Offloading:

server {
    listen 80;
    listen 443 ssl;
    server_name wiki.hoanghd.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    location / {
        # SSL Offloading: Giải mã SSL rồi chuyển tiếp HTTP không mã hóa
        proxy_pass http://backend_server; # Backend sẽ nhận HTTP
        proxy_set_header Host $host;      # Giữ nguyên tên host
        proxy_set_header X-Real-IP $remote_addr;  # Giữ IP gốc của client
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # Tiếp tục theo dõi chuỗi IP
        proxy_set_header X-Forwarded-Proto $scheme;  # Gửi thông tin protocol (http/https)
    }
}

Giải thích:

  • listen 443 ssl;: Nginx vẫn tiếp nhận kết nối SSL ở cổng 443.
  • ssl_certificatessl_certificate_key: Nginx sử dụng chứng chỉ SSL để giải mã các kết nối HTTPS từ client.
  • proxy_pass http://backend_server;: Sau khi giải mã SSL, Nginx chuyển tiếp HTTP không mã hóa đến backend server.

Cách hoạt động:

  • SSL Handshake: Client kết nối tới wiki.hoanghd.com bằng HTTPS.
  • Giải mã SSL tại Nginx: Nginx tiếp nhận yêu cầu và giải mã SSL.
  • Chuyển tiếp HTTP không mã hóa: Sau khi giải mã, Nginx gửi yêu cầu HTTP đến backend server (có thể là http://sysnote.com).
  • Backend xử lý HTTP: Backend server nhận yêu cầu HTTP và xử lý nó bình thường (như một kết nối HTTP tiêu chuẩn).

Sơ đồ minh họa:

Client ---HTTPS--> [Nginx Giải Mã SSL] ---> [Nginx chuyển HTTP tới Backend] ---> Backend server (sysnote.com)

(SSL được giải mã tại Nginx, backend server nhận HTTP không mã hóa)

Các lưu ý khi sử dụng SSL Offloading:

  • Hiệu suất: Khi sử dụng SSL Offloading, Nginx sẽ đảm nhận toàn bộ quá trình giải mã SSL, giúp giảm tải cho backend server.
  • Không giữ được mã hóa: Mối quan hệ giữa client và backend server không còn mã hóa SSL nữa (nếu không sử dụng HTTPS giữa Nginx và backend).
  • Thông tin gốc: Cần sử dụng các headers như X-Forwarded-For để đảm bảo backend nhận được thông tin đúng về client (IP gốc, protocol…).

5. Một ví dụ hệ thống thực tế

5.1. Triển khai SSL Passthrough cho ứng dụng tài chính

  • Ứng dụng: Cổng thanh toán điện tử.
  • Yêu cầu: Bảo mật dữ liệu thẻ tuyệt đối.
  • Giải pháp: Sử dụng SSL Passthrough từ Load Balancer đến từng server dịch vụ.

5.2. Triển khai SSL Offloading cho web bán hàng

  • Ứng dụng: Website TMĐT bán hàng đa quốc gia.
  • Yêu cầu: Kiểm tra nội dung yêu cầu để phát hiện gian lận và tối ưu SEO.
  • Giải pháp: Dùng SSL Offloading tại Load Balancer + thêm WAF + routing thông minh.

6. Kết luận

Việc chọn SSL Passthrough, SSL Offloading hay SSL Termination phụ thuộc vào:

  • Yêu cầu bảo mật,
  • Hiệu suất mong muốn,
  • Khả năng phân tích lưu lượng.

Hiểu rõ cách mỗi phương pháp hoạt động sẽ giúp bạn tối ưu hệ thống, vừa đảm bảo bảo mật vừa đảm bảo hiệu năng.

Nếu bạn đang làm việc trên các hệ thống cloud, hoặc muốn đơn giản hóa việc quản lý IP tĩnh và SSL, hãy tham khảo các dịch vụ như QuotaGuard — nơi cung cấp giải pháp IP tĩnh linh hoạt, bảo mật cho các cloud app.

Tham khảo https://www.quotaguard.com/blog/ssl-passthrough-vs-ssl-offloading-a-quick-primer/

Bài viết gần đây

spot_img

Related Stories

Leave A Reply

Please enter your comment!
Please enter your name here

Đăng ký nhận thông tin bài viết qua email