SSLredirect307概念

我和一个同事正试图通过HTTPS重新定位一个问题,我认为更多的眼睛不会受到伤害。 我们的问题如下:

  • 客户端(192.168.0.1)和主机1(4.3.2.1)成功协商SSLv3.0会话。
  • 客户端(192.168.0.1)尝试发送HTTP数据到主机1(4.3.2.1),并被redirect(307)到主机2(4.3.2.2)
  • HTTP数据永远不会被Host2接收(4.3.2.2)

我们对SSL的了解是相当不错的,但是那些真正精通的人已经不在这里了,所以请耐心等待。 这是我们的问题:

  1. 由于我们通过SSLredirect,Host2(4.3.2.2)证书通用名称是否需要与客户端(192.168.0.1)证书上的通用名称匹配?
  2. 什么是可能导致这个问题的其他问题?

您将重新启动一个通向redirect主机的通信。

如果你这样做:

1)用户请求https://exampleA.com/redirect

2) https://exampleA.com/redirect 307转向https://exampleB.com/redirect

3)用户请求https://exampleB.com/redirect

在1中,您需要与exampleA.com CN成功进行SSL交换,在3中,您需要与exampleB.com CN成功进行SSL交换(如果您正转向https,如果转发到HTTP,则不需要)

此外,请注意,3不会redirect到1,这会造成“大循环和坏循环”。

快速提醒:您在实际传递虚拟主机数据之前先协商SSL(除非使用SNI,这很less见)。 因此,如果A和B位于同一台服务器上,则两者都使用相同的IP,则可能会出现问题。