Bạn có thể đang ở đây vì một proxy thông thường trông có vẻ ổn trên giấy, nhưng thực tế thì không như vậy.
Bạn đã thiết lập một proxy trong trình duyệt hoặc kịch bản tự động của mình. Sau đó, một nền tảng xã hội vẫn đánh dấu phiên, một bài kiểm tra địa lý cho thấy phiên bản sai của trang, hoặc trình thu thập dữ liệu của bạn kết nối nhưng không thể hoạt động giống như một trình duyệt thực sự trên một trang web bảo mật. Điều đó thường xảy ra vì các trang web hiện đại không chỉ sử dụng HTTP. Họ sử dụng HTTPS với SSL/TLS, và điều đó thay đổi những gì mà một proxy có thể thấy và làm.
Một proxy thông thường có thể chuyển tiếp lưu lượng. Nó có thể thay đổi IP thoát của bạn. Điều mà nó thường không thể làm là tương tác một cách thông minh với lưu lượng được mã hóa trừ khi nó được xây dựng và cấu hình cho công việc đó. Đó là lý do tại sao ý tưởng về một máy chủ proxy với SSL lại quan trọng. Khi bạn hiểu sự khác biệt giữa việc tạo đường hầm lưu lượng được mã hóa và kết thúc hoặc kiểm tra nó, nhiều hành vi khó hiểu bắt đầu trở nên hợp lý.
Tại sao Proxy Chuẩn của Bạn Thất Bại trên Các Trang Web Hiện Đại
Một ví dụ phổ biến là công việc tài khoản.
Bạn đăng nhập vào một ứng dụng web bảo mật thông qua một proxy chuẩn, và trang đăng nhập tải lên. Cho đến nay thì tốt. Nhưng sau khi đăng nhập, trang bắt đầu phục vụ các thông báo bất thường, kiểm tra bảo mật, hoặc nội dung không nhất quán. Trong quá trình thử nghiệm, bạn có thể thấy địa phương sai, tài sản bị hỏng, hoặc một phiên hoạt động khác với một phiên người dùng thực sự. Proxy “đã hoạt động,” nhưng không theo cách bạn cần.
Lý do rất đơn giản. Các trang web hiện đại mong đợi các phiên được mã hóa từ đầu đến cuối, và họ đưa ra quyết định dựa trên các chi tiết bên trong trao đổi bảo mật đó. Một proxy chuyển tiếp cơ bản giống như một người chuyển phát mang theo một chiếc cặp khóa. Nó có thể di chuyển chiếc cặp từ nơi này sang nơi khác, nhưng nó không thể thấy bên trong, điều chỉnh bất cứ điều gì, hoặc xác thực nội dung.
Những gì bị hỏng trong thực tế
Khi mọi người nói rằng một proxy đã thất bại, họ thường có nghĩa là một trong những điều sau:
- Xử lý phiên bị hỏng: Trang web mong đợi một luồng HTTPS sạch, nhưng khách hàng, proxy và điểm đến không đồng ý về cách thiết lập nó.
- Thử nghiệm trở nên không chính xác: Bạn có thể thay đổi vị trí ở rìa mạng, nhưng vẫn bỏ lỡ cách mà một trang bảo mật phản ứng với hành vi của trình duyệt.
- Tự động hóa bị chặn: Các trang kiểm tra các mẫu kết nối, hành vi chứng chỉ, và các tín hiệu khác mà một thiết lập rẻ tiền hoặc cấu hình sai sẽ không khớp tốt.
- Gỡ lỗi trở nên mờ mịt: Bởi vì lưu lượng được mã hóa, bạn không thể dễ dàng kiểm tra các yêu cầu trừ khi proxy được thiết kế để kết thúc hoặc chặn TLS.
Một proxy chuẩn là đủ để thay đổi lộ trình. Nó thường không đủ để hiểu hoặc kiểm soát lưu lượng web được mã hóa.
Đó là lý do tại sao những người quản lý tài khoản, xác minh quảng cáo, hoặc thử nghiệm các luồng theo vùng cụ thể lại tìm kiếm một máy chủ proxy với hỗ trợ SSL thay vì một điểm cuối proxy chung.
Hiểu Về Các Proxy Bật SSL
Một máy chủ proxy với SSL ngồi giữa một khách hàng và một điểm đến sử dụng HTTPS. Câu hỏi quan trọng không chỉ là liệu lưu lượng có được mã hóa hay không. Câu hỏi quan trọng là proxy xử lý việc mã hóa đó như thế nào.
Tạo đường hầm so với chặn
Hãy nghĩ về lưu lượng HTTPS như một phong bì đã được niêm phong.
Với TLS tunneling, proxy hoạt động như một dịch vụ giao hàng. Nó thấy nơi phong bì nên đi, nhưng nó không mở nó ra. Đây là mô hình mà nhiều người sử dụng khi họ cấu hình một proxy HTTPS cho một trình duyệt hoặc kịch bản. Proxy chuyển tiếp phiên mã hóa, nhưng nội dung vẫn riêng tư giữa khách hàng và trang web.
Với TLS interception hoặc termination, proxy giống như một phòng thư đáng tin cậy mở phong bì, kiểm tra nội dung, và niêm phong lại trước khi gửi đi. Điều đó chỉ hoạt động khi khách hàng đã đồng ý rõ ràng để tin tưởng proxy cho vai trò đó.
Sự phân biệt này quan trọng vì một proxy SSL/TLS khác biệt rõ rệt với một proxy chuyển tiếp đơn giản. Vì dữ liệu được mã hóa, proxy thường chỉ có thể chuyển tiếp nó trừ khi nó thực hiện một kiểu chặn man-in-the-middle. Trong một phân tích năm 2014, tác giả ước tính rằng nếu mẫu đại diện, khoảng 0.5% người dùng internet đang ở sau một proxy chặn lưu lượng được mã hóa, cho thấy điều này không chỉ là một trường hợp lý thuyết ngay cả khi đó, như được mô tả trong phân tích này về các proxy phá vỡ kết nối SSL.
Tại sao mọi người nhầm lẫn về proxy HTTPS
Nhiều sự nhầm lẫn đến từ cụm từ “proxy SSL” tự nó. Mọi người sử dụng nó để có nghĩa là hai điều khác nhau:
- Một proxy có thể mang lưu lượng HTTPS
- Một proxy có thể giải mã và kiểm tra lưu lượng HTTPS
Đó không phải là cùng một thứ.
Nếu bạn đang duyệt an toàn qua một proxy, proxy có thể đang vận chuyển dữ liệu được mã hóa. Nếu bạn đang ở trong một mạng doanh nghiệp, phòng QA, hoặc môi trường bảo mật, proxy có thể kết thúc và mã hóa lại lưu lượng để nó có thể kiểm tra các yêu cầu và phản hồi.
Nơi các proxy bật SSL giúp đỡ
Đối với người dùng kỹ thuật, giá trị thực tế thường rơi vào một vài nhóm:
- Vận chuyển an toàn: Proxy có thể mang lưu lượng HTTPS hiện đại một cách chính xác.
- Kiểm tra và gỡ lỗi: Trong các thiết lập kiểm soát, nó có thể phơi bày các yêu cầu được mã hóa để thử nghiệm.
- Thực thi chính sách: Các nhóm có thể lọc hoặc giám sát lưu lượng nơi mà sự tin tưởng được cấu hình rõ ràng.
- Thực tế phiên: Một chuỗi được cấu hình tốt hơn tạo ra hành vi gần hơn với những gì các trang bảo mật mong đợi.
Quy tắc thực tiễn: Nếu khách hàng chưa được thông báo để tin tưởng proxy, hãy giả định rằng proxy chỉ đang tạo đường hầm lưu lượng được mã hóa, không đọc nó.
Quy tắc đó làm rõ hầu hết các sự hiểu lầm.
Các Loại Proxy Chính và Cách Chúng Xử Lý SSL
Không phải mọi proxy đều đóng vai trò giống nhau. Cách dễ nhất để chọn đúng là ngừng hỏi “Proxy nào tốt hơn?” và bắt đầu hỏi “Proxy này ngồi ở đâu, và nó làm gì với TLS?”
Proxy chuyển tiếp và proxy đảo ngược
Một proxy chuyển tiếp ngồi trước khách hàng. Trình duyệt, bot, trình chạy thử, hoặc thiết bị di động của bạn gửi lưu lượng đến nó trước tiên. Đây là mô hình mà mọi người sử dụng cho tính ẩn danh, cách ly tài khoản, kiểm tra địa lý, và kiểm soát lưu lượng ra.
Một proxy đảo ngược ngồi trước máy chủ. Người truy cập nghĩ rằng họ đang nói chuyện trực tiếp với trang web, nhưng proxy đảo ngược chấp nhận kết nối, thường xử lý TLS, và sau đó chuyển tiếp các yêu cầu đến ứng dụng backend.
Trong các môi trường doanh nghiệp, proxy SSL là một tính năng bảo mật bình thường thay vì một thủ thuật ngách. Tài liệu cho thấy các cấu hình khác biệt cho proxy chuyển tiếp và proxy đảo ngược, và nó cũng phản ánh một xu hướng hướng tới việc chặn HTTPS được quản lý với các chứng chỉ chuyên dụng và thậm chí các cổng cụ thể như 33335, như được nêu trong tổng quan này về hoạt động của proxy SSL chuyển tiếp và đảo ngược.
Proxy rõ ràng và proxy trong suốt
Một sự phân biệt thứ hai là cách lưu lượng đến proxy.
- Proxy rõ ràng: Khách hàng được cấu hình để sử dụng nó. Trình duyệt, ứng dụng, hoặc kịch bản biết rằng proxy tồn tại.
- Proxy trong suốt: Mạng chuyển hướng lưu lượng qua nó mà không cần khách hàng thiết lập chi tiết proxy thủ công.
Các thiết lập rõ ràng thường dễ lý luận hơn vì khách hàng và proxy có một mối quan hệ rõ ràng. Các thiết lập trong suốt có thể mạnh mẽ, nhưng chúng cũng tạo ra nhiều trường hợp biên hơn khi các chứng chỉ, cổng, hoặc xác thực TLS hiện đại được liên quan.
Proxy HTTPS và SOCKS5 không thể thay thế cho nhau
Mọi người thường gộp chúng lại với nhau, nhưng chúng hoạt động khác nhau.
Một proxy HTTPS hiểu rõ lưu lượng web đủ để tạo ra các đường hầm an toàn cho các ứng dụng dựa trên HTTP. Một proxy SOCKS5 hoạt động ở cấp độ thấp hơn và chuyển tiếp các loại lưu lượng khác nhau một cách tổng quát hơn. Điều đó có thể hữu ích, nhưng cũng có nghĩa là ứng dụng thường phải chịu trách nhiệm nhiều hơn về hành vi giao thức. Nếu bạn muốn sự khác biệt khái niệm được trình bày rõ ràng, hướng dẫn ngắn này về các nguyên tắc cơ bản của proxy SOCKS5 là một tài liệu tham khảo hữu ích.
So sánh loại proxy cho lưu lượng SSL
| Loại Proxy | Trường hợp sử dụng chính | Phương pháp xử lý SSL/TLS |
|---|---|---|
| Proxy chuyển tiếp | Duyệt web ra ngoài, tự động hóa, kiểm tra địa lý | Thường tạo đường hầm TLS, có thể chặn nếu được cấu hình tin cậy |
| Proxy đảo ngược | Bảo vệ và đại diện cho các ứng dụng web | Thường kết thúc TLS trước khi chuyển tiếp lưu lượng lên trên |
| Proxy rõ ràng | Cài đặt khách hàng do người dùng kiểm soát | Khách hàng cố ý gửi lưu lượng an toàn qua proxy |
| Proxy trong suốt | Chặn hoặc định tuyến do mạng thực thi | Có thể chuyển tiếp hoặc chặn, nhưng cần xử lý chứng chỉ cẩn thận |
| Proxy HTTPS | Proxy an toàn tập trung vào web | Thường sử dụng đường hầm CONNECT cho HTTPS |
| Proxy SOCKS5 | Vận chuyển đa mục đích cho nhiều giao thức | Chuyển tiếp lưu lượng một cách tổng quát hơn, ứng dụng xử lý nhiều chi tiết giao thức hơn |
Nếu bạn đang chọn cho tự động hóa trình duyệt hoặc QA, hãy bắt đầu bằng cách quyết định xem bạn cần vận chuyển an toàn đơn giản hay kiểm tra SSL thực sự. Quyết định đó quan trọng hơn nhãn sản phẩm.
Ma thuật kỹ thuật đằng sau proxy SSL
Khi bạn loại bỏ thuật ngữ, proxy SSL giảm xuống hai quy trình làm việc rất khác nhau.
Đường hầm CONNECT
Đối với việc duyệt web an toàn thông thường qua một proxy, khách hàng thường bắt đầu với một yêu cầu HTTP CONNECT. Đó là khách hàng yêu cầu proxy mở một đường dẫn đến máy chủ đích qua một cổng an toàn cụ thể.
Một phép ẩn dụ đơn giản là một lễ tân kết nối một cuộc gọi điện thoại. Lễ tân không cần phải hiểu cuộc trò chuyện riêng tư. Họ chỉ cần thiết lập đường dây giữa người gọi và bên kia.
Sau khi đường hầm đó tồn tại, khách hàng và trang web đích thực hiện bắt tay TLS của họ qua proxy. Proxy chuyển tiếp các gói, nhưng không nhìn vào cuộc trò chuyện được mã hóa.
Chặn có nghĩa là hai phiên TLS
Kiểm tra phức tạp hơn.
Để giải mã lưu lượng, proxy tạo ra hai phiên SSL/TLS riêng biệt. Một phiên là giữa khách hàng và proxy. Phiên còn lại là giữa proxy và máy chủ đích. Để điều đó hoạt động, proxy sử dụng một hồ sơ CA để ký chứng chỉ mà nó hiển thị cho khách hàng, và khách hàng phải tin tưởng CA của proxy đó. Nếu không có sự tin tưởng đó, kết nối sẽ thất bại và việc kiểm tra không thể xảy ra. Mối quan hệ tin tưởng đó là yêu cầu trung tâm đằng sau proxy chuyển tiếp SSL.
Dưới đây là trình tự thực tế:
- Khách hàng bắt đầu một kết nối an toàn đến một trang web.
- Proxy chặn bắt tay thay vì chuyển tiếp nó mà không bị chạm vào.
- Proxy trình bày một chứng chỉ thay thế cho trang đích.
- Khách hàng kiểm tra sự tin tưởng. Nếu CA của proxy không được tin tưởng, bạn sẽ nhận được một cảnh báo chứng chỉ hoặc một lỗi nghiêm trọng.
- Proxy mở kết nối an toàn riêng của nó đến đích ban đầu.
- Lưu lượng chảy qua cả hai phiên, cho phép proxy kiểm tra và sau đó mã hóa lại dữ liệu.
Tại sao cảnh báo chứng chỉ xuất hiện
Khi mọi người thấy một cảnh báo trình duyệt trong một thiết lập proxy SSL, họ thường giả định rằng có điều gì đó “bị hỏng” một cách ngẫu nhiên. Thông thường, điều đó không phải là ngẫu nhiên.
Khách hàng đang làm chính xác những gì nó nên làm. Nó nhận được một chuỗi chứng chỉ được ký bởi một CA mà nó không tin tưởng. Từ quan điểm của trình duyệt, đó là một sự kiện bảo mật nghiêm trọng.
Proxy chỉ có thể kiểm tra lưu lượng được mã hóa sau khi khách hàng rõ ràng tin tưởng chứng chỉ gốc của proxy.
Đó cũng là lý do tại sao việc kiểm tra proxy SSL trong các phòng thí nghiệm và môi trường QA thường bắt đầu với việc cài đặt chứng chỉ, không phải với máy chủ và cổng proxy.
Ví dụ cấu hình thực tế
Thuyết lý giúp ích, nhưng nhiều người dùng cần lưu lượng chảy trước.
Cài đặt trình duyệt
Hầu hết các trình duyệt đều sử dụng cài đặt proxy hệ thống hoặc cho phép cấu hình proxy thủ công thông qua tùy chọn mạng. Trong thực tế, bạn thường nhận được bốn giá trị từ nhà cung cấp của mình:
- Máy chủ
- Cổng
- Tên người dùng
- Mật khẩu
Nhập máy chủ proxy và cổng vào cài đặt proxy của trình duyệt hoặc hệ điều hành. Nếu dịch vụ yêu cầu xác thực, trình duyệt thường sẽ yêu cầu tên người dùng và mật khẩu khi bạn thực hiện yêu cầu đầu tiên.
Nếu thiết lập là cho đường hầm lưu lượng HTTPS, điều đó có thể đủ.
Nếu thiết lập là cho chặn SSL, bạn cũng cần cài đặt chứng chỉ CA đáng tin cậy của proxy trên thiết bị thử nghiệm hoặc hồ sơ trình duyệt. Nếu không có điều đó, các trang an toàn có thể thất bại với lỗi chứng chỉ mặc dù điểm cuối proxy có thể truy cập được.
Dòng lệnh với curl
Để thử nghiệm nhanh, curl vẫn là một trong những công cụ sạch nhất:
curl -x https://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT https://example.com
Nếu proxy của bạn sử dụng proxy HTTP cơ bản cho các đích HTTPS, bạn cũng có thể thấy cú pháp như:
curl --proxy http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT https://example.com
Điều quan trọng là đích có thể là HTTPS ngay cả khi chi tiết kết nối proxy sử dụng một sơ đồ khác. Điều quan trọng là cách mà proxy hỗ trợ đường hầm an toàn hoặc kết thúc.
Một cách sạch để xác thực thiết lập
Đừng bắt đầu với toàn bộ ngăn xếp tự động hóa của bạn. Bắt đầu nhỏ.
- Kiểm tra kết nối trước: Xác nhận rằng proxy chấp nhận một yêu cầu.
- Kiểm tra một đích HTTPS tiếp theo: Đảm bảo rằng các trang an toàn tải mà không có lỗi bắt tay.
- Thêm xác thực sau đó: Thông tin xác thực sai có thể trông giống như sự cố mạng.
- Chỉ sau đó chuyển sang các kịch bản: Nếu trình duyệt hoặc curl thất bại, bot sẽ không tự động sửa chữa nó.
Đối với các nhóm cần thông tin xác thực proxy di động sẵn sàng cho công việc tài khoản hoặc kiểm tra địa lý, một lựa chọn là Evoproxy, cung cấp thông tin truy cập proxy phù hợp với quy trình tiêu chuẩn về máy chủ, cổng, tên người dùng và mật khẩu được mô tả ở trên.
Các trường hợp sử dụng chiến lược cho proxy SSL di động
Một proxy di động trở nên có giá trị hơn khi trang web mục tiêu vừa nhạy cảm về bảo mật vừa nhạy cảm về hành vi. Điều đó mô tả nhiều nền tảng hiện đại.
Hoạt động mạng xã hội
Nếu bạn quản lý tài khoản, sự tin tưởng trong phiên làm việc quan trọng gần như bằng việc xoay vòng IP thô.
Các nền tảng mong đợi đăng nhập an toàn, hành vi trình duyệt nhất quán và danh tính mạng hợp lý. Một proxy di động với hỗ trợ SSL giúp ích vì nó có thể mang lưu lượng được mã hóa mà các nền tảng đó yêu cầu trong khi cung cấp cho bạn một điểm thoát mạng di động thường phù hợp hơn với hành vi của người dùng so với một mẫu trung tâm dữ liệu tổng quát.
Điều đó không làm cho công việc tài khoản trở nên không có rủi ro. Nó chỉ làm cho lớp kết nối của bạn gần gũi hơn với môi trường mà các trang web đó được xây dựng để phục vụ.
QA và kiểm tra cụ thể theo địa lý
Các nhóm QA gặp phải một phiên bản khác của cùng một vấn đề.
Một trang đích, biểu mẫu đăng ký hoặc quy trình thanh toán có thể hoạt động theo một cách trong văn phòng của bạn và theo cách khác cho một người dùng ở Pháp trên một mạng di động. Nếu trang web an toàn, và hầu hết đều như vậy, đường thử nghiệm của bạn cũng phải xử lý HTTPS một cách sạch sẽ. Nếu không, bạn sẽ phải gỡ lỗi thiết lập proxy thay vì ứng dụng.
Một điểm cuối di động đặc biệt hữu ích khi bạn cần tái tạo:
- Luồng nhạy cảm với vị trí
- Hành vi cụ thể của nhà mạng
- Thay đổi nội dung chỉ dành cho di động
- Các thông báo hoặc chuyển hướng tuân thủ khu vực
Đối với các nhóm tập trung vào loại quy trình làm việc đó, cái nhìn tổng quan về một nhà cung cấp proxy di động cung cấp một khung tốt cho những gì cơ sở hạ tầng proxy di động được thiết kế để giải quyết.
Nghiên cứu, xác minh và thu thập dữ liệu an toàn
Các nhà nghiên cứu thị trường, các nhóm liên kết và các chuyên gia xác minh quảng cáo gặp phải các trang web mã hóa suốt cả ngày. Các trang sản phẩm, trang đích chiến dịch, bảng điều khiển tài khoản và cửa hàng đối thủ chủ yếu là HTTPS. Nếu lớp kết nối yếu, kết quả sẽ bị nhiễu.
Một máy chủ proxy hỗ trợ SSL quan trọng ở đây vì lý do thực tiễn. Nó cho phép các công cụ của bạn tiếp cận và duy trì các phiên an toàn theo cách mà các trang web hiện đại mong đợi. Điều đó cải thiện khả năng rằng những gì bạn thấy là những gì một người dùng thực sự trong môi trường đó sẽ thấy.
Đối với việc kiểm tra và xác minh, sai lầm đắt giá nhất là sự tự tin sai lầm. Một con đường proxy bị lỗi có thể làm cho hành trình của người dùng bị hỏng trông có vẻ khỏe mạnh.
Bảo mật hiệu suất và Khắc phục sự cố
Proxy SSL thêm khả năng, nhưng nó cũng tăng chi phí.
Thỏa thuận hiệu suất
Giải mã và mã hóa lại lưu lượng truy cập cần CPU và bộ nhớ. Proxy phải hoàn thành một cuộc bắt tay với khách hàng và một cuộc với máy chủ, điều này có thể làm tăng độ trễ bắt tay so với lưu lượng không qua proxy. Trên các liên kết có lưu lượng cao, việc kích hoạt kiểm tra SSL có thể giảm băng thông hiệu quả từ 15% đến 25% nếu phần cứng không được tối ưu hóa cho tăng tốc mã hóa, theo tài liệu của Palo Alto Networks về Proxy SSL Chuyển tiếp.
Điều đó quan trọng nhất khi mọi người mong đợi một proxy hoạt động như một ống dẫn đơn giản. Nó không chỉ chuyển tiếp gói tin nữa. Nó đang thực hiện công việc mã hóa trên mỗi phiên an toàn.
Bảo mật và quyền riêng tư gắn liền với nhau
Một proxy chặn có thể đọc lưu lượng mã hóa. Đó là toàn bộ điểm. Nó cũng là rủi ro chính.
Nếu bạn kiểm soát môi trường, chẳng hạn như phòng thí nghiệm thử nghiệm hoặc ranh giới chính sách doanh nghiệp, điều đó có thể chấp nhận được và có chủ ý. Nếu bạn không hoàn toàn tin tưởng dịch vụ xử lý việc chặn, bạn không nên nhẹ dạ giao cho nó các phiên nhạy cảm.
Một proxy hầm mang lại ít rủi ro về khả năng nhìn thấy hơn vì nó thường không giải mã tải trọng. Nhưng một khi kiểm tra được đưa vào bức tranh, sự tin tưởng của nhà cung cấp và các kiểm soát hoạt động trở nên quan trọng hơn nhiều.
Những gì cần kiểm tra khi mọi thứ sai
Hầu hết các lỗi rơi vào một danh sách ngắn.
- Cảnh báo chứng chỉ: Khách hàng không tin tưởng CA của proxy, hoặc proxy đang trình bày chuỗi chứng chỉ sai.
- Lưu lượng bị bỏ lỡ: Quy tắc chặn của bạn chỉ khớp với các cổng HTTPS tiêu chuẩn, trong khi ứng dụng sử dụng một cổng khác.
- Lỗi xác thực: Các kiểm tra OCSP hoặc các bước xác thực chứng chỉ liên quan có thể thất bại nếu môi trường không thể tiếp cận các dịch vụ cần thiết.
- Không tương thích: Khách hàng, proxy và máy chủ có thể không đồng ý về các phiên bản TLS hoặc hỗ trợ mã hóa.
- Vấn đề phát hiện: Chính proxy có thể có thể truy cập, nhưng trang web mục tiêu vẫn phân loại phiên là đáng ngờ. Trong trường hợp đó, hãy kiểm tra dấu vân tay và hành vi của tuyến đường với một bài kiểm tra phát hiện proxy.
Một thứ tự khắc phục sự cố thực tiễn
Sử dụng một thứ tự cố định thay vì thay đổi năm điều cùng một lúc.
- Xác minh khả năng tiếp cận cơ bản. Khách hàng có thể kết nối với proxy không?
- Kiểm tra một trang HTTPS thủ công. Đừng bắt đầu với tự động hóa.
- Kiểm tra độ tin cậy của chứng chỉ. Cảnh báo của trình duyệt thường nói lên sự thật.
- Xác nhận cổng dự kiến được bao phủ. Lưu lượng an toàn ngoài cổng thông thường thường bị bỏ qua.
- Xem xét xem bạn có cần hầm hay chặn không. Nhiều thiết lập thất bại vì mục tiêu thiết kế không rõ ràng.
“Nếu lưu lượng an toàn thất bại, hãy kiểm tra độ tin cậy trước, chính sách thứ hai và hiệu suất thứ ba.”
Thứ tự đó tiết kiệm thời gian vì hầu hết các vấn đề proxy SSL là vấn đề cấu hình và độ tin cậy trước khi chúng là vấn đề tốc độ.
Chìa khóa của bạn cho Web An toàn Hiện đại
Một lần đăng nhập mạng xã hội thất bại mặc dù proxy đang trực tuyến. Một kịch bản thử nghiệm truy cập trang web mục tiêu, nhưng trình duyệt hiển thị cảnh báo chứng chỉ. Cả hai vấn đề thường quay trở lại cùng một khoảng trống. Kết nối được mã hóa, và chiến lược proxy không khớp với cách mà lưu lượng HTTPS hiện đại hoạt động.
Đó là lý do tại sao một máy chủ proxy với SSL quan trọng. Nó cung cấp cho bạn một cách để truyền tải lưu lượng mã hóa một cách chính xác, bằng cách truyền qua phiên TLS với hầm CONNECT hoặc bằng cách kết thúc TLS tại proxy để lưu lượng có thể được kiểm tra, lọc hoặc ghi lại. Sự khác biệt nghe có vẻ học thuật lúc đầu. Trong thực tế, nó quyết định xem trình duyệt của bạn có tin tưởng phiên hay không, liệu môi trường QA của bạn có ghi lại các yêu cầu đúng hay không, và liệu các quy trình dựa trên tài khoản có hoạt động giống như lưu lượng của người dùng thực hay không.
Đối với một người kiểm tra QA, điều đó có nghĩa là gỡ lỗi chính xác hơn. Bạn có thể thấy liệu vấn đề là độ tin cậy của chứng chỉ, khả năng tương thích bắt tay, hay một ứng dụng sử dụng cổng HTTPS không chuẩn. Đối với một người tự động hóa mạng xã hội, điều đó có nghĩa là chọn một tuyến đường phù hợp với mong đợi của nền tảng thay vì ép lưu lượng an toàn qua một thiết lập được xây dựng cho web cũ hơn.
Mô hình tư duy hữu ích rất đơn giản. TLS là phong bì đã khóa. Một proxy tiêu chuẩn chỉ chuyển tiếp phong bì. Một proxy hỗ trợ SSL có thể hoặc là truyền phong bì đó mà không bị chạm vào hoặc mở nó một cách hợp pháp, kiểm tra nó và niêm phong lại bằng một chứng chỉ mà khách hàng đã tin tưởng. Khi bạn hiểu công việc mà proxy của bạn đang thực hiện, các lựa chọn cấu hình không còn cảm thấy ngẫu nhiên nữa.
Nếu bạn cần truy cập proxy di động Pháp cho công việc tài khoản an toàn, QA hoặc thử nghiệm nhắm mục tiêu địa lý, Evoproxy là một lựa chọn để xem xét. Nó cung cấp các cổng proxy di động được thiết kế cho các quy trình làm việc dựa trên HTTPS, điều này có thể hữu ích khi bạn cần một đường dẫn mạng di động sạch hơn thay vì một tuyến đường proxy chung chung.
