我有一个运行在具有SSL证书的自定义域上的应用程序引擎应用程序（标准环境）。 我试图确保它免受BEAST攻击。
SSLyze扫描显示我的应用接受DES-CBC3-SHA 112位作为TLS密码。
是否有任何方法来更新TLS端点configuration，只允许TLSv1.2具有更强的密码（如更长的密钥，Diffie-Hellman等）？
或者，还有另一种方法来保护我的应用程序引擎应用程序与BEAST攻击？
BEAST攻击的主要问题在于初始化向量易于使用TLS 1.0及更低版本进行预测 。 为了有效地缓解这一点，客户端和服务器必须同意使用TLS 1.1或1.2。 Google的体系结构已经支持TLS 1.2一段时间了。 剩下的问题是客户更新他们的系统以支持1.2。 正如迈克尔·汉普顿（@Michael Hampton）所说，缓解BEAST的最有效方法是更新客户端，因为Google已经提供了TLS 1.2。
另一种select是服务器将接受的TLS连接限制为> 1.0。 这可能会起作用，但有可能排除大部分客户端人口的不利因素。 使用当前的App Engine体系结构， 无法将特定应用程序的TLS支持限制为> 1.0 。 如果您希望在安全性至关重要的情况下看到为App Engine实施此function，请在Google App Engine公开问题跟踪器上提交function请求，并在此处发布链接，以便其他人也可以支持该function。
与此同时，如果安全性至关重要，则可以使用Compute Engine实例（使用公共IP）创build自己的应用程序前端，并使其强制协商TLS> 1.0。 虽然这可能涉及重新实施App Engine现有体系结构的重要部分，即TLS端点和负载平衡器，但这是可能的。 这也会影响性能瓶颈，这取决于应用程序和实现的stream量。
如果顶级安全性不是绝对的，那么最好的办法就是向用户提供安全漏洞的build议，如果您发现他们正在使用已知不支持TLS> 1.0的系统。 除了应用程序之外，随着全球范围内移动到更安全的协议而不是排他性，整体上的安全性得到了更好的改善。