<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Amazon web services signature vulnerability</title>
	<atom:link href="http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/</link>
	<description>Embedded security, crypto, software protection</description>
	<lastBuildDate>Mon, 08 Mar 2010 21:19:29 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/#comment-5176</link>
		<dc:creator>Nate Lawson</dc:creator>
		<pubDate>Sat, 18 Jul 2009 18:50:27 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=339#comment-5176</guid>
		<description>SK, for client cert auth, you have to distribute the private key (PEM file) to all the clients. Or, you have to provide a tool to the clients to generate their own keys. Either way, it&#039;s not well-integrated with the stock OS. Does Apple&#039;s keychain utility automatically generate client certs/keys?</description>
		<content:encoded><![CDATA[<p>SK, for client cert auth, you have to distribute the private key (PEM file) to all the clients. Or, you have to provide a tool to the clients to generate their own keys. Either way, it&#8217;s not well-integrated with the stock OS. Does Apple&#8217;s keychain utility automatically generate client certs/keys?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SK</title>
		<link>http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/#comment-5175</link>
		<dc:creator>SK</dc:creator>
		<pubDate>Fri, 17 Jul 2009 22:38:05 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=339#comment-5175</guid>
		<description>Nate - I couldn&#039;t hit &#039;reply&#039; next to your comment so I&#039;m asking here. I&#039;m not sure I understand how client certs involve distributing a blob to your clients. Dont you mean distributing a blob to your servers? Essentially the server should check whether the client cert matches the cert the client gave you through some out of band mechanism (like uploading through a site).</description>
		<content:encoded><![CDATA[<p>Nate &#8211; I couldn&#8217;t hit &#8216;reply&#8217; next to your comment so I&#8217;m asking here. I&#8217;m not sure I understand how client certs involve distributing a blob to your clients. Dont you mean distributing a blob to your servers? Essentially the server should check whether the client cert matches the cert the client gave you through some out of band mechanism (like uploading through a site).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nolan</title>
		<link>http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/#comment-5059</link>
		<dc:creator>Nolan</dc:creator>
		<pubDate>Mon, 01 Jun 2009 23:44:55 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=339#comment-5059</guid>
		<description>Oh, I absolutely agree with your point, and I use https for all my interactions with AWS.

I was merely compulsively correcting minor misinformation.</description>
		<content:encoded><![CDATA[<p>Oh, I absolutely agree with your point, and I use https for all my interactions with AWS.</p>
<p>I was merely compulsively correcting minor misinformation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/#comment-5058</link>
		<dc:creator>Nate Lawson</dc:creator>
		<pubDate>Mon, 01 Jun 2009 20:56:12 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=339#comment-5058</guid>
		<description>I appreciate you explaining more, but I still don&#039;t see the need for the distinction you&#039;re making between endpoints and application. However, I can come up with an artificial scenario which should be helpful for discussion.

Consider a client, middle-man, and server. The client wants to authenticate its requests to the server while sending them through the untrusted middle-man. The middle-man should not be able to masquerade as the client and generate its own requests. Obviously, SSL does not provide this protection.

But instead of rushing to implement a separate authenticated message layer, why not reconsider the architecture that creates an untrusted middle-man? In nearly all cases, this is due to an attempt to work around a broken architecture by adding custom crypto. Now you have two problems!

I have seen very few cases where this was actually necessary and in those cases, a high-level API, such as Keyczar, or using an OS subsystem, such as disk encryption, were the right answers.</description>
		<content:encoded><![CDATA[<p>I appreciate you explaining more, but I still don&#8217;t see the need for the distinction you&#8217;re making between endpoints and application. However, I can come up with an artificial scenario which should be helpful for discussion.</p>
<p>Consider a client, middle-man, and server. The client wants to authenticate its requests to the server while sending them through the untrusted middle-man. The middle-man should not be able to masquerade as the client and generate its own requests. Obviously, SSL does not provide this protection.</p>
<p>But instead of rushing to implement a separate authenticated message layer, why not reconsider the architecture that creates an untrusted middle-man? In nearly all cases, this is due to an attempt to work around a broken architecture by adding custom crypto. Now you have two problems!</p>
<p>I have seen very few cases where this was actually necessary and in those cases, a high-level API, such as Keyczar, or using an OS subsystem, such as disk encryption, were the right answers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PB</title>
		<link>http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/#comment-5046</link>
		<dc:creator>PB</dc:creator>
		<pubDate>Wed, 27 May 2009 06:51:31 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=339#comment-5046</guid>
		<description>Nate, I agree that SSL is useful &quot;protect URLs and data, giving privacy, integrity protection&quot;. However, I would clarify that SSL provides those features in an application agnostic way. An application doesn&#039;t need to know anything about what SSL is doing. This is a good thing (tm). However, if client certificates are not viable and an application needs some degree of message level security (authenticating messages for example), we may have to look elsewhere. That was the main point of my earlier comments. In my opinion, without certificates the protections afforded to us by SSL don&#039;t address all of the requirements (most, but not all). In my view SSL provides protection at the transport level, not the message level. Yes, the messages within the SSL stream have those protections, but that is from the context of the *SSL endpoints*, not the *application*. HMAC is an option that can authenticate messages from the context of the application. Like you mentioned in your original post, you&#039;d definitely need to rely on SSL to protect the data stream.</description>
		<content:encoded><![CDATA[<p>Nate, I agree that SSL is useful &quot;protect URLs and data, giving privacy, integrity protection&quot;. However, I would clarify that SSL provides those features in an application agnostic way. An application doesn&#8217;t need to know anything about what SSL is doing. This is a good thing &#8482;. However, if client certificates are not viable and an application needs some degree of message level security (authenticating messages for example), we may have to look elsewhere. That was the main point of my earlier comments. In my opinion, without certificates the protections afforded to us by SSL don&#8217;t address all of the requirements (most, but not all). In my view SSL provides protection at the transport level, not the message level. Yes, the messages within the SSL stream have those protections, but that is from the context of the *SSL endpoints*, not the *application*. HMAC is an option that can authenticate messages from the context of the application. Like you mentioned in your original post, you&#8217;d definitely need to rely on SSL to protect the data stream.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/#comment-5036</link>
		<dc:creator>Nate Lawson</dc:creator>
		<pubDate>Fri, 22 May 2009 17:12:26 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=339#comment-5036</guid>
		<description>Explain how idempotency saves you here:

  ADD_USER(&quot;nate&quot;)
  DELETE_USER(&quot;nate&quot;)
  ADD_USER(&quot;nate&quot;)</description>
		<content:encoded><![CDATA[<p>Explain how idempotency saves you here:</p>
<p>  ADD_USER(&#8220;nate&#8221;)<br />
  DELETE_USER(&#8220;nate&#8221;)<br />
  ADD_USER(&#8220;nate&#8221;)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
