<?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: POODLE and the TLS_FALLBACK_SCSV Remedy</title>
	<atom:link href="http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/</link>
	<description>IT security tools, techniques and commentary</description>
	<lastBuildDate>Sun, 07 Sep 2025 03:12:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.6.1</generator>
	<item>
		<title>By: Jerome</title>
		<link>http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/#comment-5328</link>
		<dc:creator>Jerome</dc:creator>
		<pubDate>Thu, 13 Aug 2015 08:53:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.exploresecurity.com/?p=277#comment-5328</guid>
		<description><![CDATA[Before any data is sent, the client and server negotiate which cipher suite to use (as well as other parameters) before exchanging key material in such a way that they both end up with the same set of symmetric secrets, which a network man-in-the-middle can&#039;t determine. At this point, the two endpoints check to see that the handshake hasn&#039;t been tampered with by essentially hashing the previous &lt;em&gt;Handshake&lt;/em&gt;* messages, which has encryption and integrity checking applied. Both the client and the server does this so, using their newly derived secrets, they can verify these Finished messages from each other, and thus they can be confident that the handshake has been negotiated without any funny business. In this way the handshake is protected.

* there is a specific set of Handshake messages (consult the RFC): other non-handshake messages may have been transmitted but won&#039;t be included in the making of the Finished message. The most &quot;famous&quot; exception is the ChangeCipherSpec (CCS) message, which precedes the Finished message. This is why the OpenSSL CCS vulnerability (CVE-2014-0224) could be exploited, as the attacker&#039;s CCS messages are not included in the handshake verification.]]></description>
		<content:encoded><![CDATA[<p>Before any data is sent, the client and server negotiate which cipher suite to use (as well as other parameters) before exchanging key material in such a way that they both end up with the same set of symmetric secrets, which a network man-in-the-middle can&#8217;t determine. At this point, the two endpoints check to see that the handshake hasn&#8217;t been tampered with by essentially hashing the previous <em>Handshake</em>* messages, which has encryption and integrity checking applied. Both the client and the server does this so, using their newly derived secrets, they can verify these Finished messages from each other, and thus they can be confident that the handshake has been negotiated without any funny business. In this way the handshake is protected.</p>
<p>* there is a specific set of Handshake messages (consult the RFC): other non-handshake messages may have been transmitted but won&#8217;t be included in the making of the Finished message. The most &#8220;famous&#8221; exception is the ChangeCipherSpec (CCS) message, which precedes the Finished message. This is why the OpenSSL CCS vulnerability (CVE-2014-0224) could be exploited, as the attacker&#8217;s CCS messages are not included in the handshake verification.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: alex</title>
		<link>http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/#comment-5263</link>
		<dc:creator>alex</dc:creator>
		<pubDate>Sat, 08 Aug 2015 21:51:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.exploresecurity.com/?p=277#comment-5263</guid>
		<description><![CDATA[&gt; Remember, the attacker can’t remove the TLS_FALLBACK_SCSV from the Client Hello because the handshake is cryptographically protected

Could you explain by what means it is protected? There is now signature over Cipher Suites in Client Hello.]]></description>
		<content:encoded><![CDATA[<p>&gt; Remember, the attacker can’t remove the TLS_FALLBACK_SCSV from the Client Hello because the handshake is cryptographically protected</p>
<p>Could you explain by what means it is protected? There is now signature over Cipher Suites in Client Hello.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerome</title>
		<link>http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/#comment-2996</link>
		<dc:creator>Jerome</dc:creator>
		<pubDate>Sun, 30 Nov 2014 22:36:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.exploresecurity.com/?p=277#comment-2996</guid>
		<description><![CDATA[Organisations might well have disabled SSLv3 (and v2) but IE8 supports TLSv1.0 by default so there&#039;s no obvious reason why that browser wouldn&#039;t connect. Test the domain you&#039;re trying to connect to at &lt;a href=&quot;https://www.ssllabs.com/ssltest/&quot; rel=&quot;nofollow&quot;&gt;SSL Labs&lt;/a&gt; and see which protocols it supports. Also check the &quot;handshake simulation&quot; section and see what it reports for IE8 under XP.]]></description>
		<content:encoded><![CDATA[<p>Organisations might well have disabled SSLv3 (and v2) but IE8 supports TLSv1.0 by default so there&#8217;s no obvious reason why that browser wouldn&#8217;t connect. Test the domain you&#8217;re trying to connect to at <a href="https://www.ssllabs.com/ssltest/" rel="nofollow">SSL Labs</a> and see which protocols it supports. Also check the &#8220;handshake simulation&#8221; section and see what it reports for IE8 under XP.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rich</title>
		<link>http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/#comment-2907</link>
		<dc:creator>Rich</dc:creator>
		<pubDate>Tue, 25 Nov 2014 02:33:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.exploresecurity.com/?p=277#comment-2907</guid>
		<description><![CDATA[Hi I am trying to open my cragslist account and I cant access the page. I would like to know If I should play with my ssl2 and3 settings or if I should get windows 8 ? I`m running xp home sp2 ie8  seems like the poodle problem thanks for any feed back richardpelzer@netzero.net]]></description>
		<content:encoded><![CDATA[<p>Hi I am trying to open my cragslist account and I cant access the page. I would like to know If I should play with my ssl2 and3 settings or if I should get windows 8 ? I`m running xp home sp2 ie8  seems like the poodle problem thanks for any feed back <a href="mailto:richardpelzer@netzero.net">richardpelzer@netzero.net</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darren Sandford</title>
		<link>http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/#comment-2401</link>
		<dc:creator>Darren Sandford</dc:creator>
		<pubDate>Wed, 22 Oct 2014 13:54:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.exploresecurity.com/?p=277#comment-2401</guid>
		<description><![CDATA[Thanks! This is the clearest description of how TLS_FALLBACK_SCSV works, and more importantly it&#039;s intention!  Much appreciated!]]></description>
		<content:encoded><![CDATA[<p>Thanks! This is the clearest description of how TLS_FALLBACK_SCSV works, and more importantly it&#8217;s intention!  Much appreciated!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: What is POODLE and how to detect it &#124; serializethoughts</title>
		<link>http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/#comment-2358</link>
		<dc:creator>What is POODLE and how to detect it &#124; serializethoughts</dc:creator>
		<pubDate>Sun, 19 Oct 2014 04:19:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.exploresecurity.com/?p=277#comment-2358</guid>
		<description><![CDATA[[&#8230;] then this attack can be carried out. To further read about TLS_FALLBACK_SCSV, you can visit here  and RFC [&#8230;]]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] then this attack can be carried out. To further read about TLS_FALLBACK_SCSV, you can visit here  and RFC [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
