ASP.net 设计问题，如果在 HTTPS 上则强制重定向到 HTTP

Question

在我的母版页上我有以下功能:

/// <summary>
/// Forces user to use unsecure HTTP connection
/// </summary>
public void FoceUnsecure()
{
    SSLHTTPDirect(false);
}

/// <summary>
/// Forces user to redirect to SSL
/// </summary>
public void ForceSSL()
{
    SSLHTTPDirect(true);
}

/// <summary>
/// Perform the redirect to self
/// </summary>
/// <param name="SSLRequired">True = Force HTTPS, False = Force HTTP</param>
private void SSLHTTPDirect(bool SSLRequired)
{
    if (int.Parse(ConfigurationManager.AppSettings["UseSSL"].ToString()) == 1)
    {
        bool IsOnSSL = HttpContext.Current.Request.Url.Scheme.ToLower() == "https";
        if (SSLRequired && !IsOnSSL)
            Response.Redirect(ConfigurationManager.AppSettings["SecureDomainRoot"] + "" + Request.RawUrl);
        else if (!SSLRequired && IsOnSSL)
            Response.Redirect(ConfigurationManager.AppSettings["MasterDomainRoot"] + "" + Request.RawUrl);
    }
}

在我需要 SSL 的页面上，它工作正常。我只是执行 Master.ForceSSL()，如果它们在 HTTP 上，它会重定向到安全连接。

问题是，我想将所有其他页面重定向到 HTTP(如果它们在 HTTPS 上)，而不必手动拖网搜索将函数调用添加到 ForceUnsecure() 的页面。

无论我尝试什么，如果调用了 ForceSSL() 函数(使用标志等)，我似乎无法从母版页中计算出来。理想情况下，我想要类似的东西

if(!SSLRequired && OnHTTPS){ForceUnsecure()}

但无论我尝试什么，母版页似乎都会在内容页调用 ForceSSL() 之前执行所有检查。所以我永远无法知道内容页面设置的值。

Answer 1

作为对评论的回应，我将其转化为答案:

我知道这不是您问题的直接答案；但是，可以这么说，我对此有强烈的感觉，可以登上肥皂盒。

---

首先，如果您拥有的任何内容足够敏感以至于需要用户名和密码，那么您不应该通过在初始登录过程后强行关闭 SSL 来发送未加密的 session cookie 数据来限制您的用户。

对于大多数网站，与在一个或多个帐户被劫持的情况下失去信任相比，所需的额外带宽和/或处理能力是微不足道的。只有您可以决定关闭 ssl 是否值得。

如果您认为性能问题可能比您的商业声誉更重要，那么请对您的应用程序使用标准分析工具，以准确了解影响是什么。这些工具包括像 YSlow 这样的一次性工具，以及像那些包含在 visual studio 高端版本中的“真正的”现成工具。

有值(value)的链接:
(讨论 SSL 对性能的影响)
How much overhead does SSL impose?
HTTP vs HTTPS performance

(讨论为什么登录后关闭 SSL 是个坏主意)
http://codebutler.com/firesheep
http://codebutler.com/firesheep-a-week-later-idiot-shepherds
http://codebutler.com/firesheep-three-weeks-later-fallout

(堆栈溢出承担其安全性 - 或缺乏安全性) https://meta.stackexchange.com/questions/69171/why-doesnt-the-stack-overflow-team-fix-the-firesheep-style-cookie-theft

综上所述，有一些特殊情况需要考虑。也就是说，如果攻击者拦截并冒充您网站上的用户，潜在的后果是什么？如果负面影响为零或接近零，那么关闭 ssl 可能 没问题。即便如此，如果不这样做的代价超出我的承受能力，我只会考虑走这条路。