Ajax 100%SSL或选择性SSL、JSONP。。。没有错误吗？

我想请您发表深思熟虑的意见，以帮助我决定我的Ajax应用程序的以下两种原产地策略：

从HTTPS://www.mydomain.com加载我的所有资产

另外：Ajax很简单。同一原产地政策没有问题。
另外：PUT方法提供了大量有效负载。
另外：可以将网络错误消息反馈给用户。
缺点：服务器需要付出更多的努力来加密构成网站的所有糟粕。浏览器需要花更多的精力来解密这一切。总体而言，用户体验较慢。

通过HTTP://www.mydomain.com加载大部分浮渣，并仅将HTTPS://www.mydomain.com用于敏感数据交换

另外：更快的浏览器用户体验，更重要的是，我的服务器做的加密更少。 另外：通过JSONP处理SOP（*），Ajax仍然很简单。
减：JSONP上的GET方法将有效负载限制为2K-可能会成为一个问题。
大减号：在网络错误（任何类型）之后，找不到任何方法从报头获取状态响应。用户信息不能超出“我的坏”范围。

有什么想法吗

---

（*）顺便说一句，如果有人能给我举一个由同一域上的协议切换引起的安全漏洞的例子，我将不胜感激。我知道这些是不同的服务器，但那又怎样？它们在我的域名上。我控制他们。我不理解这个问题。

使用SSL。您是否对SSL的性能损失进行了基准测试？一般来说，现代计算机速度很快，SSL加密/解密开销可以忽略不计。有关此主题的一些讨论，请参阅

---

不必使用JSONP，能够使用HTTP PUT，以及您在我的书中概述的所有其他好处都比几个cpu周期更有价值。

关于该漏洞，我在下面列举了一些示例：

维持这种状态似乎不可取 使用HTTP和HTTPS之间的会话 相同的cookie或URL标记

想象一下，您的用户是 使用给定的cookie（或URL）登录 令牌）为每个 电子商务中的请求/响应 网站。如果中间有人 如果他能读懂那块饼干，他就可以了 登录到的HTTP或HTTPS变体 网站上有它。即使不管怎样 合法用户所做的一切都结束了 HTTPS，攻击者仍然可以 访问该会话（因为他也是 将拥有合法的cookie）。他 可以看到像购物车、购物车之类的页面 付款方式，可能会改变 送货地址

通过某种形式的考试是有道理的 HTTP会话和 HTTPS会话（如果您正在使用 会议），但将其视为一个整体 同样会引起一些 脆弱性。创建一次性的 查询参数中的令牌只是 过渡可能是一个解决办法。你 但是，我们应该将它们视为两个 单独的认证会话

此漏洞可能会发生 有时与网站使用混合 HTTP和HTTPS内容（特定） Firefox等浏览器将为您提供 发生这种情况时会发出警告，尽管 大多数人倾向于禁用它 第一次出现时）。你本来可以的 主服务器的HTTPS会话cookie 页面，但该页面包含图像 对于公司徽标，通过普通HTTP。 不幸的是，浏览器会发送 两者的cookie（因此攻击者 那就可以吃饼干了）。我已经 看到它发生了，即使图像在 问题根本就不存在（答案是否定的） 浏览器将发送带有 将cookie发送到服务器，即使 返回了一个404（未找到）

关于使用SSL/TLS的开销，应特别关注：

SSL/TLS在计算上不再昂贵

---

谢谢你为我恢复这些链接。有一个有趣的评论是关于SSL会话的缓存，以及具有许多客户端的SSL服务器如何需要大量内存。但我认为选择性SSL根本没有帮助。因为我偶尔需要SSL，所以无论如何我都会有那个缓存。我在初次握手时也会付出最高的代价。谢谢Bruno，但我不同意：我用“secure=true”创建了我的HTTPS PHPSESSID，从而完全避免了（意外地以纯文本传输此标识符）问题（浏览器仅通过HTTPS发送cookie）。所以，不，我仍然没有看到漏洞。我只对非会话渣滓使用HTTP。装饰等等。只要看看谷歌的东西。那是一首很棒的曲子。把它放进书签。非常感谢。事实上，这是不安全的饼干的问题。原则上，如果HTTP通信不需要authn，也可以。然后，混合内容的pb是用户很难知道哪些元素是安全传输的。你不能期望用户通过源代码检查HTTPS上的内容，以及应该检查的内容。如果站点按照您的建议正确设计，它应该很好，但浏览器很难检测到这一点并向用户发出适当的警告。不幸的是，在许多网站上，混合内容警告反映了一个实际问题。我现在已经将所有内容都转换为HTTPS，当FF发布混合警告时，我起初感到困惑。然后我意识到我正在做一个源于HTTP的Google混搭。在这一点上，我与100万平均作业：管他呢，反正加载-不要再麻烦问了。无论如何，这对我来说是一个讽刺：从某个未知的第三方加载一些.js文件（通过FF确定）肯定比从到发出Ajax请求（无论如何——通过FF不确定）更危险。我认为SOP太严格了wrt协议变更。。。