<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: PSA: I think Rackspace Chicago &#038; Dallas datacenters are seriously compromised	</title>
	<atom:link href="https://dhyoung.net/2013/10/11/psa-i-think-rackspace-chicago-dallas-datacenters-are-seriously-compromised/feed/" rel="self" type="application/rss+xml" />
	<link>https://dhyoung.net/2013/10/11/psa-i-think-rackspace-chicago-dallas-datacenters-are-seriously-compromised/</link>
	<description>Scribo, ergo sum. Words and works of DH Young, scribbler at large.</description>
	<lastBuildDate>Fri, 22 Nov 2013 20:19:51 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.4.2</generator>
	<item>
		<title>
		By: David		</title>
		<link>https://dhyoung.net/2013/10/11/psa-i-think-rackspace-chicago-dallas-datacenters-are-seriously-compromised/#comment-17082</link>

		<dc:creator><![CDATA[David]]></dc:creator>
		<pubDate>Sat, 12 Oct 2013 00:05:52 +0000</pubDate>
		<guid isPermaLink="false">https://davidhaywoodyoung.com/?p=2206#comment-17082</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://dhyoung.net/2013/10/11/psa-i-think-rackspace-chicago-dallas-datacenters-are-seriously-compromised/#comment-17074&quot;&gt;Oran Dennison&lt;/a&gt;.

Hey Oran! Didn&#039;t know you read this blog. But yeah, serve me up a giant-sized rant. I&#039;ve only gazed on such obnoxious devices from afar, and mostly looked away even so.

Meanwhile I got an unconvincing response from Rackspace, in which the guy focused on all the things it could be aside from a MitM attack, decided on the basis of experimentation/logic that they were unlikely, and concluded all was well in their datacenters. Which strikes me as both unjustified and unhelpful.

I mean...just for starters, if I were building/configuring such a device I&#039;d only intercept traffic coming from -outside- the datacenter. That&#039;d partly be &#039;cause it makes sense to do so from most perspectives I can think of, and also partly &#039;cause I might not have a choice (depending on architecture/access). So his playing around from the inside is interesting but far from conclusive.

Assuming he&#039;s correct, though? I&#039;m using AT&#038;T at the moment but have had the same issues via Cable One and Comcast. And via VPNs terminating in Ireland, Canada, the US, Germany, and Latvia (because I like Latvia). It&#039;s fairly likely that all of the above are traveling through the same pipe at some point, and I guess I could start doing traceroutes...but I wouldn&#039;t trust the results and I&#039;m not sure there&#039;s much I could do about &#039;em anyway.

I&#039;m very close to concluding that I should host my own data/servers literally in-house. As it is I do most of my browsing via Tor/Tails/Orbot, using XPrivacy on Android and also starting off with a variety of VPNs. And I messed with runlevels/scripts months ago on my Rackspace-hosted VMs so Rackspace&#039;s &quot;imaging&quot; utilities don&#039;t work (it&#039;d also be very difficult for them to leverage &quot;physical&quot; access to get root). It just struck me that their ability to invisibly image a server and change the root pwd in the process was about the biggest security hole I could imagine, so I made sure they&#039;d at least have to write a special script. I&#039;ve even considered installing an OS on an encrypted partition that&#039;d require me to log in and give a passphrase to boot it up, but if they can defeat my current setup they could easily compromise the outer non-encrypted device and set up--for example--a keylogger anyway. So it&#039;d be fun but pointless.

At this point I don&#039;t trust any variety of commercial cert, but have more confidence in my self-generated stuff. Which is being spoofed in a sorta clumsy way right now. So I&#039;m very interested in your rant.

