3

I'm trying to pass the Trustwave pci DSS scan but i can't because it fails in "TLSv1.0 supported" and i think the problem is in GCE HTTPS loadbalancer that enables TLSv 1.0, 1.1 and 1.2 by default (https://cloud.google.com/compute/docs/load-balancing/http/#tls_support). I have tested my instances locally with openssl and with cipherscan (https://github.com/jvehent/cipherscan) and in either one i was only able to get connection using TLSv1.2 ciphers. It i try to use the same tools using the public ip of GCE HTTS Load Balancer i can connect using TLSv1,TLSv1.1,TLSv1.2.

André Freitas
  • 31
  • 1
  • 3
  • 2
    You might be able to use GCE Network Load Balancers instead, for forwarding the TCP packets directly to your instances; this means your HTTPS client would be handshaking directly with your application, and thus would use the TLSv1.2 ciphers. On the downside, you might not get the same per-request balancing behavior. – Castaglia Apr 12 '16 at 20:36
  • @Castaglia is it possible to post your comment as an answer, so others can benefit from it. – George Nov 11 '16 at 20:41
  • @George Ok, done. – Castaglia Nov 11 '16 at 21:11
  • Your best option will be to dispute this finding and submit your Risk Mitigation & Migration Plan, which will grant you an EXCEPTION to this finding until June 30th, 2018. You'll get another 14 months to deal with this issue. I submitted one and was granted an exception within a couple hours. The reasoning was for supporting IE9/10 on Win7, which does not support TLS 1.1 or 1.2 by default; support can only be configured manually in the browser, which no one will do. A significant enough percentage of our customers are still using those browsers on that OS, so we'd lose their business. – danemacmillan Apr 26 '17 at 15:54

2 Answers2

8

For anyone stumbling on this ; it is now possible to define an SSL-policy that can be applied to the target-https-proxies created by a GCE HTTPS load balancer.

The following command allow to create a policy that, to my knowledge, would had met the requirement for the mentioned Trustwave pci DSS scan in OP question.

$ gcloud beta compute ssl-policies create pci_dss_ssl_policy \
  --profile MODERN --min-tls-version 1.2

List the existing target-https-proxies with :

$ gcloud beta compute target-https-proxies list

Apply the created policy to a given target-https-proxies with :

$ gcloud beta compute target-https-proxies update \
  NAME_OF_HTTPS_TARGET --ssl-policy pci_dss_ssl_policy

For further reference, the ssl-policies is your friend. E.g. if one want to further restrict the policy using a custom list of cipher.

pfcarrier
  • 81
  • 1
  • 1
  • Thanks! I did the same using Google Cloud Console and it had `0` effect on the ssl policies.. After doing it with gcloud commands you provided above, everything worked perfectly! `sslscan` showed the difference :+1: – Yarik Nov 25 '20 at 11:15
2

You might be able to use GCE Network Load Balancers instead, for forwarding the TCP packets directly to your instances; this means your HTTPS client would be handshaking directly with your application, and thus would use the TLSv1.2 ciphers. On the downside, you might not get the same per-request balancing behavior.

Hope this helps!

Castaglia
  • 3,349
  • 3
  • 21
  • 42
  • 1
    The most significant difference in the load balancing behavior is that the TCP balancing can only balance between VMs in a single region. HTTP/HTTPS/SSL balancing can balance between VMs in different regions. – kasperd Nov 11 '16 at 21:46
  • Anyone who needs high availability should not do this, as @kasperd noted with the limitation to a single region. – danemacmillan Apr 26 '17 at 15:57
  • @danemacmillan You could always setup a separate TCP balancer in each region and use a DNS server with awareness of location of the users and health of the load balancers to direct users. But some would say that is re-inventing the wheel. – kasperd Apr 26 '17 at 19:51