Question

我们的应用程序在两个框架中运行。一个使用https，一个不使用。我正在尝试配置tomcat连接器，但是当我在一个框架中工作时，它在另一个框架中不起作用。

我被告知我们不需要完全“处理”SSL，因为这是由我们的负载均衡器处理的。不确定这些意味着什么。

例如：在一个框架中，我们将获得权限拒绝错误，另一个框架将工作。如果我们改变相反的情况，但是我们会得到无效的证书错误，而不是权限错误。

连接器上的tomcat文档没有很好地描述这些选项。知道我们做错了吗？

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000"/>

<Connector port="443" protocol="HTTP/1.1" SSLEnabled="false" maxThreads="150" scheme="https" secure="false" clientAuth="false" sslProtocol="TLS"/>

以上连接器与http框架一起工作，但在IE中给出了“混合内容警告”，因为有些请求是http和一些https。

非常感谢任何帮助。

Answer 1

如果你有一个连接器侦听端口443，它应该启用SSL，因为这是HTTPS端口，浏览器一连接就会发送SSL ClientHello消息 - 服务器将无法理解这一点除非它启用了SSL。

可能是您的负载均衡器正在终止SSL连接，并通过纯HTTP将请求转发给Tomcat。在这种情况下，您不需要端口443上的连接器。

但是，听起来您的某个应用程序可能正在使用客户端证书来执行身份验证。查看web.xml文件中的login-config元素。正在使用哪些身份验证方法？

如果您需要客户端证书，但SSL在负载均衡器处终止，则身份验证无法运行，因为客户端证书永远不会到达Tomcat。

Answer 2

如果你是负载平衡器的后面，例如带有mod_proxy的Apache Httpd（在反向模式下），SSL连接将从浏览器到负载均衡器（如“erickson”所述）。您可能确实在web.xml文件中检查了login-config（以检查您是否使用了CLIENT-CERT）。

您可能遇到的另一个问题是web.xml中的transport-guarantee元素：

<security-constraint>
   <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>
</security-constraint>

当您确定自己是一个安全的负载均衡器时，似乎有一种方法可以使用自定义阀强制执行此操作。这是an article on the subject (translated from French)。

混合内容的最可能原因是加载未托管在SSL上的图像。您可能会发现模板中的某个公司徽标使用http://进行了硬编码，或者某些Location标头返回http://网址。后者可以使用像这个Apache Httpd这样的配置来修复（假设它是你的负载均衡器），当然你需要用正确的地址替换它：

Header edit Location ^http://www.example.com/test/ https://www.example.com/test/

许多网站（甚至来自大公司）都在混合内容。这实际上是一件坏事，因为：

如果没有查看所有请求以及页面的来源，用户就无法真正知道页面的哪些部分是安全的，哪些部分不是。
从HTTPS请求到普通HTTP请求的一些泄漏cookie和信息。如果有人通过普通HTTP捕获该cookie，他们可能会通过HTTPS使用它作为冒名顶替者。（更具体地说，当使用没有安全标志的cookie时。）

对SSL配置和Tomcat感到困惑

2 个答案: