Certificate Transparency: Require SCTs for EV certificates.

net/socket/ssl_client_socket_nss.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // This file includes code SSLClientSocketNSS::DoVerifyCertComplete() derived
 // from AuthCertificateCallback() in
 // mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp.
 
 /* ***** BEGIN LICENSE BLOCK *****
  * Version: MPL 1.1/GPL 2.0/LGPL 2.1
@@ skipping 3484 matching lines @@
       &ct_verify_result_,
       net_log_);
   // TODO(ekasper): wipe stapled_ocsp_response and sct_list_from_tls_extension
   // from the state after verification is complete, to conserve memory.
 
   VLOG(1) << "CT Verification complete: result " << result
           << " Invalid scts: " << ct_verify_result_.invalid_scts.size()
           << " Verified scts: " << ct_verify_result_.verified_scts.size()
           << " scts from unknown logs: "
           << ct_verify_result_.unknown_logs_scts.size();
+
+  if ((server_cert_verify_result_.cert_status & CERT_STATUS_IS_EV) &&
+      (!cert_transparency_verifier_->DoesConformToCTEVPolicy(
+          server_cert_verify_result_.verified_cert, ct_verify_result_))) {
+    VLOG(1) << "EV certificate without enough SCTs, removing EV status.";
+    server_cert_verify_result_.cert_status &= ~CERT_STATUS_IS_EV;
+  }

[Ryan Sleevi, 2014/08/05 22:19:10]

Another sign of layering concern is that this logic is getting embedded in a
particular platform implementation, rather than somewhere generic/platform
agnostic.

Conceptually, I think:
- We want a single class responsible for verifying certificates/certificate
chains (CertVerifier)
- We want a single class responsible for verifying correctness/validity of SCTs
(CTVerifier)
- We likely want a single class responsible for validating "policy" (where
policy includes things like PKP data, CT policy, etc)

I will have to think about this more, though. Right now, CertVerifier has 'part'
of the policy (validity periods, intranet names), and the SocketNSS has another
part (PKP validation, of which there are several open bugs because of this being
handled here).

There's also a further 'wrench' in things regarding how these policies affect
other aspects of "TLS-using" code - such as extensions/apps and Pepper/NaCl -
that we haven't quite ironed out as to which is the appropriate layer.

[Eran Messeri, 2014/10/20 17:26:30]

I've created a new class, CertPolicyEnforcer, which would be used from
SSLClientSocketNSS and SSLClientSocketOpenSSL. Does that work? Anything else you
want me to move there?

 }
 
 void SSLClientSocketNSS::LogConnectionTypeMetrics() const {
   UpdateConnectionTypeHistograms(CONNECTION_SSL);
   int ssl_version = SSLConnectionStatusToVersion(
       core_->state().ssl_connection_status);
   switch (ssl_version) {
     case SSL_CONNECTION_VERSION_SSL2:
       UpdateConnectionTypeHistograms(CONNECTION_SSL_SSL2);
       break;
@@ skipping 50 matching lines @@
 scoped_refptr<X509Certificate>
 SSLClientSocketNSS::GetUnverifiedServerCertificateChain() const {
   return core_->state().server_cert.get();
 }
 
 ChannelIDService* SSLClientSocketNSS::GetChannelIDService() const {
   return channel_id_service_;
 }
 
 }  // namespace net