Provide enterprise policy option to set the minimum SSL version.

components/policy/resources/policy_templates.json

Index: components/policy/resources/policy_templates.json
diff --git a/components/policy/resources/policy_templates.json b/components/policy/resources/policy_templates.json
index f65ef8c64ec77500cc8197aa4bb4304ba6bb3085..eead7c745dccb3746933418559c3a7ff71ef6bb9 100644
--- a/components/policy/resources/policy_templates.json
+++ b/components/policy/resources/policy_templates.json
@@ -123,7 +123,7 @@
 #   persistent IDs for all fields (but not for groups!) are needed. These are
 #   specified by the 'id' keys of each policy. NEVER CHANGE EXISTING IDs,
 #   because doing so would break the deployed wire format!
-#   For your editing convenience: highest ID currently used: 278
+#   For your editing convenience: highest ID currently used: 279
 #
 # Placeholders:
 #   The following placeholder strings are automatically substituted:
@@ -6791,6 +6791,52 @@
 
       If this policy is set to false, <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> will not allow creation of new profiles from the profile manager.''',
     },
+    {
+      'name': 'SSLVersionMin',

[Andrew T Wilson (Slow), 2014/10/14 08:32:53]

I wonder if instead of a blanket policy, if instead admins should be allowed to
provide a trusted whitelist of sites that are allowed to use sslv3?

[agl, 2014/10/14 17:39:51]

The message is very much that we're moving on from SSLv3. Adding infrastructure
to support of a set of hostnames would make the patch more difficult and
dangerous to merge. Users who are using this to reenable SSLv3 /should/ feel
that it's a questionable choice!

(Also, some might want to use it to *disable* SSLv3 before we do by default. I
rather hope that's the more common usage.)

+      'type': 'string-enum',
+      'schema': {
+        'type': 'string',
+        'enum': [
+          'ssl3',
+          'tls1',
+          'tls1.1',
+          'tls1.2',
+        ],
+      },
+      'items': [
+        {
+          'name': 'SSLv3',
+          'value': 'ssl3',
+          'caption': 'SSL 3.0',
+        },
+        {
+          'name': 'TLSv1',
+          'value': 'tls1',
+          'caption': 'TLS 1.0',
+        },
+        {
+          'name': 'TLSv1.1',
+          'value': 'tls1.1',
+          'caption': 'TLS 1.1',
+        },
+        {
+          'name': 'TLSv1.2',
+          'value': 'tls1.2',
+          'caption': 'TLS 1.2',
+        },
+      ],
+      'supported_on': ['chrome.*:39-', 'chrome_os:39-', 'android:39-'],

[Andrew T Wilson (Slow), 2014/10/14 08:32:53]

We use our own net stack on ios - is this policy supported on that platform?

[Joao da Silva, 2014/10/14 08:40:10]

Is this going to be merged back to 39? Current trunk is 40.

[agl, 2014/10/14 17:39:51]

We are going to watch and listen to requests once the issue is public but I do
expect that this will be merged to 39 at least.

[agl, 2014/10/14 17:39:51]

Thanks -- I just omitted ios. Done.

+      'features': {
+        'dynamic_refresh': True,
+        'per_profile': False,
+      },
+      'example_value': 'ssl3',
+      'id': 279,
+      'caption': '''Minimum SSL version enabled''',
+      'desc': '''If this policy is not configured then <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> will use a default minimum version, which is SSLv3 in Chrome 39 but may be TLS 1.0 in Chrome 40.

[Andrew T Wilson (Slow), 2014/10/14 08:32:53]

The idea is that ssl3 < tls1 for the purposes of this check - I'm wondering if
we need to make this fact clearer in the documentation?

[agl, 2014/10/14 17:39:51]

That's good point. It is something that people have misunderstood in the past.
I've added a note to that effect.

+
+      Otherwise it may be set to one of the following values: "sslv3", "tls1", "tls1.1" or "tls1.2". When set, <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> will not use SSL/TLS versions less than the specified version. An unrecognized value will be ignored.''',
+    },
   ],
   'messages': {
     # Messages that are not associated to any policies.