Bạn luôn có thể mã hóa lưu lượng giữa bất kỳ hệ thống nào thuộc một nhóm xác định. Chế độ vận chuyển IPsec được tạo riêng cho điều đó. Việc các máy chủ đó đảm nhận vai trò nào, phụ trợ, giao diện người dùng, v.v. không quan trọng, chúng chỉ là các nút IP trong trường hợp này. Hãy coi đây là một giải pháp chung khiến "có, có thể" trở thành câu trả lời hợp lệ cho tất cả các câu hỏi như "có thể mã hóa lưu lượng giữa A và B không". Tuy nhiên, đôi khi nó không thuận tiện và thường có những lựa chọn khác.
Các tùy chọn khác phụ thuộc vào cho mục đích nào bạn cần mã hóa này. Đừng trả lời "chỉ để bảo mật", không có thứ gọi là "chỉ để bảo mật". Có các mô hình mối đe dọa và có các mô hình bảo mật đối phó với các mối đe dọa đã xác định đó. Ví dụ: nói một cách đơn giản, mô hình mối đe dọa đối với HTTP là kẻ ở giữa có thể nghe lén và đưa dữ liệu của chính nó vào, tự mạo danh mình là một máy chủ hợp lệ và/hoặc một máy khách hợp lệ; HTTPS được thiết kế để biến điều này thành không thể bằng cách mã hóa và ký tất cả các giao tiếp. MitM tốt nhất có thể vượt qua tất cả lưu lượng truy cập mà không thể nghe lén hoặc chỉ làm gián đoạn liên lạc hoàn toàn. Vậy thì sao bạn đang bảo vệ chống lại, các mối đe dọa của bạn là gì?
Mạng của bạn giữa các phụ trợ và bộ cân bằng không đáng tin cậy? Tại sao? Những mạng đó chỉ nên bao gồm các bộ cân bằng và phụ trợ và không có gì khác, bạn có những tác nhân không đáng tin cậy nào ở đó? Tuy nhiên, IPsec ở chế độ vận chuyển là giải pháp chấp nhận được trong trường hợp này, vì nó sẽ mã hóa mọi thứ trên dây.
Bạn cũng có thể sử dụng HTTPS giữa bộ cân bằng và phụ trợ (và giữa chính các phụ trợ). Không sao, bộ cân bằng của bạn sẽ chấm dứt HTTPS của người dùng, xem yêu cầu và trả lời bằng văn bản thuần túy, có thể xử lý chúng (thêm/xóa/thay đổi tiêu đề) và có thể chọn phần phụ trợ và xử lý bằng cách phân tích nội dung, ví dụ: chọn một phần phụ trợ cho nội dung tĩnh và khác cho nội dung động. Sau đó nó sẽ thành lập nữa Kết nối HTTPS đến phụ trợ. Các máy khách HTTPS duy nhất cho các chương trình phụ trợ sẽ là các bộ cân bằng và các chương trình phụ trợ khác, vì vậy việc họ sử dụng các chứng chỉ được công nhận lại trên toàn cầu là không quan trọng. (Ví dụ: Google Frontends không kiểm tra chứng chỉ của các phụ trợ HTTPS nằm bên trong Google Cloud, do đó, ngay cả chứng chỉ tự ký cũng sẽ hoạt động.) Bạn có thể tạo CA nội bộ của riêng mình, cấp chứng chỉ cho tất cả các phụ trợ và bộ cân bằng và làm cho chúng đáng tin cậy bằng cách cài đặt chứng chỉ CA đó trong cửa hàng của mỗi hệ thống. Chỉ các bộ cân bằng mới cần phải định cấu hình các chứng chỉ hợp lệ toàn cầu và chỉ ở phía máy khách. Tự động hóa Let's Encrypt có thể cũng sẽ là nhiệm vụ của những bộ cân bằng đó, bởi vì các chứng chỉ đã cấp sẽ được cài đặt trên chúng.
Bạn không tin tưởng cân bằng tải của bạn? Truyền qua SSL có thể hữu ích, nhưng nó cũng có nhược điểm riêng. Trong thiết lập này, người cân bằng là một trong những người ở giữa mà HTTPS được tạo ra chống lại họ. Vì vậy, nó không thể truy cập các chi tiết HTTP để cân bằng các yêu cầu, thậm chí biết giá trị tiêu đề Máy chủ http để phân biệt các vhost; nó không thể thêm các tiêu đề proxy bổ sung như các tiêu đề "được ủy quyền cho", v.v.; các kết nối được bảo vệ khỏi nó như mong đợi.Tất cả những gì nó có thể làm là hy vọng theo dõi kết nối và nếu không thì chuyển tiếp các gói một cách mù quáng đến một số phụ trợ. Trong trường hợp này, bạn không định cấu hình bất kỳ chứng chỉ nào trên đó và thậm chí không định cấu hình bất kỳ tên máy chủ nào. Chỉ cần chỉ định IP của phụ trợ. Ngoài ra, trong trường hợp này, các chứng chỉ hợp lệ phải được cài đặt trên tất cả các phụ trợ, vì không biết trước phụ trợ nào sẽ nhận được yêu cầu nào.
