READ SSL would prevent it, Re: Internet security flaw exposes private data

[David Farber <dave () farber net>]

Begin forwarded message:

From: "David P. Reed" <dpreed () reed com>
Date: January 18, 2010 11:16:30 AM EST
To: dave () farber net
Cc: ip <ip () v2 listbox com>
Subject: Re: re SSL would prevent it, Re: [IP] Internet security flaw exposes private data

Re: SSL security: I have been studying man-in-the-middle setups on various Internet Access Providers for the past 6 
months, as well as setups that seem to be deployed by hackers pretending to offer "free Internet" in locations where 
hotspots ought to be (e.g. outside hotels, using SSIDs that appear to guests to be hotel-based WiFi).

There are a variety of ways to set up a difficult-to-detect spoof of a site normally protected by HTTPS:.

The easiest one is that "half SSL".   This appears to be in use by some I have discovered:

1. Intercept connections to http://foo.company.com (which normally redirects you on that page or a later one to an 
https: secure connection).   Do this as if the person connecting were originating the connection from the "middlebox" 
where the interception is carried out.  Substitute (textually) for all references to "https:" in the text returned the 
characters "http:", and continue to intercept all traffic to "company.com" as a man-in-the-middle.

2. Remember the URIs that were supposed to be accessed over https:, and whenever you see those URIs, substitute https: 
for http: (i.e. originate the SSL connection from the "middlebox" rather than the end user.)

Voila: from the user's point of view, the only difference is that he is using cleartext over http, rather than 
ciphertext over https for ALL of his connections.   The middlebox, however, makes it look to "company.com" as if the 
user is completely protected when his password is sent.   The only thing the user might notice is that his/her browser 
doesn't tell him/her that it it using https: for its accesses.   In the case of AJAX-based UIs in the browser, the use 
of https is not terribly obvious anyway, so the user doesn't see that it is not used.

This is not the only SSL-piercing man-in-the-middle attack I have seen by apparently "legitimate" access providers, 
including ones operated by quite large (F500) companies, universities, and state agencies.

This is not the "decrypt SSL" type of attack indicated by Christian Huitema.  It is far easier.  Easy to deploy as part 
of a "DPI" service, in fact.   One wonders whether DPI services will offer this as a way to "monetize" ISP services.

Application of "man-in-the middle attack" technology for commercial purposes is quite tempting: one merely needs to 
consider Phorm and NebuAd's claims that they were doing good by reading everything transmitted by each user on their 
customers' networks.  Why not snoop into SSL if your purposes are "right" and the techniques are easy?


On 01/17/2010 03:32 PM, Dave Farber wrote:
> Begin forwarded message:
>
> > From: Christian Huitema <huitema () microsoft com>
> > Date: January 17, 2010 3:20:02 PM EST
> > To: "dave () farber net" <dave () farber net>, ip <ip () v2 listbox com>
> > Subject: RE: SSL would prevent it, Re: [IP] Internet security flaw exposes private data
> >
> > > With at least one authenticated end-point (the end-point server, as usual), SSL would NOT allow a AT&T caching 
> > > server > that sits in-between to have had a "correct" SSL session between the wrong two end-points. See A. Menezes 
> > > et al., 
> > > /Handook of Applied Cryptography/, CRC Press, New York, 1997.
> >
> > Well, maybe. There are some proxies that actually decrypt SSL. They are mostly sold to enterprises and the military 
> > now. The argument is that security conscious organizations want to really control the traffic. They treat an 
> > encrypted flow to the outside as a hole. The proxy work by installing a trusted certificate authority on the client 
> > computer, and then making up certificates on the fly while relaying the SSL connections. 
> >
> > I am not aware that ISP are deploying any such proxies. But there are commercial effort to push them to do so, 
> > ostensibly for controlling encrypted transmission of music files or other protected content.
> >
> > -- Christian Huitema
> Archives      




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com