Re: Considering the pressure to turn HTTPS into a three-party protocol

Noah Mendelsohn wrote:
> 
> Eric J. Bowman wrote:
>
> > With Lenovo and Samsung now caught doing MitM HTTPS ad injection,
> > it's time to stop referring to this as an ISP issue.
> 
> Right, it's not only an ISP issue. As I recall earlier in this thread
> an example was discussed that was specifically an ISP, so I referred
> to that. It is at least an ISP issue according to reports. As you
> say, there are many other non-ISP MITM stories popping up, such as
> the Lenovo Superfish, etc.
> 

Didn't mean to call you out in particular. This thread is just the most-
recent example (see mnot's original post) of the issue being framed as
the fault of ISPs or uneducated end-users. It's amazing how in under a
week, even with the GoGo revelation, such framing has been obsoleted.

Pepsi *wants* to inject their ads on our TVs at no revenue benefit to
content publishers. Komodia (and such-like) *will* offer products which
make this possible through TV providers directly, SSL be damned. Lenovo
*will* likewise enable ad injection, if it's a profitable revenue
stream, without being constrained by the same cultural values their
customers suscribe to -- like privacy or security online.

Discussion of educating end-users not to do anything stupid, just
became moot. No more handwaving around parental-control appliances or
other opt-in uses, or corporate-firewall implementations affecting only
employee devices corporations have every right to control, or the
limited market-share of HotSpots monetized by ad injection, either.

The issue here is the Web. The Web is the motivator for technology like
Komodia's Redirector SDK [1,2]. Web-based efforts to head this off with
umpteen new techologies to fix HTTPS *in browsers* do nothing to fix
the same vulnerability for smtps or ftps, etc., ironically begotten of
the Web.

IMO, fixing the Web with some sort of improved HTTP digest-auth would
be a fix limited to the Web, not something with devastating consequences
for all other encrypted Internet traffic, when it goes sideways. But it
requires re-embracing the architectural notion of serendipitous re-use
as a Good Thing.

Because the consequences of calling interception a Bad Thing and trying
to eliminate it via ubiquitous HTTPS appear to be demonstrably worse,
than any of the FUD used to discredit digest-auth as even being a good
alternative starting point, ever even suggested. No borked digest-auth
implementation ever compromised the security of the entire Internet for
any subset of Web users, even if MitM'd.

As I've said before, framing the ubiquitous-HTTPS debate in terms of
the consequences being limited to caching, is a disservice even if the
Web's existing shared-cache architecture could be shown to be obsolete.
Different uses exist for the same architecture. Restrict intermediaries
from participating in *any* Web communication, and they will take it
upon themselves to participate in *all* Internet communication, is my
takeaway from the week's events.

Especially when HTTPS becomes a three-party protocol as a result. Which
is inevitable when every middleware appliance/app developer is lining
up for solutions like Komodia's, as a matter of survival in ubiquitous-
HTTPS bizarro-world.

Allowing intermediaries to participate in communications (serendipitous
re-use) in general, but restricting them from participating in
transactions, seems to me a more *solveable* problem. For one thing,
ubiquitous RESTful shared caching disincentivizes the market from
forking over big bucks to the likes of Komodia for libraries whose very
existence threatens Web security.

By which I mean, I doubt Superfish is the only licensee who neglected
to change the default 'komodia' password. Now those certs are out there.
I wouldn't be surprised to see them used as an attack vector by some
malworm in the future. That vector now has mass-market appeal, which it
wouldn't if embracing serendipitous re-use as an architectural precept,
only one benefit of which is shared caching -- others may have higher
market demand, albeit less exposure/awareness.

Sorry to go off on a rant, but this is exactly the sort of unintended
consequence (like breaking the back button in browsers) which results
from an approach to architecture of ex-post-facto documentation, as
opposed to guidance; i.e. we'll just update the living URI standard to
get rid of that inconvenient end-to-end HTTPS requirement since nobody
follows it anyway, seeing as how caching has become irrelevant.

Don't get me started on EFF's suggestion that Superfish should be a
browser extension -- Komodia's web pages explain exactly why the move
to restrict browser extensions to "app stores" is a selling point for
their approach (for one thing, no self-respecting app store would allow
Superfish). Another unintended-consequence example of the Web's current
direction financially incentivizing its own demise, but one which risks
taking the Internet down with it for trying to solve the Web's problems
at the wrong layer.

-Eric

Received on Saturday, 21 February 2015 02:22:31 UTC