Implement a skeleton version of Expect CT reports

chrome/browser/net/chrome_network_delegate.cc

Index: chrome/browser/net/chrome_network_delegate.cc
diff --git a/chrome/browser/net/chrome_network_delegate.cc b/chrome/browser/net/chrome_network_delegate.cc
index 0775d81bca00232e5156420b3309875a9910361f..5a65ab0cb2574b78f58fdf1be388dc957c2cd106 100644
--- a/chrome/browser/net/chrome_network_delegate.cc
+++ b/chrome/browser/net/chrome_network_delegate.cc
@@ -34,6 +34,7 @@
 #include "chrome/browser/custom_handlers/protocol_handler_registry.h"
 #include "chrome/browser/net/chrome_extensions_network_delegate.h"
 #include "chrome/browser/net/connect_interceptor.h"
+#include "chrome/browser/net/expect_ct_monitor.h"
 #include "chrome/browser/net/request_source_bandwidth_histograms.h"
 #include "chrome/browser/net/safe_search_util.h"
 #include "chrome/browser/profiles/profile_manager.h"
@@ -339,6 +340,11 @@ void ChromeNetworkDelegate::set_data_use_aggregator(
   is_data_usage_off_the_record_ = is_data_usage_off_the_record;
 }
 
+void ChromeNetworkDelegate::set_expect_ct_monitor(
+    ExpectCTMonitor* expect_ct_monitor) {
+  expect_ct_monitor_ = expect_ct_monitor;
+}
+
 // static
 void ChromeNetworkDelegate::InitializePrefsOnUIThread(
     BooleanPrefMember* enable_referrers,
@@ -490,11 +496,21 @@ void ChromeNetworkDelegate::OnBeforeRedirect(net::URLRequest* request,
 #endif
   if (domain_reliability_monitor_)
     domain_reliability_monitor_->OnBeforeRedirect(request);
+  if (expect_ct_monitor_ &&
+      (request->ssl_info().cert_status &
+       net::CERT_STATUS_CT_COMPLIANCE_FAILED) != 0) {
+    expect_ct_monitor_->OnCTComplianceFailed(request);
+  }

[Ryan Sleevi, 2016/01/12 04:41:20]

This feels like a weird place to put this.

Is there a reason you don't see yourself super-classing
CTPolicyEnforcer/CertPolicyEnforcer and applying the checks there? Why do you
track by |request| versus, say, connection?

Just trying to think about the timing and implications, since this may result in
significantly more reports for a single connection (since they may be re-used,
and each and every connection will be invalid), and it's different than how,
say, we handle HPKP (which is enforced at socket connect time)

I'm just curious why this implementation wouldn't follow the same basic skeleton
of HPKP & reporting.

[estark, 2016/01/12 05:05:23]

This feature is more like PKP-Report-Only: we have to send CT reports at the
time that we process HTTP headers rather than socket connect time, because we
want to check for the `Expect-CT: preload` header before sending a report. So I
don't think we can do the whole thing inside
CertPolicyEnforcer::DoesConformToCTEVPolicy() (or whatever its name will change
to) because we don't know the response headers at the time that that's called.

   extensions_delegate_->OnBeforeRedirect(request, new_location);
 }
 
 
 void ChromeNetworkDelegate::OnResponseStarted(net::URLRequest* request) {
+  if (expect_ct_monitor_ &&
+      (request->ssl_info().cert_status &
+       net::CERT_STATUS_CT_COMPLIANCE_FAILED) != 0) {
+    expect_ct_monitor_->OnCTComplianceFailed(request);
+  }
   extensions_delegate_->OnResponseStarted(request);
 }