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