Thiết lập proxy SSL minh bạch

Tôi đã có một hộp linux được thiết lập với 2 card mạng để kiểm tra lưu lượng truy cập qua cổng 80. Một thẻ được sử dụng để truy cập internet, một thẻ còn lại được nối với một công tắc mạng. Vấn đề là có thể kiểm tra tất cả lưu lượng HTTP và HTTPS trên các thiết bị được nối với công tắc đó cho mục đích gỡ lỗi.

Tôi đã viết các quy tắc sau cho iptables:

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Vào ngày 192.168.2.1:1337, tôi đã có một proxy http trong suốt bằng cách sử dụng Charles ( http://www.charlesproxy.com/ ) để ghi.

Mọi thứ đều ổn đối với cổng 80, nhưng khi tôi thêm các quy tắc tương tự cho cổng 443 (SSL) trỏ đến cổng 1337, tôi gặp lỗi về thông báo không hợp lệ thông qua Charles.

Trước đây, tôi đã sử dụng proxy SSL trên cùng một máy tính với Charles ( http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ), nhưng đã không thành công khi thực hiện nó một cách minh bạch vì một số lý do. Một số tài nguyên mà tôi đã nói rằng không thể thực hiện được - Tôi sẵn sàng chấp nhận đó là câu trả lời nếu ai đó có thể giải thích lý do.

Lưu ý, tôi có quyền truy cập đầy đủ vào thiết lập được mô tả bao gồm tất cả các máy khách được nối với mạng con - vì vậy tôi có thể chấp nhận các certs tự ký của Charles. Giải pháp không nhất thiết phải là Charles vì ​​về lý thuyết, mọi proxy minh bạch sẽ làm.

Cảm ơn!

Chỉnh sửa: Sau khi chơi với nó một chút, tôi đã có thể làm cho nó hoạt động cho một máy chủ cụ thể. Khi tôi sửa đổi iptables của mình thành như sau (và mở 1338 trong charles cho proxy ngược):

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Tôi có thể nhận được phản hồi, nhưng không có máy chủ đích. Trong proxy ngược, nếu tôi chỉ định rằng mọi thứ từ 1338 sẽ đến một máy chủ cụ thể mà tôi muốn nhấn, nó sẽ thực hiện thao tác lắc tay đúng cách và tôi có thể bật proxy SSL để kiểm tra giao tiếp.

Thiết lập ít hơn lý tưởng vì tôi không muốn giả sử mọi thứ từ 1338 đến máy chủ đó - có ý tưởng nào khiến máy chủ đích bị tước không?

Cảm ơn một lần nữa

Các vấn đề bạn đang gặp phải giống nhau khiến việc sử dụng nhiều chứng chỉ trên một địa chỉ / cổng IP duy nhất (không sử dụng Chỉ định tên máy chủ) .

Trong HTTP đơn giản, proxy trong suốt của bạn có thể cho biết máy khách nào muốn kết nối với máy chủ nào bằng cách nhìn vào Hosttiêu đề.

Khi proxy minh bạch HTTPS MITM nhận được yêu cầu, nó không thể biết tên máy chủ nào được yêu cầu ở vị trí đầu tiên. .

• Để có được tên máy chủ dự kiến, proxy MITM sẽ phải đọc Hosttiêu đề trong thông điệp HTTP, điều này chỉ có thể xảy ra sau khi bắt tay thành công.
• Để bắt tay thành công, proxy MITM cần tạo chứng chỉ giả mạo phù hợp với tên máy chủ dự kiến.

Do đó, proxy MITM không thể biết chứng chỉ nào sẽ được tạo trước khi bắt tay.

Điều này có thể hoạt động với proxy MITM không minh bạch, vì ít nhất bạn sẽ có được tên máy chủ dự định thông qua CONNECTphương thức HTTP .

Chỉ cần một số thông tin cơ bản về chủ đề này.

Chỉ có một vài thiết bị mà tôi biết có thể thành công trong hành động này. Tuy nhiên chúng không thực sự có sẵn cho công chúng. Bản thân tôi đang sử dụng Fortinet Fortigate với SSL Offloading.

Những gì nó về cơ bản là; nó chặn Kết nối SSL được thực hiện với máy chủ và giải mã kết nối trong phần cứng, sau đó kiểm tra nơi bạn muốn đến và đưa ra quyết định tường lửa dựa trên thông tin đó.

Sau đó, nó sẽ thiết lập kết nối của chính nó đến máy chủ đó để lấy dữ liệu và ký lại yêu cầu ban đầu cho khách hàng bằng cách sử dụng CA do người dùng cung cấp. Để làm cho công việc này diễn ra suôn sẻ, cần phải có CA trong CA gốc đáng tin cậy trên máy khách.

Những loại thiết lập này được sử dụng trong các tổ chức để thực thi các chính sách của công ty về việc sử dụng internet. Vì sử dụng Active Directory, thật dễ dàng để cài đặt CA công ty của bạn trong các máy khách, hình thức này không có vấn đề gì đối với các tổ chức lớn.

Đây là cách DUY NHẤT bạn có thể làm mà không cần tạo proxy thủ công, vì lưu lượng SSL được mã hóa. Về cơ bản nó là một MITM, vì vậy điều quan trọng là có bất kỳ vấn đề pháp lý nào được đề cập.

Có một vài gợi ý về câu hỏi khác mà bạn có thể đã thấy: những huyền thoại và sự thật về proxy SSL minh bạch . Và có liên kết này giải thích chính xác cách cấu hình Squid để trở thành proxy SSL minh bạch. Nó không phải là những gì bạn đang tìm kiếm, nhưng ít nhất nó có thể cung cấp cho bạn cái nhìn sâu sắc về những gì có thể đi sai.

Các quy tắc iptables có vẻ ổn, nhưng tôi không biết phần mềm proxy bạn đang sử dụng có thể làm những gì bạn đang cố gắng làm hay không. Các tài liệu chắc chắn tuyên bố đây là trường hợp.

Để thêm vào giải pháp của Bruno, tôi đã điều tra một chút và muốn chia sẻ làm thế nào tôi có một cách khắc phục nhanh ít lý tưởng hơn.

Sau khi đặt các iptables đó, tôi có thể đặt proxy ngược trên cổng 1338 và chuyển tiếp tới localhost trên cổng 1337. Vì cổng 1337 là proxy http trong suốt và dữ liệu đã được giải mã, nó sẽ lấy tiêu đề máy chủ và biến nó thành đích tổ chức.

Nhược điểm chính là về cơ bản tôi đã chuyển đổi kết nối https thành http - không phải lúc nào cũng hoạt động với mọi máy chủ (chưa kể đến lỗ hổng bảo mật mà tôi gặp phải từ đó).

Tôi đã làm việc từ trong giới hạn của phần mềm của tôi. Tôi tin rằng một giải pháp sạch hơn theo Bruno sẽ là giả sử tất cả lưu lượng truy cập từ năm 1338 sẽ được giải mã. Sau khi giải mã, kiểm tra máy chủ đích và sau đó ủy quyền yêu cầu bằng SSL.