Tuesday, June 27, 2017

Re: [google-cloud-sql-discuss] Eliminating SSL overhead by using a Google VM to connect to CloudSQL

Hi,

What requirements you will have here depends a lot on what you are trying to defend against. If you are attack from outside google, then our physical network isolation should suffice (although you might want to encrypt anyway for security in depth). If you are trying to defend against attack from other GCP customers, our virtual network isolation should suffice (although you might want to to encrypt anyway, to protect against a hypothetical bug in this system).

The scenario you suggest - defending against Google employees with access to network devices inspecting your traffic - does require SSL to protect against. For what it's worth our policy strongly limits access to user data and we have extensive access restrictions and audit logging to enforce this.


To take a different approach on this issue... I'm kind of surprised SSL is adding 500ms of overhead for you. It might be possible to reduce this, here are some ideas:
  • Ensure your VMs and Cloud SQL instance are in the same region to minimize latency (thus reducing time introduced by additional round trips for ssl handshake)
  • Try out connection pooling (thus reducing the number of connections which incur connection setup overhead). If your application is legacy and cannot have connection pooling retrofitted you might achieve this with one of he various MySQL proxies around.
  • Ensure your VMs and Cloud SQL instance are not maxed out on CPU (as encryption adds some processor overhead)


On Tue, Jun 27, 2017 at 8:57 AM, Kurt Josep <kurt.josephson@gmail.com> wrote:
Thanks David - that clarifies a lot.  If traffic never leaves Google's networks, does that mean it would only be intercepted or sniffed by someone at Google who has access to your routers/switches, or that other customers like myself could potentially intercept it?  It's probably moot as I'd prefer not to allow _anyone_ access to mysql credentials with write privileges, but just wanted to get a feel for how limited of a pool of people would have access to see that traffic.

Thanks again,

-Kurt

On Tuesday, June 27, 2017 at 11:35:11 AM UTC-4, David Newgas wrote:
Hi Kurt,

I believe you are referring to articles such as this, which says "messages inside of the Google datacenter network will be encrypted". We use encryption in lots of places (such as on disk and HTTPS to users) but this is mostly referring to encryption in our RPC mechanism (closely related to gRPC, which also provides encryption). As traffic from your GCE instance to Cloud SQL is raw packets and not in this RPC mechanism it doesn't automatically get encrypted.

Therefore if you want your traffic encrypted between the VM and the Cloud SQL instance, you should enable SSL.  However note that traffic from GCE to Cloud SQL doesn't leave our network, so whether you need to encrypt this depends on your data and threat model.

You can read more about GCP security at https://cloud.google.com/security/.

David

On Tue, Jun 27, 2017 at 6:12 AM, Kurt Josep <kurt.jo...@gmail.com> wrote:
I remember reading that all traffic between endpoints within the Google ecosystem are encrypted - is that accurate?  Would that mean that I could turn off SSL for MYSQL connections from a Google hosted VM and my Google CloudSQL instance since the traffic would be encrypted anyway?  That would be a pretty big performance boost for my legacy app where the SSL negotiation slows down each request by ~0.5 seconds and requires extra resources that could be devoted to serving more traffic.

Thanks,

-Kurt

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/46c84354-38ec-4f6e-bbb0-4db06b189810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/3efd4dc9-ef77-4753-a909-7f58b7e47ff4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/CAJZK_bYHZ8FOGk7PjmrEkjUFQBht7ARqMiZWehzGmPWcVqy-wA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment