Apache HTTPD/mod_proxy/Tomcat và SSL với auth ứng dụng khách

Question

Tôi chắc chắn đây là câu hỏi thường gặp nhưng tôi không thể tìm thấy bất kỳ điều gì tôi đã nhận ra là cùng một câu hỏi.

Tôi có một số ứng dụng web chạy trong Tomcat, với một số trang, ví dụ: trang đăng nhập được bảo vệ bởi SSL như được xác định bởi các yếu tố bảo mật trong tệp web.xml của chúng. Một trong các ứng dụng cũng chấp nhận xác thực ứng dụng khách qua chứng chỉ. Tôi cũng có một ủy quyền xác thực dựa trên JAAS dựa trên giao thức xác thực & và có tất cả các loại mã được chia sẻ và các cấu hình JAAS khác nhau, vv giữa các ứng dụng web khác nhau.

Tôi thực sự không muốn làm phiền bất kỳ điều gì trong khi hoàn thành bên dưới.

Tôi hiện đang trong quá trình chèn Apache HTTPD với mod-proxy và mod-proxy-balancer trước Tomcat làm bộ cân bằng tải, trước khi thêm nhiều phiên bản Tomcat. Những gì tôi muốn thực hiện cho các yêu cầu HTTPS là chúng được chuyển hướng 'mù' sang Tomcat mà không cần HTTPD là điểm cuối SSL, tức là HTTPD chỉ chuyển trực tiếp bản mã tới Tomcat để TC có thể tiếp tục làm những gì nó đã làm với thông tin đăng nhập , SSL, bảo mật bảo mật web.xml và quan trọng nhất là xác thực ứng dụng khách.

Điều này có thể thực hiện được với cấu hình mà tôi đã mô tả không?

Tôi rất quen thuộc với các ứng dụng web và SSL và HTTPS và Tomcat, nhưng kiến ​​thức về các kết nối bên ngoài của Apache HTTPD bị giới hạn.

hạnh phúc để có điều này di chuyển nếu cần thiết nhưng nó là loại chương trình với các tập tin cấu hình;)

Answer 1

này nghe có vẻ giống với this question, nơi tôi đã trả lời rằng đó là không thể:

Bạn có thể không chỉ chuyển tiếp lưu lượng SSL/TLS tới Tomcat từ Apache. Hoặc là kết nối SSL của bạn kết thúc tại Apache và sau đó bạn nên đảo ngược proxy lưu lượng truy cập tới Tomcat (SSL [giữa Httpd và Tomcat] hiếm khi hữu ích trong trường hợp này) hoặc bạn thực hiện khách hàng kết nối trực tiếp với Tomcat và để nó xử lý kết nối SSL .

Tôi thừa nhận có một chút liên kết để trả lại xác nhận quyền sở hữu này. Tôi đoán tôi có thể sai (tôi chưa bao giờ thấy điều này được thực hiện, nhưng điều đó không có nghĩa là nó không tồn tại ...).

Như bạn đã biết, bạn cần kết nối trực tiếp hoặc kết nối hoàn toàn được chuyển tiếp, giữa tác nhân người dùng và điểm cuối SSL (trong trường hợp này, bạn muốn nó là Tomcat). Điều này có nghĩa là Apache Httpd sẽ không thể nhìn vào URL: nó sẽ biết tên máy chủ ở mức tốt nhất (khi sử dụng chỉ dẫn tên máy chủ).

Các lựa chọn duy nhất mà dường như không phụ thuộc vào một URL trong mod_proxy documentation là AllowCONNECT, đó là những gì được sử dụng cho mong máy chủ proxy cho HTTPS.

Thậm chí the options in mod_proxy_balancer mong đợi một đường dẫn tại một số điểm của cấu hình. Tài liệu của nó không đề cập đến SSL/HTTPS ("Nó cung cấp hỗ trợ cân bằng tải cho giao thức HTTP, FTP và AJP13"), trong khi mod_proxy nói ít nhất về SSL khi đề cập đến CONNECT.

