When it’s a customer service announcement.   At least that’s what one in-flight internet on demand service provider claimed.

So, the first thing to understand is that there is no reason to believe that customer information was actually compromised.  On the other hand, as Bruce Schneier points out in Liars and Outliers, society runs on trust and that trust depends, in part, on our belief that entities are following the rules (“compliance”).

One of the principles of good security practices is “Trust but Verify”.  And that is where Google Chrome security engineer Adrienne Porter Felt comes in.  While establishing the secure connection negotiated between her browser and the service provider, Felt examined the SSL certificate.  All of us establish these connections all the time when browsing and I imagine very few know how to actually look at the certificate’s issuer and of those who know how few actually do so.

Felt found that the SSL certificate was a fake, not issued by the entity she expected (her employer), but issued instead by the service provider.  In using this fake certificate, a user would open themselves up to their encrypted traffic being examined by the provider.  So, rather than the end-to-end encryption expected, the user is allowing a “man-in-the-middle.”

When confronted with the security vulnerability they are introducing here, the CTO of the company responded that they are…

…working on many ways to bring more bandwidth to an aircraft. Until then, we have stated that we don’t support various streaming video sites and utilize several techniques to limit/block video streaming. One of the recent off-the-shelf solutions that we use proxies secure video traffic to block it. Whatever technique we use to shape bandwidth, it impacts only some secure video streaming sites and does not affect general secure Internet traffic. These techniques are used to assure that everyone who wants to access the Internet on [a plane we offer service on] will have a consistent browsing experience.

There is no reason to doubt this explanation; although as many have pointed out, all traffic could be decrypted.  Corporations put proxies between their intranet and the web all the time.  There is no breach of trust in those situations since the user is starting on the corporate network and should not be expecting privacy.

But here, where the public is invited to use the internet as a paid service, the public trusts that a secure session is just that, secure.

Explaining that the breach of that trust is on behalf of “a consistent browsing experience” is no doubt accurate, but not particularly comforting.

II.

In addition, it might have real compliance implications.

The HIPAA Omnibus Rule of 2013 specifically carves out internet service providers as not being “business associates”, and therefore not subject to HIPAA’s Security regulations.  The rule makers referred to this as the “conduit exception”:

The conduit exception is a narrow one and is intended to exclude only those entities providing mere courier services, such as the U.S. Postal Service or United Parcel Service and their electronic equivalents, such as internet service providers (ISPs) providing mere data transmission services. (Federal Register / Vol. 78, No. 17 / Friday, January 25, 2013 / Rules and Regulations p. 5571)

(Health Care providers should be providing VPN connections to their sensitive health care information and would therefore not be trusting the SSL connection of an ISP for their, the Health Care provider’s, compliance with HIPAA.)

And in the example of the in-flight ISP, since they did not have a contract with a Health Care provider (i.e., a HIPAA covered entity) they would not have been a business associate under HIPAA.  But if ISP’s are going to reserve the right to decrypt encrypted traffic as a general rule in order to provide for better customer experience, then perhaps this exception needs to be re-evaluated.