是否需要为仅转发到另一个域的域提供 SSL 证书？
Is it necessary to have an SSL cert for a domain that just forwards to another domain?
我有一个应用程序，它为各种帐户使用格式为 myapplication.com/{SLUG} 的帐户别名，类似于 Github 的做法。此域有 SSL 证书，一切正常。
但是，我有一些客户购买了他们提供给客户的域名，这些客户将他们转发到我申请中的帐户页面。
例如，假设 "John Smith" 购买了域 johnsmithisawesome.com，他将该域设置为转发到 myapplication.com/johnsmithisawesome。它主要用于品牌推广目的，因此 John 可以向客户提供一个 cool/catchy 域名，最终将他们发送到我的应用程序。
请注意，此重定向只会发生一次。我没有将它用作代理，它只是一种方便的方法，让人们可以使用一个吸引人的域，将他们完全重定向到应用程序域。初始重定向后，客户端将位于应用程序域中，所有请求都直接转到安全应用程序，它们不应再引用不安全域。
另请注意，没有安全凭证被传递 back/forth 到不安全的域。如果客户端必须登录，他们将直接在应用程序域上进行登录，根本不会与不安全的域进行交互。
流程基本上是这样工作的：
- 用户在浏览器中访问
johnsmithisawesome.com
johnsmithisawesome.com 的 DNS 使用指向 myapplication.com/johnsmithisawesome- 用户的浏览器 URL 现在位于
myapplication.com/johnsmithisawesome
- 所有进一步的请求都经过
myapplication.com/johnsmithisawesome，没有进一步的请求经过 johnsmithisawesome.com
我希望这对我想要完成的事情来说是明确的，我知道我不太精通术语。
如果域上没有 SSL 证书只是将它们转发到我的应用程序，是否存在任何安全风险？
我的假设是这无关紧要，因为实际的应用程序本身受到 SSL（或 TLS 作为新标准）的保护，而且我认为使用域进行转发不会有任何安全风险，但想和一些比我更了解这方面的人核实:)
不幸的是，简短的回答是肯定的，如果你想保护它，你也需要为另一个域单独的 SSL 证书。
考虑以下问题。 Alice（最终用户）在她的浏览器中输入 johnsmithisawesome.com，浏览器发出请求。中间人攻击者 Mallory 捕获请求，向 https://yourapplication.com/johnsmithisawesome 发出请求，这会在 Mallory 和您的应用程序之间创建一个 SSL 会话。当 Mallory 收到响应时，将对您的应用程序的所有引用转换为 http://johnsmithisawesome.com 和 returns 结果（修改后的）页面
给爱丽丝。
您的应用程序可以看到的是它所服务的 https 上的请求，一切正常。 Alice 可以看到的是她输入了一个域并得到了结果，甚至 URL 栏中的域名也与她想看到的相匹配。 Mallory 可以看到的是 Alice 和您的应用程序之间的所有（可能是机密的）流量。 Alice 的唯一提示是浏览器中没有 SSL 的指示，但大多数用户不会发现。
这称为 SSL Stripping，并且有现成的工具可以通过单击几下来完成此操作。你的场景和最初的想法相比有点特殊，但它只是帮助了攻击者。
事实上，马洛里甚至不需要这样做。没有 johnsmithisawesome.com 的证书，Mallory 可以只替换响应，仅此而已，严格来说他不需要剥离 SSL，因为没有任何 SSL。 :)
这就是发明 HSTS response header 的目的，应该在重定向期间由您的应用程序和 johnsmithisawesome.com 发送。
只要您不使用 HTTP 访问转发域，您将技术上不需要证书，即重定向将起作用。只是，当您想使用 HTTPS 访问转发域时，从技术上讲，您需要该域的证书，即使在此域上所做的所有操作都是转发到其他地方。否则最终用户将在浏览器中收到警告并且转发不会发生。
但是，即使技术上没有要求，出于安全原因，在转发域上使用 HTTPS 仍然有意义。
All further requests go through myapplication.com/johnsmithisawesome, there are no further requests going through johnsmithisawesome.com
请注意，这只是有效和无效的技术观点。
我将此解释为对客户端域只有一个请求导致重定向到最终域。并且不会与客户域共享任何敏感数据，而只会与最终（安全）域共享。
在这种情况下，主要的攻击向量是中间人攻击，它改变了重定向的目标，例如从 myapplication.com/johnsmithisawesome 到攻击者控制的域和 URL 如 myapplication-secure.com/johnsmithisawesome.使用正确命名的域，攻击者肯定可以欺骗用户相信他到达了正确的站点。
可以通过使用 HTTPS 保护重定向来减轻此类攻击，security-wise这是最佳选择。但这意味着客户端应该首先使用 HTTPS 访问客户端域，否则攻击者可能会劫持初始请求并更改重定向。如果接受此风险并希望攻击者在第一个请求期间不存在，则可以重定向到 HTTPS 并添加 HSTS header 以强制将来在客户端域上使用 HTTPS，或者可以进行 301 重定向到最终域而不是 302 重定向。使用 301，浏览器将缓存重定向，不会再次询问客户端服务器，而是在下次访问时直接转到最终域，从而绕过设法拦截对客户端域的请求的攻击者。
DNS for johnsmithisawesome.com uses an HTTP REDIRECT that points to myapplication.com/johnsmithisawesome
事情不是这样的。
从技术上讲，DNS 无法发出 HTTP 重定向。 DNS 仅用于将主机名解析为 IP 地址。然后，该地址的 HTTP 服务器可以在 HTTP 级别进行重定向。
一些 DNS 提供商仍然提供这样的 HTTP 重定向。但这通过将主机名解析为 DNS 提供商拥有的 IP 地址和 运行 此 IP 地址上的特殊 HTTP 服务器然后执行配置的 HTTP 重定向来实现。有时他们让客户配置这是 301 还是 302 重定向，有时则不是。而且通常无法在这种设置中配置证书。
我有一个应用程序，它为各种帐户使用格式为 myapplication.com/{SLUG} 的帐户别名，类似于 Github 的做法。此域有 SSL 证书，一切正常。
但是，我有一些客户购买了他们提供给客户的域名，这些客户将他们转发到我申请中的帐户页面。
例如，假设 "John Smith" 购买了域 johnsmithisawesome.com，他将该域设置为转发到 myapplication.com/johnsmithisawesome。它主要用于品牌推广目的，因此 John 可以向客户提供一个 cool/catchy 域名，最终将他们发送到我的应用程序。
请注意，此重定向只会发生一次。我没有将它用作代理，它只是一种方便的方法，让人们可以使用一个吸引人的域，将他们完全重定向到应用程序域。初始重定向后，客户端将位于应用程序域中，所有请求都直接转到安全应用程序，它们不应再引用不安全域。
另请注意，没有安全凭证被传递 back/forth 到不安全的域。如果客户端必须登录，他们将直接在应用程序域上进行登录，根本不会与不安全的域进行交互。
流程基本上是这样工作的：
- 用户在浏览器中访问
johnsmithisawesome.com johnsmithisawesome.com的 DNS 使用指向myapplication.com/johnsmithisawesome 的 HTTP 重定向
- 用户的浏览器 URL 现在位于
myapplication.com/johnsmithisawesome - 所有进一步的请求都经过
myapplication.com/johnsmithisawesome，没有进一步的请求经过johnsmithisawesome.com
我希望这对我想要完成的事情来说是明确的，我知道我不太精通术语。
如果域上没有 SSL 证书只是将它们转发到我的应用程序，是否存在任何安全风险？
我的假设是这无关紧要，因为实际的应用程序本身受到 SSL（或 TLS 作为新标准）的保护，而且我认为使用域进行转发不会有任何安全风险，但想和一些比我更了解这方面的人核实:)
不幸的是，简短的回答是肯定的，如果你想保护它，你也需要为另一个域单独的 SSL 证书。
考虑以下问题。 Alice（最终用户）在她的浏览器中输入 johnsmithisawesome.com，浏览器发出请求。中间人攻击者 Mallory 捕获请求，向 https://yourapplication.com/johnsmithisawesome 发出请求，这会在 Mallory 和您的应用程序之间创建一个 SSL 会话。当 Mallory 收到响应时，将对您的应用程序的所有引用转换为 http://johnsmithisawesome.com 和 returns 结果（修改后的）页面
给爱丽丝。
您的应用程序可以看到的是它所服务的 https 上的请求，一切正常。 Alice 可以看到的是她输入了一个域并得到了结果，甚至 URL 栏中的域名也与她想看到的相匹配。 Mallory 可以看到的是 Alice 和您的应用程序之间的所有（可能是机密的）流量。 Alice 的唯一提示是浏览器中没有 SSL 的指示，但大多数用户不会发现。
这称为 SSL Stripping，并且有现成的工具可以通过单击几下来完成此操作。你的场景和最初的想法相比有点特殊，但它只是帮助了攻击者。
事实上，马洛里甚至不需要这样做。没有 johnsmithisawesome.com 的证书，Mallory 可以只替换响应，仅此而已，严格来说他不需要剥离 SSL，因为没有任何 SSL。 :)
这就是发明 HSTS response header 的目的，应该在重定向期间由您的应用程序和 johnsmithisawesome.com 发送。
只要您不使用 HTTP 访问转发域，您将技术上不需要证书，即重定向将起作用。只是，当您想使用 HTTPS 访问转发域时，从技术上讲，您需要该域的证书，即使在此域上所做的所有操作都是转发到其他地方。否则最终用户将在浏览器中收到警告并且转发不会发生。
但是，即使技术上没有要求，出于安全原因，在转发域上使用 HTTPS 仍然有意义。
All further requests go through myapplication.com/johnsmithisawesome, there are no further requests going through johnsmithisawesome.com
请注意，这只是有效和无效的技术观点。
我将此解释为对客户端域只有一个请求导致重定向到最终域。并且不会与客户域共享任何敏感数据，而只会与最终（安全）域共享。
在这种情况下，主要的攻击向量是中间人攻击，它改变了重定向的目标，例如从 myapplication.com/johnsmithisawesome 到攻击者控制的域和 URL 如 myapplication-secure.com/johnsmithisawesome.使用正确命名的域，攻击者肯定可以欺骗用户相信他到达了正确的站点。
可以通过使用 HTTPS 保护重定向来减轻此类攻击，security-wise这是最佳选择。但这意味着客户端应该首先使用 HTTPS 访问客户端域，否则攻击者可能会劫持初始请求并更改重定向。如果接受此风险并希望攻击者在第一个请求期间不存在，则可以重定向到 HTTPS 并添加 HSTS header 以强制将来在客户端域上使用 HTTPS，或者可以进行 301 重定向到最终域而不是 302 重定向。使用 301，浏览器将缓存重定向，不会再次询问客户端服务器，而是在下次访问时直接转到最终域，从而绕过设法拦截对客户端域的请求的攻击者。
DNS for johnsmithisawesome.com uses an HTTP REDIRECT that points to myapplication.com/johnsmithisawesome
事情不是这样的。
从技术上讲，DNS 无法发出 HTTP 重定向。 DNS 仅用于将主机名解析为 IP 地址。然后，该地址的 HTTP 服务器可以在 HTTP 级别进行重定向。
一些 DNS 提供商仍然提供这样的 HTTP 重定向。但这通过将主机名解析为 DNS 提供商拥有的 IP 地址和 运行 此 IP 地址上的特殊 HTTP 服务器然后执行配置的 HTTP 重定向来实现。有时他们让客户配置这是 301 还是 302 重定向，有时则不是。而且通常无法在这种设置中配置证书。