tôi sẽ đề nghị một vài lựa chọn:

• Sử dụng một iptables dựa trên cân bằng tải, mà không đi qua httpd, kết thúc các kết nối trong Tomcat trực tiếp.

• Kết thúc kết nối SSL/TLS tại Httpd và sử dụng proxy ngược HTTP đơn giản cho Tomcat.

Tùy chọn thứ hai này yêu cầu cấu hình nhiều hơn để xử lý chứng chỉ ứng dụng khách và hạn chế bảo mật của Tomcat.

Nếu bạn đã định cấu hình ứng dụng web của mình bằng <transport-guarantee>CONFIDENTIAL</transport-guarantee>, bạn sẽ cần đặt Tomcat gắn cờ các kết nối là an toàn, mặc dù thực tế nó thấy chúng đến từ cổng HTTP thuần túy của nó. Đối với Tomcat 5, here is an article (ban đầu bằng tiếng Pháp, nhưng bản dịch tự động không quá tệ) mô tả cách thực hiện van để đặt isSecure(). (Nếu bạn không quen thuộc với valves, chúng tương tự như các bộ lọc, nhưng hoạt động trong chính Tomcat, trước khi yêu cầu được truyền cho webapp. Chúng có thể được cấu hình trong Catalina) Tôi nghĩ từ Tomcat 5.5, HTTP connector secure option thực hiện chính xác điều đó, mà không cần van của riêng bạn. Đầu nối AJP cũng có tùy chọn tương tự (nếu sử dụng mod_proxy_ajp hoặc mod_jk).

Nếu sử dụng trình kết nối AJP, mod_proxy_ajp sẽ chuyển tiếp chứng chỉ đầu tiên trong chuỗi và làm cho nó có sẵn trong Tomcat (thông qua thuộc tính yêu cầu bình thường). Có thể bạn sẽ cần SSLOptions +ExportCertData +StdEnvVars. mod_jk (mặc dù không được chấp nhận theo như tôi biết) cũng có thể chuyển tiếp toàn bộ chuỗi được khách hàng gửi (sử dụng JkOptions +ForwardSSLCertChain). Điều này có thể cần thiết khi sử dụng proxy certificates (điều này vô nghĩa nếu không có chuỗi đến chứng chỉ thực thể cuối cùng của chúng).

Nếu bạn muốn sử dụng mod_proxy_http, một mẹo là để vượt qua chứng chỉ qua an HTTP header (mod_header), sử dụng một cái gì đó như RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s. Tôi không thể nhớ các chi tiết chính xác, nhưng điều quan trọng là phải đảm bảo rằng tiêu đề này được xóa để nó không bao giờ xuất phát từ trình duyệt của khách hàng (người có thể giả mạo nó theo cách khác). Nếu bạn cần chuỗi đầy đủ, bạn có thể dùng thử this Httpd patch attempt. Cách tiếp cận này có lẽ sẽ cần thêm một van/bộ lọc để biến tiêu đề thành javax.servlet.request.X509Certificate (bằng cách phân tích cú pháp các khối PEM).

Một vài điểm khác mà bạn có thể quan tâm:

• Nếu tôi nhớ tốt, bạn cần phải tải CRL tập tin một cách rõ ràng cho httpd và configure it to use them. Tùy thuộc vào phiên bản của Httpd bạn đang sử dụng, bạn có thể phải restart it to reload the CRLs.
• Nếu bạn đang sử dụng lại thương lượng để nhận chứng chỉ ứng dụng khách, chỉ thị CLIENT-CERT sẽ không yêu cầu Httpd yêu cầu chứng chỉ ứng dụng theo như tôi biết (điều này được thực hiện thông qua một van có thể truy cập SSLSession khi sử dụng JSSE kết nối trực tiếp). Bạn có thể phải cấu hình đường dẫn phù hợp trong Httpd để yêu cầu chứng chỉ ứng dụng khách.