2

I have a app engine application (standard environment) running on a custom domain with an SSL certificate. I'm trying to make sure it is protected against a BEAST attack.

A SSLyze scan shows that my app accepts DES-CBC3-SHA 112 bits as TLS cipher.

Is there any way to update the TLS endpoint configuration to allow only TLSv1.2 with stronger ciphers (e.g. longer keys, Diffie-Hellman, etc.)?

Or, is there another way to protect my app engine application vs a BEAST attack?

MMA
  • 21
  • 3
  • You upgrade the web browser. BEAST is properly mitigated on the client side. It is not possible to mitigate BEAST on server side without using weak ciphers, which defeats the whole point of the exercise. – Michael Hampton Dec 15 '16 at 18:44
  • By any chance are you referring to the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite which would be different from the DES-CBC3-SHA 112 bits? In fact, I’ve run an SSLyze scan on my App Engine instance and found that it used among other strong ciphers suites, the TLS_RSA_WITH_3DES_EDE_CBC_SHA suite. This cipher suite should be safe against the BEAST attack as backed by the answer to this [post](http://security.stackexchange.com/questions/7440/what-ciphers-should-i-use-in-my-web-server-after-i-configure-my-ssl-certificate). – Alex Dec 23 '16 at 23:01
  • Though it's not exactly a _solution_, there's an issue for it in the public tracker: https://issuetracker.google.com/issues/80295154 It's been set to _Assigned_, so Google is apparently working on something. – Zalán Meggyesi Jul 11 '18 at 12:28

1 Answers1

2

The principle issue with the BEAST attack stems from initialization vectors being easily predictable with TLS 1.0 and below. To effectively mitigate this, the client and server must agree to use TLS 1.1 or 1.2. Google's architecture has supported TLS 1.2 for some time. The remaining issue was for clients to update their systems to support 1.2 as well. As stated by @Michael Hampton, the most effective way in this scenario to mitigate BEAST is to update clients as Google already offers TLS 1.2.

TLS on App Engine

The other option is for servers to limit accepted TLS connections to >1.0. This may work but has the downside of potentially excluding a significant portion of the client-side population. With the current App Engine architecture, there is no way to limit TLS support to >1.0 for a specific application. If you would like to see this feature implemented for App Engine in situations where security is critical, please file a feature request on the Google App Engine public issue tracker and post a link to it here so that others may support it as well.

Compute Engine as a proxy

In the meantime, if security is absolutely critical, you can create your own application front-end with Compute Engine instances (with public IPs) and have them forcefully negotiate TLS >1.0. This is possible though it would involve re-implementing a significant portion of App Engine's existing architecture, namely the TLS endpoint and load balancer. This also risks some performance bottlenecking depending on traffic to your application and your implementation.

If top tier security is not an absolute, your best bet would be to advise users of security vulnerabilities if you detect they are using systems known for not supporting TLS >1.0. Application aside, security over the wire as a whole is better improved with global movements towards safer protocols than with exclusivity.

Nicholas
  • 236
  • 1
  • 7