<?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: Thoughts on the Certificate Authority Attack presented at CCC</title>
	<atom:link href="http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/</link>
	<description>Information Security Think Tank</description>
	<lastBuildDate>Sat, 02 Feb 2013 17:50:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.1</generator>
	<item>
		<title>By: ×™×”×•× ×ª×Ÿ ×§×œ×™× ×’×¨ &#124; ×¢×œ ×”×¡×›× ×” ×‘×¦×•×•×™ ×¢×™×§×•×œ ××œ×§×˜×¨×•× ×™×™×. &#8207; :: Intellect or Insanity&#8207;</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-129252</link>
		<dc:creator>×™×”×•× ×ª×Ÿ ×§×œ×™× ×’×¨ &#124; ×¢×œ ×”×¡×›× ×” ×‘×¦×•×•×™ ×¢×™×§×•×œ ××œ×§×˜×¨×•× ×™×™×. &#8207; :: Intellect or Insanity&#8207;</dc:creator>
		<pubDate>Tue, 02 Nov 2010 09:35:53 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-129252</guid>
		<description>[...] ×‘×©× ×ª 2001 ×”×—×œ×” ×ž×“×™× ×ª ×™×©×¨××œ ×‘××¨×’×•×Ÿ ×“×™× ×™ ×”×”×¦×¤× ×” ×‘×¦×•×¨×” ×¨××•×™×” ×•×—×•×§×§×” ××ª ×—×•×§ ×—×ª×™×ž×” ××œ×§×˜×¨×•× ×™×ª. ×”×—×•×§, ×œ×ž×¨×•×ª ×”×™×•×ª×• ×ž×¢× ×™×™×Ÿ ×•×ž××•×“ ×¤×©×•×˜, ×§×•×‘×¢ ×”×¡×“×¨×™× ×™×—×¡×™×ª ×¡×‘×•×›×™× ××š ×‘×‘×¡×™×¡×• ××•×ž×¨ ×›×™ × ×™×ª×Ÿ ×œ×”×©×ª×ž×© ×‘×ª×¢×•×“×•×ª ××œ×§×˜×¨×•× ×™×•×ª (Certificates) ×¢×œ ×ž× ×ª ×œ×—×ª×•× ×¢×œ ×ž×¡×ž×›×™× ×›×š ×©×–×”×•×ª ×”×—×•×ª× ×ª×”×™×” ×ž××•×ž×ª×ª. ×”×ž×©×ž×¢×•×ª ×”×™× ×©×›××©×¨ ×ž×ª×§×‘×œ ×ž×¡×ž×š ××œ×§×˜×¨×•× ×™ ×›×–×”, ×ž×©×§×œ×• ×›×¨××™×” ××œ×§×˜×¨×•× ×™×ª ×’×‘×•×” ×‘×ž×™×•×—×“ ×•× ×™×ª×Ÿ ×œ×”× ×™×— ×©××œ× ×× ×”×’×•×¨× ×”×ž××©×¨ (×›×œ×•×ž×¨, ×ž×™ ×©×”× ×¤×™×§ ××ª ×”×ª×¢×•×“×”) ×›×©×œ ×‘×ž×™×œ×•×™ ×ª×¤×§×™×“×• (×•×“×‘×¨×™× ×›××œ×” ×§×•×¨×™× ×ž×“×™ ×¤×¢×) ×”×¨×™ ×©×ž×™ ×©×›×ª×‘ ××ª ×”×ž×¡×ž×š ×”×•× ××›×Ÿ ×ž×™ ×©×¨×©×•× ×‘×ª×¢×•×“×”. ×”×“×‘×¨ ×“×•×ž×” ×œ×—×•×ª×ž×ª ×œ×™×™×–×¨ ××• ×—×ª×™×ž×” ×¨×©×ž×™×ª, ××š ×‘×¢×œ ××ž×™× ×•×ª ×’×‘×•×”×” ×‘×ž×™×•×—×“ ×•×”×™×›×•×œ×ª ×œ×¤×¨×•×¥ ××•×ª×• ×§×™×™×ž×ª, ××š ×ž×‘×•×¡×¡×ª ×‘×¨×•×‘×” ×¢×œ ×˜×¢×•×™×•×ª ×× ×•×© ×•×”×™× × ×“×™×¨×”, ×™×§×¨×” ×•×¦×•×¨×›×ª ×ž×©××‘×™×. [...]</description>
		<content:encoded><![CDATA[<p>[...] ×‘×©× ×ª 2001 ×”×—×œ×” ×ž×“×™× ×ª ×™×©×¨××œ ×‘××¨×’×•×Ÿ ×“×™× ×™ ×”×”×¦×¤× ×” ×‘×¦×•×¨×” ×¨××•×™×” ×•×—×•×§×§×” ××ª ×—×•×§ ×—×ª×™×ž×” ××œ×§×˜×¨×•× ×™×ª. ×”×—×•×§, ×œ×ž×¨×•×ª ×”×™×•×ª×• ×ž×¢× ×™×™×Ÿ ×•×ž××•×“ ×¤×©×•×˜, ×§×•×‘×¢ ×”×¡×“×¨×™× ×™×—×¡×™×ª ×¡×‘×•×›×™× ××š ×‘×‘×¡×™×¡×• ××•×ž×¨ ×›×™ × ×™×ª×Ÿ ×œ×”×©×ª×ž×© ×‘×ª×¢×•×“×•×ª ××œ×§×˜×¨×•× ×™×•×ª (Certificates) ×¢×œ ×ž× ×ª ×œ×—×ª×•× ×¢×œ ×ž×¡×ž×›×™× ×›×š ×©×–×”×•×ª ×”×—×•×ª× ×ª×”×™×” ×ž××•×ž×ª×ª. ×”×ž×©×ž×¢×•×ª ×”×™× ×©×›××©×¨ ×ž×ª×§×‘×œ ×ž×¡×ž×š ××œ×§×˜×¨×•× ×™ ×›×–×”, ×ž×©×§×œ×• ×›×¨××™×” ××œ×§×˜×¨×•× ×™×ª ×’×‘×•×” ×‘×ž×™×•×—×“ ×•× ×™×ª×Ÿ ×œ×”× ×™×— ×©××œ× ×× ×”×’×•×¨× ×”×ž××©×¨ (×›×œ×•×ž×¨, ×ž×™ ×©×”× ×¤×™×§ ××ª ×”×ª×¢×•×“×”) ×›×©×œ ×‘×ž×™×œ×•×™ ×ª×¤×§×™×“×• (×•×“×‘×¨×™× ×›××œ×” ×§×•×¨×™× ×ž×“×™ ×¤×¢×) ×”×¨×™ ×©×ž×™ ×©×›×ª×‘ ××ª ×”×ž×¡×ž×š ×”×•× ××›×Ÿ ×ž×™ ×©×¨×©×•× ×‘×ª×¢×•×“×”. ×”×“×‘×¨ ×“×•×ž×” ×œ×—×•×ª×ž×ª ×œ×™×™×–×¨ ××• ×—×ª×™×ž×” ×¨×©×ž×™×ª, ××š ×‘×¢×œ ××ž×™× ×•×ª ×’×‘×•×”×” ×‘×ž×™×•×—×“ ×•×”×™×›×•×œ×ª ×œ×¤×¨×•×¥ ××•×ª×• ×§×™×™×ž×ª, ××š ×ž×‘×•×¡×¡×ª ×‘×¨×•×‘×” ×¢×œ ×˜×¢×•×™×•×ª ×× ×•×© ×•×”×™× × ×“×™×¨×”, ×™×§×¨×” ×•×¦×•×¨×›×ª ×ž×©××‘×™×. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: A look at the CA Cert hack &#124; Mike Andrews</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-125156</link>
		<dc:creator>A look at the CA Cert hack &#124; Mike Andrews</dc:creator>
		<pubDate>Wed, 07 Jan 2009 11:02:57 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-125156</guid>
		<description>[...] http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/ [...]</description>
		<content:encoded><![CDATA[<p>[...] <a href="http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/" rel="nofollow">http://www.gnucitizen.org/blog.....ed-at-ccc/</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-125034</link>
		<dc:creator>Martin</dc:creator>
		<pubDate>Fri, 02 Jan 2009 12:26:21 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-125034</guid>
		<description>It might be worth mentioning that, while using MD5 was a bad idea, Verisign has shown an excellent response (they stopped using MD5 for RapidSSL within 24 hours): 
https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php</description>
		<content:encoded><![CDATA[<p>It might be worth mentioning that, while using MD5 was a bad idea, Verisign has shown an excellent response (they stopped using MD5 for RapidSSL within 24 hours):<br />
<a href="https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php" rel="nofollow">https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Janus Cook</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-125021</link>
		<dc:creator>Janus Cook</dc:creator>
		<pubDate>Fri, 02 Jan 2009 08:05:43 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-125021</guid>
		<description>&quot;still, this is a vulnerability in the vendor’s (RapidSSL) certificate issuing process, although MD5 is weak! or am I wrong?&quot;

It just makes it easier to bruteforce, because knowing about RapidSSL&#039;s process eliminates some parameters that would otherwise be completely random.

Now that Alexander is responding here, I would like to ask what he suggests for the near future. Since SHA-0/1 hashes have major flaws as well, and I believe that&#039;s still widely used.</description>
		<content:encoded><![CDATA[<p>&#8220;still, this is a vulnerability in the vendor’s (RapidSSL) certificate issuing process, although MD5 is weak! or am I wrong?&#8221;</p>
<p>It just makes it easier to bruteforce, because knowing about RapidSSL&#8217;s process eliminates some parameters that would otherwise be completely random.</p>
<p>Now that Alexander is responding here, I would like to ask what he suggests for the near future. Since SHA-0/1 hashes have major flaws as well, and I believe that&#8217;s still widely used.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rvdh</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124996</link>
		<dc:creator>rvdh</dc:creator>
		<pubDate>Thu, 01 Jan 2009 22:36:45 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124996</guid>
		<description>I only gleamed over the material, I got the idea that’s is sequential. It seems they sign plaintext with MD5 with minor entropy in the plaintext, but I think that the entropy isn’t the biggest problem here, it’s the signed plaintext ab initio. So even if they used SHA-X you could theoretically collide due to a chosen plaintext attack because of signing the plaintext. Granted it would be way tougher. So the flaw favors it’s injury: MD5. But most of the cryptanalysis goes way above my comprehension, maybe Alexander or someone else can elaborate on it.</description>
		<content:encoded><![CDATA[<p>I only gleamed over the material, I got the idea that’s is sequential. It seems they sign plaintext with MD5 with minor entropy in the plaintext, but I think that the entropy isn’t the biggest problem here, it’s the signed plaintext ab initio. So even if they used SHA-X you could theoretically collide due to a chosen plaintext attack because of signing the plaintext. Granted it would be way tougher. So the flaw favors it’s injury: MD5. But most of the cryptanalysis goes way above my comprehension, maybe Alexander or someone else can elaborate on it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pdp</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124991</link>
		<dc:creator>pdp</dc:creator>
		<pubDate>Thu, 01 Jan 2009 21:33:51 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124991</guid>
		<description>still, this is a vulnerability in the vendor&#039;s (RapidSSL) certificate issuing process, although MD5 is weak! or am I wrong?</description>
		<content:encoded><![CDATA[<p>still, this is a vulnerability in the vendor&#8217;s (RapidSSL) certificate issuing process, although MD5 is weak! or am I wrong?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rvdh</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124989</link>
		<dc:creator>rvdh</dc:creator>
		<pubDate>Thu, 01 Jan 2009 21:20:49 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124989</guid>
		<description>@Kender,

For me security and hacking is only about latency, and variations thereof. The trick for criminals is to have short latency, and for security folks it is to have long latency. It&#039;s a nice game but I think it&#039;s critical to realize that indeed the security paradigm cannot exist. That doesn&#039;t mean that security is void, it means that with long latency and addequate response and monitoring on a breach, you can be more secure.</description>
		<content:encoded><![CDATA[<p>@Kender,</p>
<p>For me security and hacking is only about latency, and variations thereof. The trick for criminals is to have short latency, and for security folks it is to have long latency. It&#8217;s a nice game but I think it&#8217;s critical to realize that indeed the security paradigm cannot exist. That doesn&#8217;t mean that security is void, it means that with long latency and addequate response and monitoring on a breach, you can be more secure.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rvdh</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124988</link>
		<dc:creator>rvdh</dc:creator>
		<pubDate>Thu, 01 Jan 2009 21:01:14 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124988</guid>
		<description>@Alexander,

In that case it&#039;s a deserved recognition. Security is and always has been an economics issue, and they surely knew about MD5 collision weakness and denied the fact that MD5 is obsolete, because it would hurt their business model, forgetting that brilliant researchers like yourself will make them regret the choice of dollar signs in their eyes. But maybe not, I don&#039;t think they even care after it went globally, these CA people don&#039;t care about their users safety, they care about dollars.

I wish they were as responsible as automobile manufacturers, when they detect a flaw they recall all models, something that the Internet is still missing: Liability.</description>
		<content:encoded><![CDATA[<p>@Alexander,</p>
<p>In that case it&#8217;s a deserved recognition. Security is and always has been an economics issue, and they surely knew about MD5 collision weakness and denied the fact that MD5 is obsolete, because it would hurt their business model, forgetting that brilliant researchers like yourself will make them regret the choice of dollar signs in their eyes. But maybe not, I don&#8217;t think they even care after it went globally, these CA people don&#8217;t care about their users safety, they care about dollars.</p>
<p>I wish they were as responsible as automobile manufacturers, when they detect a flaw they recall all models, something that the Internet is still missing: Liability.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kender</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124971</link>
		<dc:creator>Kender</dc:creator>
		<pubDate>Thu, 01 Jan 2009 09:13:29 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124971</guid>
		<description>What you&#039;re saying is that certificates are useless for determining the identity of servers. Do you assume that there are more rogue CA&#039;s out there? (one was created with a method you say is harder than other available methods)

I don&#039;t believe in perfect security so no, you cannot 100% trust all CA&#039;s. But the PKI is not built on 100% trust but on reasonable trust (imho). Incidents like the ones above erode that trust towards a level where it might not be reasonable to trust them anymore. Of course &#039;reasonable&#039; has different values for different people :)

Personally I would like to see some actions taken by the browser manufacturers (who include default trusted certs) and the CA&#039;s to beef up that trust. Stricter rules wrt algorithms and processes used should be enforced. Stricter validation and vetting of both CA&#039;s and resellers should be applied.


Oh, and if you don&#039;t trust a CA, feel free to remove their certs from your browser :) (Ff: Tools-&gt;Options-&gt;Advanced-&gt;Encryption-&gt;View certificates-&gt;Authorities)</description>
		<content:encoded><![CDATA[<p>What you&#8217;re saying is that certificates are useless for determining the identity of servers. Do you assume that there are more rogue CA&#8217;s out there? (one was created with a method you say is harder than other available methods)</p>
<p>I don&#8217;t believe in perfect security so no, you cannot 100% trust all CA&#8217;s. But the PKI is not built on 100% trust but on reasonable trust (imho). Incidents like the ones above erode that trust towards a level where it might not be reasonable to trust them anymore. Of course &#8216;reasonable&#8217; has different values for different people :)</p>
<p>Personally I would like to see some actions taken by the browser manufacturers (who include default trusted certs) and the CA&#8217;s to beef up that trust. Stricter rules wrt algorithms and processes used should be enforced. Stricter validation and vetting of both CA&#8217;s and resellers should be applied.</p>
<p>Oh, and if you don&#8217;t trust a CA, feel free to remove their certs from your browser :) (Ff: Tools->Options->Advanced->Encryption->View certificates->Authorities)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexander Sotirov</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124966</link>
		<dc:creator>Alexander Sotirov</dc:creator>
		<pubDate>Wed, 31 Dec 2008 19:30:17 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124966</guid>
		<description>I am one of the researchers who published this research. Our motivation (aside from getting famous) was to force the CAs to stop using the insecure MD5 hash function.

Obviously the theoretical attacks on certificate signing presented in 2005 and 2007 were not sufficient to make these companies stop using MD5, so we had to make the theoretical practical and do the attack. I was very pleased that Verisign responded quickly and as of today RapidSSL is no longer issuing MD5 signed certificates.</description>
		<content:encoded><![CDATA[<p>I am one of the researchers who published this research. Our motivation (aside from getting famous) was to force the CAs to stop using the insecure MD5 hash function.</p>
<p>Obviously the theoretical attacks on certificate signing presented in 2005 and 2007 were not sufficient to make these companies stop using MD5, so we had to make the theoretical practical and do the attack. I was very pleased that Verisign responded quickly and as of today RapidSSL is no longer issuing MD5 signed certificates.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pdp</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124963</link>
		<dc:creator>pdp</dc:creator>
		<pubDate>Wed, 31 Dec 2008 15:29:53 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124963</guid>
		<description>no, you are right. technically speaking, it will be easier to crack the root password but only if you can do that offline. remote attacks are challenging. and you are right about the CAs. we cannot trust them in anyway. this is the reason why I said in my post that for the same amount of money invested into this project, you can buy yourself a cert from an insider.  the only thing that I can figure right now that can potentially mitigate the whole trust in CAs issue is to record the signatures for every cert you encounter and you are willing to trust. that way you create an offline index of trusted certs, which if modified on later stage, you should get some warning for. but again, these warning will most likely be ignored by most people. :)

the way I see it now, self-signed certificates are more secure (from browser prospective). at least with the self-signed certs I can explicitly trust them. and if these trusted certs are changed, well... no worries! the browser will warn you, i think :)</description>
		<content:encoded><![CDATA[<p>no, you are right. technically speaking, it will be easier to crack the root password but only if you can do that offline. remote attacks are challenging. and you are right about the CAs. we cannot trust them in anyway. this is the reason why I said in my post that for the same amount of money invested into this project, you can buy yourself a cert from an insider.  the only thing that I can figure right now that can potentially mitigate the whole trust in CAs issue is to record the signatures for every cert you encounter and you are willing to trust. that way you create an offline index of trusted certs, which if modified on later stage, you should get some warning for. but again, these warning will most likely be ignored by most people. :)</p>
<p>the way I see it now, self-signed certificates are more secure (from browser prospective). at least with the self-signed certs I can explicitly trust them. and if these trusted certs are changed, well&#8230; no worries! the browser will warn you, i think :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rvdh</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124961</link>
		<dc:creator>rvdh</dc:creator>
		<pubDate>Wed, 31 Dec 2008 15:04:34 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124961</guid>
		<description>I believe Schneier said years ago in one of his books something similar like:

&quot;...How do we know that the CA issuer of certs can be trusted?...&quot;

Obvious answer: we can&#039;t. 

Furthermore I know no-one who checks the certs and read them before accepting them, it just a false sense of security for man in the middle attacks if you own one end of the line already. Root a box that sets up a SSL connection and no matter how secure your certs are, MIM won&#039;t be nessesary. Don&#039;t know about you but guess a root password requires less computation than setting up a CA yourself with 300 playstations.

But that might be me, I think to simple.</description>
		<content:encoded><![CDATA[<p>I believe Schneier said years ago in one of his books something similar like:</p>
<p>&#8220;&#8230;How do we know that the CA issuer of certs can be trusted?&#8230;&#8221;</p>
<p>Obvious answer: we can&#8217;t. </p>
<p>Furthermore I know no-one who checks the certs and read them before accepting them, it just a false sense of security for man in the middle attacks if you own one end of the line already. Root a box that sets up a SSL connection and no matter how secure your certs are, MIM won&#8217;t be nessesary. Don&#8217;t know about you but guess a root password requires less computation than setting up a CA yourself with 300 playstations.</p>
<p>But that might be me, I think to simple.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pdp</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124960</link>
		<dc:creator>pdp</dc:creator>
		<pubDate>Wed, 31 Dec 2008 14:55:10 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124960</guid>
		<description>I am not sure about the motivation, apart from pointing that it is possible. And I think that this often is very much needed in order to open the eyes of the masses.</description>
		<content:encoded><![CDATA[<p>I am not sure about the motivation, apart from pointing that it is possible. And I think that this often is very much needed in order to open the eyes of the masses.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rvdh</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124959</link>
		<dc:creator>rvdh</dc:creator>
		<pubDate>Wed, 31 Dec 2008 14:24:15 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124959</guid>
		<description>I don&#039;t understand the motivation behind all of this. Just like the DNS issues which has been known since ages (see: Berkeley) and many theorems written in 1991, MD5 has been written off since the late nineties and finally in 2004, and completely in 2005 by Vlastimil Klima who could produce collisions on a Pentium 1.6 GHZ. It&#039;s fairly known that you cannot rely on MD5 as well as SHA_0 since a decade. So anyone in the security field who relied on MD5 commits the original sin, so what&#039;s the news?

Other than that, there are plenty of other ways which are easier to perform. Think about shared certs on virtual hosting for example, keys that link all over place without the need for fast computation. Criminals use the path of least resistance, maybe this feat in Cryptography is interesting for governments, my bet is that we won&#039;t see attacks like these on webshops. it totally lacks perspective on the reality of Internet criminals, the term hacking certs is the right one as I see it only as a intellectual accomplishment build upon years of Cryptographic study unnecessary to provide PoC&#039;s because everyone in Cryptography was already in the knowing.  

Everyone knew the possible problems without the need for PoC&#039;s. But no one did anything, maybe that&#039;s the news: people start to see the real danger, other than that I&#039;m far from impressed. I wonder if they are in need of funding of some kind, academics with too much spare time with  agenda&#039;s beyond my comprehension. 

This is not a shoot down, it&#039;s a common sense analysis on something that doesn&#039;t needed a PoC in the first place to scare people away from using certs.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t understand the motivation behind all of this. Just like the DNS issues which has been known since ages (see: Berkeley) and many theorems written in 1991, MD5 has been written off since the late nineties and finally in 2004, and completely in 2005 by Vlastimil Klima who could produce collisions on a Pentium 1.6 GHZ. It&#8217;s fairly known that you cannot rely on MD5 as well as SHA_0 since a decade. So anyone in the security field who relied on MD5 commits the original sin, so what&#8217;s the news?</p>
<p>Other than that, there are plenty of other ways which are easier to perform. Think about shared certs on virtual hosting for example, keys that link all over place without the need for fast computation. Criminals use the path of least resistance, maybe this feat in Cryptography is interesting for governments, my bet is that we won&#8217;t see attacks like these on webshops. it totally lacks perspective on the reality of Internet criminals, the term hacking certs is the right one as I see it only as a intellectual accomplishment build upon years of Cryptographic study unnecessary to provide PoC&#8217;s because everyone in Cryptography was already in the knowing.  </p>
<p>Everyone knew the possible problems without the need for PoC&#8217;s. But no one did anything, maybe that&#8217;s the news: people start to see the real danger, other than that I&#8217;m far from impressed. I wonder if they are in need of funding of some kind, academics with too much spare time with  agenda&#8217;s beyond my comprehension. </p>
<p>This is not a shoot down, it&#8217;s a common sense analysis on something that doesn&#8217;t needed a PoC in the first place to scare people away from using certs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pdp</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124957</link>
		<dc:creator>pdp</dc:creator>
		<pubDate>Wed, 31 Dec 2008 13:34:10 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124957</guid>
		<description>not to mention that users who are usually familiar with PKI or SSL will completely ignore any warnings anyway.</description>
		<content:encoded><![CDATA[<p>not to mention that users who are usually familiar with PKI or SSL will completely ignore any warnings anyway.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kender</title>
		<link>http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/comment-page-1/#comment-124956</link>
		<dc:creator>Kender</dc:creator>
		<pubDate>Wed, 31 Dec 2008 13:29:07 +0000</pubDate>
		<guid isPermaLink="false">https://www.gnucitizen.org/?p=2053#comment-124956</guid>
		<description>The 1st step to improve the PKI would be to find out why it is possible for a CA to operate with flawed procedures (non-random serial, MD5 hashing). I thought they were held to some pretty strict standards. This attack, combined with [url=http://www.sslshopper.com/article-ssl-certificate-for-mozilla.com-issued-without-validation.html this] is making me lose trust in the PKI infra.</description>
		<content:encoded><![CDATA[<p>The 1st step to improve the PKI would be to find out why it is possible for a CA to operate with flawed procedures (non-random serial, MD5 hashing). I thought they were held to some pretty strict standards. This attack, combined with [url=http://www.sslshopper.com/article-ssl-certificate-for-mozilla.com-issued-without-validation.html this] is making me lose trust in the PKI infra.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
