stunnel bảo vệ kết nối proxy: xác minh chứng chỉ TLS thật
stunnel bảo vệ kết nối proxy bằng cách bọc đoạn đường giữa máy anh em và máy chủ proxy trong TLS, nhưng chỉ an toàn khi có xác minh chứng chỉ. ProxyVN viết bài này theo tài liệu chính thức stunnel, kèm lab chứng chỉ đã chạy thật bằng curl và Python.
stunnel bảo vệ kết nối proxy là gì và khác proxy IP thuê ở điểm nào
stunnel là chương trình bọc TLS cho dịch vụ TCP. Trang GitHub của dự án mô tả nó là lớp mã hóa SSL giữa client từ xa và máy chủ, giúp những chương trình không biết TLS vẫn có mã hóa và xác thực mà không phải sửa mã. Nó không biết gì về HTTP hay SOCKS. Nó chỉ nhận một cổng TCP và nói TLS ở cổng kia.
Vì vậy stunnel đứng cạnh proxy, không thay thế proxy. Proxy vẫn là Squid, 3proxy hay phần mềm khác nói HTTP hoặc SOCKS5. stunnel thêm một lớp mã hóa quanh đoạn đường tới proxy đó.
Khác proxy IP thuê ở điểm nào
Anh em thuê proxy để website đích thấy một địa chỉ IP khác. stunnel không cấp IP và không đổi IP. Nó không làm cho IP của anh em sạch hơn hay giống IP dân cư hơn. Nó chỉ bảo vệ nội dung đi giữa hai điểm của anh em, khỏi người đứng giữa đường đọc hoặc sửa.
Khi dùng proxy HTTP thường, tên đăng nhập và mật khẩu proxy đi trần qua mạng. Bài mã hóa proxy là gì giải thích khoảng trống này. stunnel là một trong những cách lấp nó, với điều kiện cả hai đầu đều do anh em kiểm soát.
Một giới hạn thực tế với proxy mua của nhà cung cấp
Để TLS có tác dụng, phía máy chủ proxy cũng phải có đầu TLS, tức là một cổng nhận TLS rồi chuyển vào proxy. Với proxy thương mại, đầu đó do nhà cung cấp quyết định, không phải anh em. Mình không có thông tin cho biết gói nào ở Proxy.vn cung cấp cổng TLS riêng, nên anh em hỏi nhà cung cấp trước khi lập kế hoạch.
stunnel vì thế hợp nhất với hai tình huống. Một là proxy tự dựng trên VPS của anh em, nơi anh em đặt stunnel ở cả hai đầu. Hai là nhà cung cấp có cổng TLS sẵn và anh em dùng stunnel ở chế độ client để nói chuyện với nó mà không phải sửa ứng dụng.
Không phải cách sửa mọi ERR_PROXY_CERTIFICATE_INVALID
Bài ERR_PROXY_CERTIFICATE_INVALID đã có đoạn cấu hình stunnel ở chế độ server cho proxy HTTP chạy cổng 8080. Bài này đi theo hướng khác: chế độ client, xác minh chứng chỉ, và những trường hợp stunnel không giúp được gì. Nhiều lỗi chứng chỉ có nguyên nhân ở chỗ khác, và đặt stunnel vào chỉ chuyển lỗi đi chỗ khác hoặc, tệ hơn, giấu nó.
Phạm vi đã thử và chưa thử
Mình không chạy stunnel. Môi trường soạn bài chặn việc tải và chạy bản cài đặt stunnel cho Windows, và máy không có Docker hay bản phân phối WSL. Trang tải về của stunnel liệt kê bản 5.82 cùng các bản beta 5.83.
Phần mình chạy thật là lab chứng chỉ. Python dựng một CA riêng và nhiều chứng chỉ máy chủ, một lớp bọc TLS bằng Python đứng thay vai stunnel ở chế độ server, rồi curl 8.13 và Python kiểm tra xem mỗi ca báo gì. Các thông báo lỗi là của curl và OpenSSL của Python. Chúng không phải thông báo của stunnel. Cấu hình stunnel trong bài là theo tài liệu và chưa chạy.
Bọc một kết nối lab bằng TLS: stunnel bảo vệ kết nối proxy ở hai đầu
stunnel có hai chế độ. Phân biệt chúng là bước đầu tiên.
Chế độ server và chế độ client
Theo FAQ của stunnel, chế độ server là mặc định. stunnel nhận kết nối TLS và chuyển lưu lượng đã giải mã tới dịch vụ khai ở `connect`. Chế độ client bật bằng `client = yes`. Khi đó stunnel nhận dữ liệu thường, thường ở địa chỉ loopback, rồi thiết lập TLS tới đích khai ở `connect`.
Với proxy, mô hình hai đầu trông như sau. Trên máy chủ proxy, stunnel server nhận TLS ở cổng 8443 và chuyển vào proxy ở `127.0.0.1:3128`. Trên máy của anh em, stunnel client nhận kết nối thường ở `127.0.0.1:3128` và nối TLS tới cổng 8443 của máy chủ. Trình duyệt hay công cụ chỉ cần trỏ vào `http://127.0.0.1:3128`.
Hai đầu, hai trách nhiệm xác minh
Ở mô hình trên, trình duyệt không còn thấy chứng chỉ của proxy. Việc xác minh chuyển sang stunnel client. Nếu stunnel client không được cấu hình để xác minh, anh em có kết nối mã hóa tới một đối tượng chưa được xác nhận. Đây là điểm quan trọng nhất của bài.
Giá trị mặc định của `verifyChain` trong manual là `no`. Tài liệu viết thêm: để xác minh chứng chỉ máy chủ, điều thiết yếu là phải yêu cầu thêm một chứng chỉ cụ thể bằng `checkHost` hoặc `checkIP`. Hai thứ đi cùng nhau.
Nối qua proxy HTTP: protocol = connect
Hai đầu stunnel quanh một proxy HTTP
stunnel còn một cách dùng gần với chủ đề của Proxy.vn. FAQ hướng dẫn kết nối qua proxy HTTP bằng trình xử lý HTTP CONNECT phía client. `connect` là địa chỉ của proxy, còn `protocolHost` là máy chủ TLS cuối cùng. Nếu proxy cần tài khoản, khai `protocolUsername` và `protocolPassword`.
Cách này khác mô hình hai đầu ở trên. Ở đây proxy HTTP là chặng trung gian để stunnel client đến được một máy chủ TLS khác. Tài liệu lưu ý khi dùng `checkHost`, giá trị phải mô tả máy chủ TLS cuối, không phải listener cục bộ, bộ cân bằng tải hay proxy HTTP.
stunnel khác SSH tunnel ở đâu
Bài về SSH ProxyJump và proxy tunnel mô tả các cách đi vòng khác. SSH tunnel dựa trên khóa SSH và máy chủ SSH. stunnel dựa trên chứng chỉ X.509 và một cổng TLS. Cái nào tiện hơn tùy hạ tầng anh em đang có.
Chuẩn bị lab stunnel bảo vệ kết nối proxy: CA, chứng chỉ, listener, backend
Lab trong bài tách phần chứng chỉ ra để kiểm tra riêng, vì phần này sinh ra nhiều lỗi nhất.
Dựng CA và chứng chỉ bằng Python
Mình dùng thư viện `cryptography` của Python 3.12 để tạo một CA tên "Lab CA" và sáu chứng chỉ máy chủ. Mỗi chứng chỉ phục vụ một ca thử.
Chứng chỉ |
Do ai cấp |
Nội dung |
|---|---|---|
leaf_dns |
Lab CA |
SAN chỉ có DNS localhost |
leaf_dns_ip |
Lab CA |
SAN có DNS localhost và IP 127.0.0.1 |
leaf_other |
Lab CA |
SAN chỉ có tên khac.lab.test |
leaf_expired |
Lab CA |
Hết hạn từ trước (hiệu lực 2 ngày, bắt đầu từ 10 ngày trước) |
leaf_selfsigned |
Tự ký |
SAN có DNS localhost |
leaf_impostor |
"Impostor CA" khác |
SAN có DNS localhost, giả làm máy chủ thật |
Một proxy HTTP giả chạy ở cổng 18080, chỉ trả về dòng yêu cầu nó nhận được. Nhờ đó mình biết dữ liệu có tới được phía sau lớp TLS hay không. Mỗi chứng chỉ có một cổng TLS riêng từ 18443 đến 18448, cùng chuyển vào proxy giả.
Vì sao dùng Python thay vì stunnel
Nếu chạy được stunnel thật, lab vẫn có cấu trúc đó. Mình chọn Python để chạy được với những gì có sẵn trên máy. Python TLS wrapper làm đúng việc của stunnel server: nhận TLS, chuyển byte đã giải mã tới backend. Phần được kiểm tra, tức hành vi xác minh chứng chỉ ở phía client, là hành vi của curl và OpenSSL, nên kết quả vẫn có ý nghĩa với việc đoán stunnel client sẽ gặp gì.
Cái lab không chứng minh: stunnel chạy đúng cấu hình nào, log của stunnel viết gì, `checkHost` của stunnel có cùng hành vi với curl về mọi chi tiết hay không. Với những việc đó, FAQ và manual của stunnel là nguồn.
Công cụ client
curl 8.13.0 bản Windows dùng Schannel làm thư viện TLS. Mình dùng tùy chọn `--proxy-cacert` để chỉ CA riêng cho proxy HTTPS. Python 3.12 dùng OpenSSL qua mô-đun `ssl`, với `server_hostname` để bật kiểm tra tên.
Có một chi tiết của Schannel. Với CA riêng và chứng chỉ không có điểm phân phối CRL, curl báo `CERT_TRUST_REVOCATION_STATUS_UNKNOWN` dù chuỗi đúng. Mình thêm `--ssl-revoke-best-effort` để bỏ qua việc thiếu thông tin thu hồi. Đây là hành vi riêng của Schannel trên Windows, không phải của OpenSSL, và anh em dùng curl bản khác có thể không gặp.
Cấu hình stunnel bảo vệ kết nối proxy: chế độ server, client, verifyChain, checkHost
Các cấu hình dưới đây lấy từ FAQ và manual của stunnel, chưa chạy trên máy mình.
Máy chủ proxy: stunnel server
foreground = yes
debug = info
[proxy-tls]
accept = 0.0.0.0:8443
connect = 127.0.0.1:3128
cert = /etc/stunnel/server-fullchain.pem
key = /etc/stunnel/private/server.key`accept` là cổng nhận TLS. `connect` là proxy HTTP phía sau, chỉ nghe ở loopback. `cert` phải chứa cả chuỗi chứng chỉ bắt đầu từ chứng chỉ máy chủ, theo manual: tệp nên có toàn bộ chuỗi, từ chứng chỉ thực tới CA gốc tự ký, ở dạng PEM hoặc P12. Chuỗi chứng chỉ là bắt buộc ở chế độ server.
Khóa riêng cần được giữ bí mật. Manual dặn trên Unix dùng `chmod 600`. FAQ cũng có mục riêng về lỗi stunnel từ chối quyền của tệp khóa.
Một cấu hình không có phần `[tên-dịch-vụ]` bị hiểu là cấu hình kiểu inetd, nơi tiến trình khác cấp socket đã nhận. Đó là lý do FAQ có câu hỏi "stunnel khởi động nhưng không nghe cổng".
Máy anh em: stunnel client
foreground = yes
debug = info
[proxy-local]
client = yes
accept = 127.0.0.1:3128
connect = proxy.example.com:8443
verifyChain = yes
CAfile = /etc/stunnel/lab-ca.pem
checkHost = proxy.example.com
sni = proxy.example.comMẫu này gần như trùng ví dụ `local-client` trong FAQ. `client = yes` bật chế độ client. `accept` ở loopback, nên chỉ máy anh em dùng được. `verifyChain = yes` bật kiểm tra chuỗi. `CAfile` là kho tin cậy dành riêng cho dịch vụ này. `checkHost` là tên phải có trong chứng chỉ máy chủ. `sni` gửi tên đó cho máy chủ.
FAQ nói rõ: không dựa vào SNI một mình, vì SNI gửi đi một cái tên nhưng không xác thực nó. Chuyện xác thực nằm ở `verifyChain` cộng `checkHost`. Bài SNI là gì giải thích khái niệm này.
verifyChain và verifyPeer
Tắt xác minh thì kẻ mạo danh qua cửa
FAQ phân biệt hai kiểu. `verifyChain = yes` kiểm chứng chỉ qua một CA tin cậy, và ở chế độ client phải đi kèm `checkHost` hoặc `checkIP`. `verifyPeer = yes` đòi đúng chứng chỉ lá phải được cài sẵn cục bộ trong `CAfile` hoặc `CApath`, tức là ghim chứng chỉ (pinning). Tùy chọn số `verify` đã lỗi thời.
Với lab tự dựng, `verifyChain` cộng CA riêng thường tiện hơn, vì thay chứng chỉ lá khi gia hạn không buộc anh em sửa phía client. `verifyPeer` chặt hơn nhưng mỗi lần gia hạn phải phân phối lại chứng chỉ.
checkHost và checkIP
FAQ viết: tên cần kiểm phải nằm trong phần mở rộng Subject Alternative Name của chứng chỉ lá. Tên DNS dùng `checkHost`, địa chỉ IP dùng `checkIP`. Bộ khớp ký tự đại diện theo luật kiểm tra tên của OpenSSL.
Nếu anh em nối tới proxy bằng địa chỉ IP, chứng chỉ phải có IP trong SAN, và cấu hình phải dùng `checkIP`. Đây là chỗ lab ở dưới cho thấy một lỗi điển hình.
Kiểm tra cấu hình
FAQ ghi rằng giao diện dòng lệnh hiện tại không có tùy chọn chỉ kiểm tra cấu hình. Cách làm được hướng dẫn: đặt `foreground = yes` và `debug = info` rồi chạy `stunnel /đường/dẫn/stunnel.conf` khi thử lần đầu. stunnel báo lỗi cú pháp và lỗi nạp chứng chỉ, khóa, hoặc mở cổng. Nếu khởi tạo thành công, nó tiếp tục chạy, dừng bằng Ctrl+C.
Manual cũng khuyên đừng dùng mức `debug = debug` trừ khi nhà phát triển yêu cầu. Mức mặc định là `notice`.
Phiên bản TLS và bộ mã
Manual ghi `sslVersionMin` mặc định là TLSv1, khi build với OpenSSL 1.1.0 trở lên. Với dịch vụ mới, anh em nên đặt rõ mức tối thiểu cao hơn. Mình không đưa giá trị khuyến nghị cụ thể, vì mức phù hợp đổi theo phiên bản OpenSSL mà bản stunnel của anh em đang dùng. Bài ERR_SSL_VERSION_OR_CIPHER_MISMATCH nói về hệ quả khi hai đầu không có phiên bản chung.
Chạy ca đúng và sai: stunnel bảo vệ kết nối proxy và xác minh chứng chỉ
Đây là phần mình đã chạy thật. Mỗi ca gọi proxy HTTP giả qua cổng TLS bằng `curl -x https://...`.
Bảng kết quả
11 ca lỗi chứng chỉ trong lab
Ca |
Điều kiện |
Kết quả curl 8.13 (Schannel) |
|---|---|---|
A |
Không chỉ CA |
Mã 60, `SEC_E_UNTRUSTED_ROOT`: chuỗi do tổ chức không được tin cậy cấp |
B |
Có CA, nối bằng tên `localhost`, SAN có DNS localhost |
Mã 0, HTTP 200, backend nhận dòng yêu cầu |
C |
Có CA, nối bằng IP 127.0.0.1, SAN chỉ có DNS |
Mã 60, "SSL peer certificate or SSH remote key was not OK" |
D |
Có CA, nối bằng IP 127.0.0.1, SAN có thêm IP |
Mã 0, HTTP 200 |
E |
Chứng chỉ có tên khác (khac.lab.test) |
Mã 60, không khớp tên `localhost` với tên trong chứng chỉ |
F |
Chứng chỉ hết hạn |
Mã 60, `CERT_TRUST_IS_NOT_TIME_VALID` |
G |
Chứng chỉ tự ký, chỉ có Lab CA |
Mã 60, `CERT_TRUST_IS_UNTRUSTED_ROOT` |
H |
Khai `http://` cho cổng TLS |
Mã 56, kết nối bị reset; phía máy chủ ghi "http request" |
I |
Khai `https://` cho cổng proxy thường |
Mã 35, `SEC_E_INVALID_TOKEN` |
K |
Chứng chỉ do "Impostor CA" cấp, curl dùng `--proxy-insecure` |
Mã 0, HTTP 200 (kẻ mạo danh được chấp nhận) |
L |
Cùng chứng chỉ mạo danh, curl dùng `--proxy-cacert` Lab CA |
Mã 60, `CERT_TRUST_IS_PARTIAL_CHAIN` |
Thêm ba ca bằng Python 3.12 và OpenSSL. Ca xác minh bắt buộc với chứng chỉ mạo danh: lỗi `CERTIFICATE_VERIFY_FAILED ... unable to get local issuer certificate`. Ca tắt xác minh với cùng chứng chỉ: kết nối được và nhận phản hồi từ proxy giả. Ca nối bằng IP với chứng chỉ chỉ có DNS: lỗi `IP address mismatch, certificate is not valid for '127.0.0.1'`.
Đọc từng nhóm ca
Ca A và G cho thấy cùng một triệu chứng từ hai nguyên nhân. Chuỗi không dẫn tới CA mà máy tin. Trong A, anh em chưa chỉ CA riêng. Trong G, chứng chỉ không do CA nào ký. Phía người dùng, hai ca trông gần như nhau. Cách phân biệt là xem ai ký chứng chỉ, bằng `openssl s_client` hoặc `openssl x509 -noout -issuer -subject`.
Ca C, D, E, và ca IP của Python là nhóm tên. Chuỗi hợp lệ, nhưng tên anh em gọi không có trong chứng chỉ. Đây chính là mục "Tại sao checkHost hoặc checkIP thất bại" của FAQ. Tên phải có trong SAN, DNS cho `checkHost`, IP cho `checkIP`. Điểm đáng lưu ý là ca C: cùng một chứng chỉ chạy đúng khi gọi bằng tên (B) và lỗi khi gọi bằng IP.
Ca F là chứng chỉ hết hạn. Loại lỗi này không do cấu hình. Chỉ có gia hạn chứng chỉ mới sửa được, và không công cụ bọc nào đổi được điều đó.
Ca H và I là lệch giao thức. Ở H, client nói HTTP thường vào một cổng chỉ nhận TLS. Ở I, client nói TLS vào cổng chỉ nhận HTTP thường. FAQ của stunnel có mục "wrong version number hoặc unknown protocol" cho đúng tình huống: một bên mong TLS, bên kia gửi dữ liệu thường. Mục đó khuyên kiểm `client = yes` có ở đầu khởi tạo TLS chưa, `accept` và `connect` có trỏ đúng cổng thường và cổng TLS chưa.
Trong ca I, nhật ký của proxy giả ghi nhận byte ClientHello thô đến cổng thường, tức proxy nhận rác thay vì một yêu cầu HTTP. Nếu anh em thấy proxy phía sau báo yêu cầu có ký tự lạ, hãy nghĩ tới một client đang nói TLS vào cổng thường.
Ba ca K, L và ca Python: bài học về kẻ mạo danh
Đây là nhóm đáng nhớ nhất. Ca K bỏ kiểm tra và nhận chứng chỉ do "Impostor CA" cấp, kết quả thành công, có phản hồi, không lỗi. Nếu đó là proxy thật, người đứng giữa đã nhận được mọi thứ client gửi, gồm cả tài khoản proxy. Ca L bật kiểm tra với Lab CA và bị từ chối đúng. Ca Python làm điều tương tự với OpenSSL.
Với stunnel, hệ quả trực tiếp là thế này. `verifyChain` mặc định là `no`. Một stunnel client không khai `verifyChain`, `CAfile` và `checkHost` có kết nối được mã hóa tới bất kỳ ai trả lời ở đầu kia. Phía người dùng thấy mọi thứ chạy, nên không có dấu hiệu gì cảnh báo. Đây là lý do mình coi hai dòng `verifyChain = yes` và `checkHost` là điều kiện tối thiểu, không phải tùy chọn.
Bài tấn công MITM mô tả loại tấn công mà ca K minh họa ở quy mô nhỏ.
Nhật ký phía máy chủ
Lớp bọc Python ghi lại lý do bắt tay thất bại. Với client có xác minh trước chứng chỉ mạo danh, phía máy chủ thấy cảnh báo "unknown ca". Với một số ca khác, thấy "bad certificate". Điều này cho thấy lỗi chứng chỉ thường nằm ở phía client từ chối, và log của máy chủ có thể chỉ hiện một cảnh báo ngắn.
Với stunnel thật, anh em tăng `debug = info` để xem. Manual nói cấp độ `debug` đầy đủ chỉ để cho nhà phát triển.
Khi stunnel bảo vệ kết nối proxy không sửa được ERR_PROXY_CERTIFICATE_INVALID
Lỗi này xuất hiện khi trình duyệt khai báo proxy kiểu `https://` và không tin được chứng chỉ của proxy. Có người nghe nói "đặt stunnel ở máy mình là hết lỗi". Câu đó sai ở nhiều trường hợp.
Trường hợp stunnel client chỉ che lỗi
Nếu anh em để stunnel client không xác minh, trình duyệt kết nối tới `http://127.0.0.1` và lỗi biến mất. Nhưng chứng chỉ lỗi vẫn còn, anh em chỉ chuyển nó vào chỗ không ai nhìn thấy. Ca K là minh họa trực tiếp.
Cách làm đúng là để stunnel client xác minh bằng `verifyChain`, `CAfile` và `checkHost`. Khi đó chứng chỉ sai làm stunnel từ chối kết nối, và lỗi hiện ở nhật ký của stunnel thay cho trình duyệt.
Trường hợp proxy vốn không nói TLS
Ca I cho thấy nếu proxy chỉ nói HTTP thường mà anh em khai `https://`, lỗi là lệch giao thức. Đổi lược đồ thành `http://` là đủ. Thêm stunnel server vào máy chủ proxy cũng sửa được, nhưng đó là thêm một thành phần mà không cần, nếu chỉ vì khai nhầm. Bài ERR_PROXY_CERTIFICATE_INVALID có phần phân biệt nguyên nhân này.
Trường hợp chứng chỉ hết hạn hoặc sai tên
Ca E và F: chứng chỉ sai tên hoặc hết hạn. stunnel client từ chối giống như trình duyệt. stunnel không thay được việc gia hạn chứng chỉ hay cấp lại với SAN đúng. Nếu máy chủ proxy của người khác dùng chứng chỉ hết hạn, anh em không sửa được từ phía mình, trừ khi tắt xác minh, và tắt xác minh là điều không nên.
Trường hợp thiết bị ở giữa chèn chứng chỉ
Một số mạng công ty hoặc phần mềm bảo mật chèn chứng chỉ của riêng mình để kiểm tra lưu lượng. Khi đó trình duyệt báo lỗi, vì chuỗi dẫn tới CA lạ. Với stunnel client có `CAfile` chỉ chứa CA của anh em, nó cũng từ chối, và đó là hành vi đúng. Nếu anh em thật sự chấp nhận CA của mạng công ty, hãy thêm CA đó vào `CAfile` có chủ đích, không tắt xác minh. Bài lỗi NET::ERR_CERT_AUTHORITY_INVALID nói về lỗi cùng họ ở website.
Hai kho tin cậy khác nhau
Trình duyệt tin theo kho của hệ điều hành hoặc của chính nó. stunnel tin theo `CAfile`, `CApath` hoặc `CAstore` anh em khai. Một chứng chỉ được hệ điều hành tin chưa chắc được stunnel tin, và ngược lại. FAQ nhắc đường dẫn bộ CA thay đổi theo hệ điều hành. Nếu thấy lỗi "unable to get local issuer certificate", FAQ nói thường là do máy chủ không gửi chứng chỉ trung gian, hoặc kho tin cậy cục bộ thiếu CA phát hành. FAQ dặn rõ không xử lý lỗi này bằng cách tắt xác minh.
Khi chỉ cần đổi cách khai báo
Nhiều trình duyệt hỗ trợ proxy HTTP hoặc SOCKS5 mà không cần TLS tới proxy. Nếu dịch vụ proxy anh em dùng chỉ cung cấp HTTP hoặc SOCKS5 thường, stunnel không giúp trừ khi nhà cung cấp mở cổng TLS. Bài HTTPS proxy là gì và proxy HTTPS phân biệt HTTPS proxy với việc truy cập website HTTPS qua proxy thường.
Đưa stunnel bảo vệ kết nối proxy vào hệ thống thật: hoàn nguyên, giới hạn, bảo mật
Checklist trước khi dùng stunnel cho proxy
Lab chạy được chưa đủ để đưa lên sản xuất.
Hoàn nguyên
Trên Unix, tín hiệu SIGHUP nạp lại cấu hình, SIGUSR1 đóng và mở lại tệp log, SIGUSR2 ghi các kết nối đang hoạt động. Các tùy chọn toàn cục `chroot`, `foreground`, `pid`, `setgid`, `setuid` không đổi khi nạp lại, theo FAQ. Trên dịch vụ Windows, dùng `stunnel -reload`, `stunnel -reopen` và `stunnel -stop`.
Trước khi đổi cấu hình, chép tệp cũ. Khi gia hạn chứng chỉ, FAQ có mục hướng dẫn nạp lại chứng chỉ mới. Nếu bản mới lỗi, quay lại tệp cũ và nạp lại.
Giới hạn tài nguyên
FAQ có mục "too many open files". Mỗi kết nối qua stunnel dùng ít nhất hai socket, nên giới hạn file descriptor của hệ điều hành có thể thấp hơn số kết nối anh em cần. Tùy chọn `sessionCacheSize` giới hạn số phiên trong bộ nhớ đệm của TLS, và giá trị 0 là không giới hạn, một giá trị manual không khuyên dùng cho sản xuất vì nguy cơ cạn bộ nhớ.
Mình không đo hiệu năng hay mức dùng CPU, nên không đưa con số. Hãy đo bằng tải thật. Phần mở đầu kết nối TLS tốn thêm thời gian, và session resumption có mục riêng trong FAQ.
Bảo mật
Khóa riêng chỉ cho tài khoản chạy stunnel đọc. Đặt `accept` ở loopback cho dịch vụ client, và chỉ mở cổng TLS của máy chủ tới địa chỉ cần thiết. Không để proxy HTTP phía sau nghe ngoài loopback, vì khi đó kẻ tấn công đi vòng qua lớp TLS.
Nếu backend cần biết địa chỉ client gốc, FAQ nêu `protocol = proxy` cho backend hiểu PROXY protocol phiên bản 1, và cảnh báo backend không được nhận tiêu đề PROXY giả mạo từ nguồn không tin cậy. Bài Proxy Protocol giải thích khái niệm này.
Cuối cùng là tài khoản proxy. Nếu anh em dùng `protocolUsername` và `protocolPassword`, tệp cấu hình chứa mật khẩu và phải được bảo vệ, như FAQ dặn.
Khi nào nên chọn công cụ khác
Nếu anh em tự dựng proxy trên VPS, nhiều phần mềm proxy có sẵn cổng TLS riêng, ví dụ Squid với `https_port` như bài lỗi chứng chỉ đã nhắc. Khi đó stunnel chỉ cần nếu phần mềm proxy không có TLS. Nếu hạ tầng đã có SSH, tunnel SSH có thể đơn giản hơn. Bài dùng proxy trên VPS nói về bức tranh rộng hơn.
Câu hỏi thường gặp về stunnel bảo vệ kết nối proxy
stunnel có thay được proxy IP thuê không. Không. stunnel chỉ bọc kết nối TCP bằng TLS, không cấp hay đổi IP.
stunnel có chạy trên Windows không. Có. Trang tải về của dự án có trình cài đặt cho Windows 64 bit, kèm tệp mã băm SHA256 và chữ ký. Tài liệu có các lệnh cho dịch vụ Windows. Mình không chạy bản này nên chưa kiểm.
Chỉ cần `verifyChain = yes` là đủ? Chưa. Ở chế độ client phải thêm `checkHost` hoặc `checkIP`. Manual ghi rõ việc kiểm tra chứng chỉ máy chủ cần cả hai.
Chứng chỉ tự ký có dùng được không. Dùng được cho môi trường thử nghiệm có kiểm soát, FAQ nói vậy. Mỗi client phải tin chứng chỉ đó một cách rõ ràng, và chứng chỉ vẫn cần SAN đúng. FAQ dặn không bao giờ tắt xác minh chỉ để chứng chỉ tự ký chạy được.
Gọi bằng IP thì dùng gì. Dùng `checkIP`, và chứng chỉ phải có IP trong SAN. Ca C và D trong lab cho thấy cùng một proxy chạy khi gọi bằng tên và lỗi khi gọi bằng IP nếu SAN thiếu IP.
stunnel có chuyển được UDP không. FAQ ghi các bản hiện nay hỗ trợ DTLS qua UDP với `transport = udp`. Nó không biến giao thức TCP thành UDP. Với proxy HTTP và SOCKS5 thông thường, chủ yếu là TCP, nên phần này ít liên quan.
Tại sao stunnel báo "wrong version number". Thường là một bên chờ TLS, bên kia gửi dữ liệu thường. Kiểm `client = yes`, kiểm `accept` và `connect`, và kiểm xem có phải cổng cần `protocol = connect` qua proxy HTTP. Lỗi tương tự ở trình duyệt xem ở bài SSL_ERROR_RX_RECORD_TOO_LONG.
Có dùng stunnel trong WSL được không. Được nếu có bản Linux trong WSL. Cấu hình proxy cho WSL có bài WSL proxy. Ở lab này mình không có WSL nên chưa thử.
Tắt xác minh cho nhanh được không. Không nên. Ca K cho thấy kẻ mạo danh được chấp nhận ngay khi tắt xác minh.
Cần thêm IP, anh em có thể mua proxy tại ProxyVN, có proxy dân cư tĩnh Viettel, VNPT, FPT, datacenter Việt Nam và proxy xoay, hỗ trợ HTTP và SOCKS5 với tài khoản user và mật khẩu.
stunnel bảo vệ kết nối proxy: những điều cần nhớ
stunnel bảo vệ kết nối proxy chỉ an toàn khi client đặt verifyChain, CAfile và checkHost, vì mặc định stunnel không xác minh gì. Nó không sửa chứng chỉ hết hạn, sai tên hay proxy khai nhầm giao thức. Cần proxy IP ổn định, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam cho stunnel bảo vệ kết nối proxy.