-D]]></description>
			<content:encoded><![CDATA[<div id="ac-section-17082"><p>In reply to <a href="https://dhyoung.net/2013/10/11/psa-i-think-rackspace-chicago-dallas-datacenters-are-seriously-compromised/#comment-17074">Oran Dennison</a>.</p>
<p>Hey Oran! Didn&#8217;t know you read this blog. But yeah, serve me up a giant-sized rant. I&#8217;ve only gazed on such obnoxious devices from afar, and mostly looked away even so.</p>
<p>Meanwhile I got an unconvincing response from Rackspace, in which the guy focused on all the things it could be aside from a MitM attack, decided on the basis of experimentation/logic that they were unlikely, and concluded all was well in their datacenters. Which strikes me as both unjustified and unhelpful.</p>
<p>I mean&#8230;just for starters, if I were building/configuring such a device I&#8217;d only intercept traffic coming from -outside- the datacenter. That&#8217;d partly be &#8217;cause it makes sense to do so from most perspectives I can think of, and also partly &#8217;cause I might not have a choice (depending on architecture/access). So his playing around from the inside is interesting but far from conclusive.</p>
<p>Assuming he&#8217;s correct, though? I&#8217;m using AT&amp;T at the moment but have had the same issues via Cable One and Comcast. And via VPNs terminating in Ireland, Canada, the US, Germany, and Latvia (because I like Latvia). It&#8217;s fairly likely that all of the above are traveling through the same pipe at some point, and I guess I could start doing traceroutes&#8230;but I wouldn&#8217;t trust the results and I&#8217;m not sure there&#8217;s much I could do about &#8217;em anyway.</p>
<p>I&#8217;m very close to concluding that I should host my own data/servers literally in-house. As it is I do most of my browsing via Tor/Tails/Orbot, using XPrivacy on Android and also starting off with a variety of VPNs. And I messed with runlevels/scripts months ago on my Rackspace-hosted VMs so Rackspace&#8217;s &#8220;imaging&#8221; utilities don&#8217;t work (it&#8217;d also be very difficult for them to leverage &#8220;physical&#8221; access to get root). It just struck me that their ability to invisibly image a server and change the root pwd in the process was about the biggest security hole I could imagine, so I made sure they&#8217;d at least have to write a special script. I&#8217;ve even considered installing an OS on an encrypted partition that&#8217;d require me to log in and give a passphrase to boot it up, but if they can defeat my current setup they could easily compromise the outer non-encrypted device and set up&#8211;for example&#8211;a keylogger anyway. So it&#8217;d be fun but pointless.</p>
<p>At this point I don&#8217;t trust any variety of commercial cert, but have more confidence in my self-generated stuff. Which is being spoofed in a sorta clumsy way right now. So I&#8217;m very interested in your rant.</p>
<p>-D</p>
</div><div class="ac-textarea" id="ac-textarea-17082" style="display: none;"><textarea>In reply to <a href="https://dhyoung.net/2013/10/11/psa-i-think-rackspace-chicago-dallas-datacenters-are-seriously-compromised/#comment-17074">Oran Dennison</a>.

Hey Oran! Didn't know you read this blog. But yeah, serve me up a giant-sized rant. I've only gazed on such obnoxious devices from afar, and mostly looked away even so.

Meanwhile I got an unconvincing response from Rackspace, in which the guy focused on all the things it could be aside from a MitM attack, decided on the basis of experimentation/logic that they were unlikely, and concluded all was well in their datacenters. Which strikes me as both unjustified and unhelpful.

I mean...just for starters, if I were building/configuring such a device I'd only intercept traffic coming from -outside- the datacenter. That'd partly be 'cause it makes sense to do so from most perspectives I can think of, and also partly 'cause I might not have a choice (depending on architecture/access). So his playing around from the inside is interesting but far from conclusive.

Assuming he's correct, though? I'm using AT&amp;T at the moment but have had the same issues via Cable One and Comcast. And via VPNs terminating in Ireland, Canada, the US, Germany, and Latvia (because I like Latvia). It's fairly likely that all of the above are traveling through the same pipe at some point, and I guess I could start doing traceroutes...but I wouldn't trust the results and I'm not sure there's much I could do about 'em anyway.

I'm very close to concluding that I should host my own data/servers literally in-house. As it is I do most of my browsing via Tor/Tails/Orbot, using XPrivacy on Android and also starting off with a variety of VPNs. And I messed with runlevels/scripts months ago on my Rackspace-hosted VMs so Rackspace's "imaging" utilities don't work (it'd also be very difficult for them to leverage "physical" access to get root). It just struck me that their ability to invisibly image a server and change the root pwd in the process was about the biggest security hole I could imagine, so I made sure they'd at least have to write a special script. I've even considered installing an OS on an encrypted partition that'd require me to log in and give a passphrase to boot it up, but if they can defeat my current setup they could easily compromise the outer non-encrypted device and set up--for example--a keylogger anyway. So it'd be fun but pointless.

At this point I don't trust any variety of commercial cert, but have more confidence in my self-generated stuff. Which is being spoofed in a sorta clumsy way right now. So I'm very interested in your rant.

-D</textarea></div>]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Oran Dennison		</title>
		<link>https://dhyoung.net/2013/10/11/psa-i-think-rackspace-chicago-dallas-datacenters-are-seriously-compromised/#comment-17074</link>

		<dc:creator><![CDATA[Oran Dennison]]></dc:creator>
		<pubDate>Fri, 11 Oct 2013 23:35:34 +0000</pubDate>
		<guid isPermaLink="false">https://davidhaywoodyoung.com/?p=2206#comment-17074</guid>

					<description><![CDATA[Yep, sounds like a possible MitM to me. Both the State of Alaska and ANTHC tried to turn on an automated HTTPS MitM (Blue Coat and WebSense) which is only partially successful if they&#039;re able to push out their own CA cert via group policy.  Yes this is the same technique used by Iran (and now the NSA) to spy on its citizens.  I have a giant rant on all the things that are broken with these corporate MitM cert spoofers if you&#039;re interested.  You can use a browser plugin such as Perspectives to be notified of spoofed certs.]]></description>
			<content:encoded><![CDATA[<div id="ac-section-17074"><p>Yep, sounds like a possible MitM to me. Both the State of Alaska and ANTHC tried to turn on an automated HTTPS MitM (Blue Coat and WebSense) which is only partially successful if they&#8217;re able to push out their own CA cert via group policy.  Yes this is the same technique used by Iran (and now the NSA) to spy on its citizens.  I have a giant rant on all the things that are broken with these corporate MitM cert spoofers if you&#8217;re interested.  You can use a browser plugin such as Perspectives to be notified of spoofed certs.</p>
</div><div class="ac-textarea" id="ac-textarea-17074" style="display: none;"><textarea>Yep, sounds like a possible MitM to me. Both the State of Alaska and ANTHC tried to turn on an automated HTTPS MitM (Blue Coat and WebSense) which is only partially successful if they're able to push out their own CA cert via group policy.  Yes this is the same technique used by Iran (and now the NSA) to spy on its citizens.  I have a giant rant on all the things that are broken with these corporate MitM cert spoofers if you're interested.  You can use a browser plugin such as Perspectives to be notified of spoofed certs.</textarea></div>]]></content:encoded>
		
			</item>
	</channel>
</rss>
