NNSquad - Network Neutrality Squad
[ NNSquad ] SSL would prevent it, Re: [IP] Internet security flaw exposes private data
----- Forwarded message from David Farber <dave@farber.net> ----- Date: Mon, 18 Jan 2010 11:38:36 -0500 From: David Farber <dave@farber.net> Subject: READ SSL would prevent it, Re: [IP] Internet security flaw exposes private data Reply-To: dave@farber.net To: ip <ip@v2.listbox.com> 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 ----- End forwarded message -----