<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_11_05_144252</id>
	<title>Man-In-the-Middle Vulnerability For SSL and TLS</title>
	<author>Soulskill</author>
	<datestamp>1257430980000</datestamp>
	<htmltext><a href="http://imbaczekpocztafm/" rel="nofollow">imbaczek</a> writes <i>"The SSL 3.0+ and TLS 1.0+ protocols are vulnerable to a set of related attacks which allow a man-in-the-middle (MITM) operating at or below the TCP layer to <a href="http://www.links.org/?p=780">inject a chosen plaintext prefix into the encrypted data stream</a>, often without detection by either end of the connection. This is possible because <a href="http://extendedsubset.com/?p=8">an 'authentication gap' exists during the renegotiation process</a>, at which the MitM may splice together disparate TLS connections in a completely standards-compliant way. This represents a serious security defect for <a href="http://www.ietf.org/mail-archive/web/tls/current/msg03928.html">many or all protocols which run on top of TLS</a>, including HTTPS."</i></htmltext>
<tokenext>imbaczek writes " The SSL 3.0 + and TLS 1.0 + protocols are vulnerable to a set of related attacks which allow a man-in-the-middle ( MITM ) operating at or below the TCP layer to inject a chosen plaintext prefix into the encrypted data stream , often without detection by either end of the connection .
This is possible because an 'authentication gap ' exists during the renegotiation process , at which the MitM may splice together disparate TLS connections in a completely standards-compliant way .
This represents a serious security defect for many or all protocols which run on top of TLS , including HTTPS .
"</tokentext>
<sentencetext>imbaczek writes "The SSL 3.0+ and TLS 1.0+ protocols are vulnerable to a set of related attacks which allow a man-in-the-middle (MITM) operating at or below the TCP layer to inject a chosen plaintext prefix into the encrypted data stream, often without detection by either end of the connection.
This is possible because an 'authentication gap' exists during the renegotiation process, at which the MitM may splice together disparate TLS connections in a completely standards-compliant way.
This represents a serious security defect for many or all protocols which run on top of TLS, including HTTPS.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996310</id>
	<title>Re:How does this compromise SSL?</title>
	<author>Anonymous</author>
	<datestamp>1257443820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The webserver receives the attackers request with your session cookie? SSL is not just about confidentiality but also about data integrity...</p></htmltext>
<tokenext>The webserver receives the attackers request with your session cookie ?
SSL is not just about confidentiality but also about data integrity.. .</tokentext>
<sentencetext>The webserver receives the attackers request with your session cookie?
SSL is not just about confidentiality but also about data integrity...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999802</id>
	<title>And they do.</title>
	<author>SanityInAnarchy</author>
	<datestamp>1257415920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You're confusing a single vulnerability with a systemic problem. When this is fixed, that's what SSL certificate providers will do again.</p></htmltext>
<tokenext>You 're confusing a single vulnerability with a systemic problem .
When this is fixed , that 's what SSL certificate providers will do again .</tokentext>
<sentencetext>You're confusing a single vulnerability with a systemic problem.
When this is fixed, that's what SSL certificate providers will do again.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995190</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998108</id>
	<title>Re:We need to invest in Quantum Physics.</title>
	<author>jbezorg</author>
	<datestamp>1257452100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I died laughing when someone opened the box.</p></htmltext>
<tokenext>I died laughing when someone opened the box .</tokentext>
<sentencetext>I died laughing when someone opened the box.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995546</id>
	<title>Re:How does this compromise SSL?</title>
	<author>Anonymous</author>
	<datestamp>1257440100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Effectively, if they're between you and your server, 'click here to own this connection.'</p><p>I just talked with the resident encryption guru here - as long as the attacker is between you and the server you're connecting to, with this bug you can inject arbitrary data in front of the target encrypted packet. Some of the data you can inject includes commands, such as, 'By the way, send the rest of this connection to this IP over here, keep the authentication details but renegotiate the encryption.' In other words, 'Keep authentication but talk to the attacker's PC instead.'</p></htmltext>
<tokenext>Effectively , if they 're between you and your server , 'click here to own this connection .
'I just talked with the resident encryption guru here - as long as the attacker is between you and the server you 're connecting to , with this bug you can inject arbitrary data in front of the target encrypted packet .
Some of the data you can inject includes commands , such as , 'By the way , send the rest of this connection to this IP over here , keep the authentication details but renegotiate the encryption .
' In other words , 'Keep authentication but talk to the attacker 's PC instead .
'</tokentext>
<sentencetext>Effectively, if they're between you and your server, 'click here to own this connection.
'I just talked with the resident encryption guru here - as long as the attacker is between you and the server you're connecting to, with this bug you can inject arbitrary data in front of the target encrypted packet.
Some of the data you can inject includes commands, such as, 'By the way, send the rest of this connection to this IP over here, keep the authentication details but renegotiate the encryption.
' In other words, 'Keep authentication but talk to the attacker's PC instead.
'</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998156</id>
	<title>Re:This is news? Come on!</title>
	<author>Anonymous</author>
	<datestamp>1257452280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>The funny part is a lot of people argue, strongly, that self-signed certs aren't any less secure than CA-signed certs.</p></div><p>They are if you know what you are doing -- it is not trivial to generate an alternate self-signed certificate with the same fingerprint as the original. As to whether most people pay any attention to the fingerprint I couldn't say (I assume they don't, but I have no evidence either way), but the fact that people don't understand the system does not mean the system itself is broken.</p><p>And then there's the intermediate option that everyone just ignores -- generate your own CA and use that to generate normal certificates without paying anyone. Obviously that doesn't work for untrusted third parties, but neither do self-signed certificates.</p></div>
	</htmltext>
<tokenext>The funny part is a lot of people argue , strongly , that self-signed certs are n't any less secure than CA-signed certs.They are if you know what you are doing -- it is not trivial to generate an alternate self-signed certificate with the same fingerprint as the original .
As to whether most people pay any attention to the fingerprint I could n't say ( I assume they do n't , but I have no evidence either way ) , but the fact that people do n't understand the system does not mean the system itself is broken.And then there 's the intermediate option that everyone just ignores -- generate your own CA and use that to generate normal certificates without paying anyone .
Obviously that does n't work for untrusted third parties , but neither do self-signed certificates .</tokentext>
<sentencetext>The funny part is a lot of people argue, strongly, that self-signed certs aren't any less secure than CA-signed certs.They are if you know what you are doing -- it is not trivial to generate an alternate self-signed certificate with the same fingerprint as the original.
As to whether most people pay any attention to the fingerprint I couldn't say (I assume they don't, but I have no evidence either way), but the fact that people don't understand the system does not mean the system itself is broken.And then there's the intermediate option that everyone just ignores -- generate your own CA and use that to generate normal certificates without paying anyone.
Obviously that doesn't work for untrusted third parties, but neither do self-signed certificates.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995634</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995596</id>
	<title>Disabling SSLv3 in Firefox</title>
	<author>Derek Pomery</author>
	<datestamp>1257440460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Go to about:config<br>security.enable\_ssl2 - set to true<br>security.enable\_ssl3 - set to false</p><p>Some websites, such as addons.mozilla.org require SSLv3 - you might want to create a separate profile or temporarily enable SSLv3 on those sites.</p><p>I tested a few bank websites and paypal.  All accept SSLv2<br>Also, Firefox disables 40/64 bit and similarly weak protocols, so the SSLv2 protocol downgrade is not really as much of a problem as the SSLv3 replay attack.</p></htmltext>
<tokenext>Go to about : configsecurity.enable \ _ssl2 - set to truesecurity.enable \ _ssl3 - set to falseSome websites , such as addons.mozilla.org require SSLv3 - you might want to create a separate profile or temporarily enable SSLv3 on those sites.I tested a few bank websites and paypal .
All accept SSLv2Also , Firefox disables 40/64 bit and similarly weak protocols , so the SSLv2 protocol downgrade is not really as much of a problem as the SSLv3 replay attack .</tokentext>
<sentencetext>Go to about:configsecurity.enable\_ssl2 - set to truesecurity.enable\_ssl3 - set to falseSome websites, such as addons.mozilla.org require SSLv3 - you might want to create a separate profile or temporarily enable SSLv3 on those sites.I tested a few bank websites and paypal.
All accept SSLv2Also, Firefox disables 40/64 bit and similarly weak protocols, so the SSLv2 protocol downgrade is not really as much of a problem as the SSLv3 replay attack.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996126</id>
	<title>Re:Disabling SSLv3 in Firefox</title>
	<author>Anonymous</author>
	<datestamp>1257442860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Nice thought unfortunately most sites have disabled SSLv2 long ago for security standards compliance.</p></htmltext>
<tokenext>Nice thought unfortunately most sites have disabled SSLv2 long ago for security standards compliance .</tokentext>
<sentencetext>Nice thought unfortunately most sites have disabled SSLv2 long ago for security standards compliance.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995596</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995900</id>
	<title>Re:Disabling SSLv3 in Firefox</title>
	<author>Nursie</author>
	<datestamp>1257441840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Of course it is! This is terrible advice!</p><p>SSLv2 isn't widely used any more precisely because it's got systemic vulnerabilities. What's needed is a new revision of the protocol or the removal of the renegotiation feature.</p></htmltext>
<tokenext>Of course it is !
This is terrible advice ! SSLv2 is n't widely used any more precisely because it 's got systemic vulnerabilities .
What 's needed is a new revision of the protocol or the removal of the renegotiation feature .</tokentext>
<sentencetext>Of course it is!
This is terrible advice!SSLv2 isn't widely used any more precisely because it's got systemic vulnerabilities.
What's needed is a new revision of the protocol or the removal of the renegotiation feature.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995596</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995190</id>
	<title>Wrong Impression?</title>
	<author>Anonymous</author>
	<datestamp>1257438420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I had the impression that we paid money to SSL certificate providers because they provided security and identify confirmation.  Maybe that was just a wrong impression.</p></htmltext>
<tokenext>I had the impression that we paid money to SSL certificate providers because they provided security and identify confirmation .
Maybe that was just a wrong impression .</tokentext>
<sentencetext>I had the impression that we paid money to SSL certificate providers because they provided security and identify confirmation.
Maybe that was just a wrong impression.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994486</id>
	<title>web developers</title>
	<author>chrisranjana.com</author>
	<datestamp>1257434760000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext>So are these man in middle exploits fixed in the latest Ubuntu release ?</htmltext>
<tokenext>So are these man in middle exploits fixed in the latest Ubuntu release ?</tokentext>
<sentencetext>So are these man in middle exploits fixed in the latest Ubuntu release ?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996028</id>
	<title>Re:Disabling SSLv3 in Firefox</title>
	<author>MisterSquid</author>
	<datestamp>1257442440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I am not a developer or security expert, but I know quite a bit about Internet services (run my own LAMP server locked as tight as I can afford on a hobbyist's budget) and I do what I can.</p><p>Firefox disabled by default ssl2. In 2006, wrote a post telling users how to <a href="http://blog.mistersquid.com/2006/12/firefox\_20\_and\_ssl\_2\_a\_christm.html" title="mistersquid.com">reenable ssl2 in Firefox</a> [mistersquid.com]. One of my main users (and my fiance) gets lots of Firefox was running into errors. So, I disabled ssl2 in<nobr> <wbr></nobr>/etc/apache2/httpd.conf.</p><p>And now this.</p><p>So here is my big giant &ldquo;fuck off&rdquo; for the Firefox engineers and managers who collectively disabled ssl2 support to encourage server admins to shut off ssl2 support, even as I suspected all cryptography at the practical level is broken.</p><p>Yeah, I know security is a process, not a product, but if this is the case, then &ldquo;encourging&rdquo; admins to use one version of a protocol by disabling one is just the engineering version of &ldquo;I know better than you so follow my lead.&rdquo;</p></htmltext>
<tokenext>I am not a developer or security expert , but I know quite a bit about Internet services ( run my own LAMP server locked as tight as I can afford on a hobbyist 's budget ) and I do what I can.Firefox disabled by default ssl2 .
In 2006 , wrote a post telling users how to reenable ssl2 in Firefox [ mistersquid.com ] .
One of my main users ( and my fiance ) gets lots of Firefox was running into errors .
So , I disabled ssl2 in /etc/apache2/httpd.conf.And now this.So here is my big giant    fuck off    for the Firefox engineers and managers who collectively disabled ssl2 support to encourage server admins to shut off ssl2 support , even as I suspected all cryptography at the practical level is broken.Yeah , I know security is a process , not a product , but if this is the case , then    encourging    admins to use one version of a protocol by disabling one is just the engineering version of    I know better than you so follow my lead.   </tokentext>
<sentencetext>I am not a developer or security expert, but I know quite a bit about Internet services (run my own LAMP server locked as tight as I can afford on a hobbyist's budget) and I do what I can.Firefox disabled by default ssl2.
In 2006, wrote a post telling users how to reenable ssl2 in Firefox [mistersquid.com].
One of my main users (and my fiance) gets lots of Firefox was running into errors.
So, I disabled ssl2 in /etc/apache2/httpd.conf.And now this.So here is my big giant “fuck off” for the Firefox engineers and managers who collectively disabled ssl2 support to encourage server admins to shut off ssl2 support, even as I suspected all cryptography at the practical level is broken.Yeah, I know security is a process, not a product, but if this is the case, then “encourging” admins to use one version of a protocol by disabling one is just the engineering version of “I know better than you so follow my lead.”</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995596</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994980</id>
	<title>Re:This is news? Come on!</title>
	<author>Anonymous</author>
	<datestamp>1257437340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's news in the sense that TLS provides an authentication mechanism specifically designed against this kind of attack.</p></htmltext>
<tokenext>It 's news in the sense that TLS provides an authentication mechanism specifically designed against this kind of attack .</tokentext>
<sentencetext>It's news in the sense that TLS provides an authentication mechanism specifically designed against this kind of attack.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999410</id>
	<title>Re:Its a quantum man in the middle attack</title>
	<author>Anonymous</author>
	<datestamp>1257414300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>OMG! Comment WIN!</p></htmltext>
<tokenext>OMG !
Comment WIN !</tokentext>
<sentencetext>OMG!
Comment WIN!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30004718</id>
	<title>Re:Dissabling SSL re-negotiation?</title>
	<author>Anonymous</author>
	<datestamp>1257515760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Actually, if this is the only way to verify client cert, then SSL renegotiation is vital part of SSL.</p></div><p>Except for the part where client cert is not only non-vital but obscure to the point of not really existing in the real world.</p></div>
	</htmltext>
<tokenext>Actually , if this is the only way to verify client cert , then SSL renegotiation is vital part of SSL.Except for the part where client cert is not only non-vital but obscure to the point of not really existing in the real world .</tokentext>
<sentencetext>Actually, if this is the only way to verify client cert, then SSL renegotiation is vital part of SSL.Except for the part where client cert is not only non-vital but obscure to the point of not really existing in the real world.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995656</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29997586</id>
	<title>Re:Use PGP/GNUPG auth</title>
	<author>Anonymous</author>
	<datestamp>1257450000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You are clearly confused. This is about a flaw in the SSL protocol, not a flaw in X.509/PKI. The only real difference between PGP and X.509/PKI is in key management. Using PGP's <b>extremely expensive, time-consuming, and error-prone</b> key distribution method is the reason PGP is going extinct. Your grandma will never go to a key-signing party.</p><p>Another thing you are confused about: smart cards? What? What do they have to do with anything? Smart cards typically use X.509, not PGP. And in this case, smart cards would make things less secure than, say, passwords.</p><p>It sounds like you took a bunch of random crypto words and strung them together. Are you a bot? If you're not sure, go try some CAPTCHAs and see how you do.</p></htmltext>
<tokenext>You are clearly confused .
This is about a flaw in the SSL protocol , not a flaw in X.509/PKI .
The only real difference between PGP and X.509/PKI is in key management .
Using PGP 's extremely expensive , time-consuming , and error-prone key distribution method is the reason PGP is going extinct .
Your grandma will never go to a key-signing party.Another thing you are confused about : smart cards ?
What ? What do they have to do with anything ?
Smart cards typically use X.509 , not PGP .
And in this case , smart cards would make things less secure than , say , passwords.It sounds like you took a bunch of random crypto words and strung them together .
Are you a bot ?
If you 're not sure , go try some CAPTCHAs and see how you do .</tokentext>
<sentencetext>You are clearly confused.
This is about a flaw in the SSL protocol, not a flaw in X.509/PKI.
The only real difference between PGP and X.509/PKI is in key management.
Using PGP's extremely expensive, time-consuming, and error-prone key distribution method is the reason PGP is going extinct.
Your grandma will never go to a key-signing party.Another thing you are confused about: smart cards?
What? What do they have to do with anything?
Smart cards typically use X.509, not PGP.
And in this case, smart cards would make things less secure than, say, passwords.It sounds like you took a bunch of random crypto words and strung them together.
Are you a bot?
If you're not sure, go try some CAPTCHAs and see how you do.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995414</id>
	<title>re: How does this compromise SSL?</title>
	<author>Anonymous</author>
	<datestamp>1257439500000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>You're right, this isn't a big deal.  What they're describing is essentially a very complicated CSRF.  The upshot is that you can get the user's browser to visit a URL of your choosing, but you can't see the results from that page.  Sound familiar?  That's because all you'd have to do is embed an IMG tag in some HTTP that the user is getting back in order to accomplish the exact same thing -- no fragile renegotiation attack required.</p><p>Thank you security industry for all the hype.</p></htmltext>
<tokenext>You 're right , this is n't a big deal .
What they 're describing is essentially a very complicated CSRF .
The upshot is that you can get the user 's browser to visit a URL of your choosing , but you ca n't see the results from that page .
Sound familiar ?
That 's because all you 'd have to do is embed an IMG tag in some HTTP that the user is getting back in order to accomplish the exact same thing -- no fragile renegotiation attack required.Thank you security industry for all the hype .</tokentext>
<sentencetext>You're right, this isn't a big deal.
What they're describing is essentially a very complicated CSRF.
The upshot is that you can get the user's browser to visit a URL of your choosing, but you can't see the results from that page.
Sound familiar?
That's because all you'd have to do is embed an IMG tag in some HTTP that the user is getting back in order to accomplish the exact same thing -- no fragile renegotiation attack required.Thank you security industry for all the hype.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994902</id>
	<title>Now the terrorists win.</title>
	<author>elucido</author>
	<datestamp>1257436980000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>So now that SSL is pretty much useless, lets assume the terrorists have all of our https and ssl secured credit card numbers. This is on top of the random number generator vulnerability in Windows which most people don't know about.</p></htmltext>
<tokenext>So now that SSL is pretty much useless , lets assume the terrorists have all of our https and ssl secured credit card numbers .
This is on top of the random number generator vulnerability in Windows which most people do n't know about .</tokentext>
<sentencetext>So now that SSL is pretty much useless, lets assume the terrorists have all of our https and ssl secured credit card numbers.
This is on top of the random number generator vulnerability in Windows which most people don't know about.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30002330</id>
	<title>Educated Guesswork link with explanation</title>
	<author>owlstead</author>
	<datestamp>1257432120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think this blog site explains best:</p><p><a href="http://www.educatedguesswork.org/2009/11/understanding\_the\_tls\_renegoti.html" title="educatedguesswork.org">http://www.educatedguesswork.org/2009/11/understanding\_the\_tls\_renegoti.html</a> [educatedguesswork.org]</p></htmltext>
<tokenext>I think this blog site explains best : http : //www.educatedguesswork.org/2009/11/understanding \ _the \ _tls \ _renegoti.html [ educatedguesswork.org ]</tokentext>
<sentencetext>I think this blog site explains best:http://www.educatedguesswork.org/2009/11/understanding\_the\_tls\_renegoti.html [educatedguesswork.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30126622</id>
	<title>Re:We need to invest in Quantum Physics.</title>
	<author>Anonymous</author>
	<datestamp>1258489140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>.<br>.<br>Not even so: since we now have demonstrated <b>how to slow-down, store and modify light on-the-fly</b>, what is <b>abusively called "quantum encryption"</b> (key exchange rather than encryption) is, ahem, <b>no more than marketing</b> (abusively again) repackaged as "science".<br>.<br>.</p></htmltext>
<tokenext>..Not even so : since we now have demonstrated how to slow-down , store and modify light on-the-fly , what is abusively called " quantum encryption " ( key exchange rather than encryption ) is , ahem , no more than marketing ( abusively again ) repackaged as " science " .. .</tokentext>
<sentencetext>..Not even so: since we now have demonstrated how to slow-down, store and modify light on-the-fly, what is abusively called "quantum encryption" (key exchange rather than encryption) is, ahem, no more than marketing (abusively again) repackaged as "science"...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999282</id>
	<title>Re:We need to invest in Quantum Physics.</title>
	<author>OldSoldier</author>
	<datestamp>1257413760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Funny... but as I understand it... one mode of QM communications only allows for 100\% detection of an intercepted communication, not specifically unbreakable ciphers.</p></htmltext>
<tokenext>Funny... but as I understand it... one mode of QM communications only allows for 100 \ % detection of an intercepted communication , not specifically unbreakable ciphers .</tokentext>
<sentencetext>Funny... but as I understand it... one mode of QM communications only allows for 100\% detection of an intercepted communication, not specifically unbreakable ciphers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30010978</id>
	<title>Re:Dissabling SSL re-negotiation?</title>
	<author>EelBait</author>
	<datestamp>1257509220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You can also use renegotiation to derive new keys after X amount of data has passed. This would be for long running connections.</htmltext>
<tokenext>You can also use renegotiation to derive new keys after X amount of data has passed .
This would be for long running connections .</tokentext>
<sentencetext>You can also use renegotiation to derive new keys after X amount of data has passed.
This would be for long running connections.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995656</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998904</id>
	<title>Bypassing Behavioral Filters</title>
	<author>mebrahim</author>
	<datestamp>1257412320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This attack might be used for bypass behavioral network filters used for blocking SSL and TLS connections.</htmltext>
<tokenext>This attack might be used for bypass behavioral network filters used for blocking SSL and TLS connections .</tokentext>
<sentencetext>This attack might be used for bypass behavioral network filters used for blocking SSL and TLS connections.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30000454</id>
	<title>Bob and Alice are too nice</title>
	<author>Anonymous</author>
	<datestamp>1257418860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I think it's high time that Bob and Alice kick the snot out of Marvin and Mallory.  They are known troublemakers, right?</p></htmltext>
<tokenext>I think it 's high time that Bob and Alice kick the snot out of Marvin and Mallory .
They are known troublemakers , right ?</tokentext>
<sentencetext>I think it's high time that Bob and Alice kick the snot out of Marvin and Mallory.
They are known troublemakers, right?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998340</id>
	<title>BruceLee</title>
	<author>Anonymous</author>
	<datestamp>1257452940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This should be a sticky till a fix is found...</p></htmltext>
<tokenext>This should be a sticky till a fix is found.. .</tokentext>
<sentencetext>This should be a sticky till a fix is found...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996906</id>
	<title>Client certificates only? is this important?</title>
	<author>Xylantiel</author>
	<datestamp>1257446700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>The linked articles only discuss authentication via client certificates, which seems pretty rare currently.  How does this vulnerability actually impact the "usual" web commerce usages of SSL, which involves a server certificate?  Also it does not appear that there is any way to force a re-negotiation from outside.  And while re-negotiation appears common for client certs, I would expect it to be somewhat uncommon for server certs except for the initial up-negotiation to a secure connection for TLS.

How important is this for the common-use cases of e-commerce and banking?</htmltext>
<tokenext>The linked articles only discuss authentication via client certificates , which seems pretty rare currently .
How does this vulnerability actually impact the " usual " web commerce usages of SSL , which involves a server certificate ?
Also it does not appear that there is any way to force a re-negotiation from outside .
And while re-negotiation appears common for client certs , I would expect it to be somewhat uncommon for server certs except for the initial up-negotiation to a secure connection for TLS .
How important is this for the common-use cases of e-commerce and banking ?</tokentext>
<sentencetext>The linked articles only discuss authentication via client certificates, which seems pretty rare currently.
How does this vulnerability actually impact the "usual" web commerce usages of SSL, which involves a server certificate?
Also it does not appear that there is any way to force a re-negotiation from outside.
And while re-negotiation appears common for client certs, I would expect it to be somewhat uncommon for server certs except for the initial up-negotiation to a secure connection for TLS.
How important is this for the common-use cases of e-commerce and banking?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995634</id>
	<title>Re:This is news? Come on!</title>
	<author>bluefoxlucid</author>
	<datestamp>1257440700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>The funny part is a lot of people argue, strongly, that self-signed certs aren't any less secure than CA-signed certs.</p><p>
When routing, you have a default gateway IP... no, that's wrong.  You configure such a thing; but what you have is an ARP request finding the MAC of the default gateway (say 10.0.0.1 -&gt; 00:11:22:AA:BB:CC).  Not sending to the local network?  Slap that MAC as the target packet; the router interface gets the packet, reads the IP, says "Hmm that's not my IP address," checks routing table, slaps a new MAC on, and transmits out the appropriate interface.
</p><p>
Well, if I'm at a point where I can eaves drop your packet (self-signed certs protect against eavesdropping), say on your Wifi AP, I can send a spoofed ARP response at you.  Knock off your ARP table entry, replace 10.0.0.1's entry with DD:EE:FF:11:23:45 (mine).  Now you'll send the packet to me; I MitM you; then I slap on 00:11:22:AA:BB:CC as the destination addr of the new packet and it routes as normal.
</p><p>
ALL SSL attacks are MitM attacks.  An eaves drop attack is a lazy MitM that could become an active MitM if he cared.  Mitigation is complex and prone to causing catastrophic breakage; in uncontrolled environments it causes breakage immediately, and in huge controlled environments (corporate LAN) it becomes impossible to reconfigure things on the fly without causing a network storm and outages-- and mistakes require manually walking to each affected machine to undo them.
</p><p>
Note that many people, of course, don't understand SSL.  Many programmers get the implementation wrong (it supplies encryption; ignore all these weird certificate anomaly bullshits, shit's encrypted so it's fine).  Users don't know what they're worrying about.  Notice further that SSL is very well designed, but on like version 4?  (SSL3.0 -&gt; TLS1.0)  The designers are well aware that the issue is hard to understand, and that they've not gotten it quite right yet; they are, however, intelligent, and managing a pretty fucking good job.
</p></htmltext>
<tokenext>The funny part is a lot of people argue , strongly , that self-signed certs are n't any less secure than CA-signed certs .
When routing , you have a default gateway IP... no , that 's wrong .
You configure such a thing ; but what you have is an ARP request finding the MAC of the default gateway ( say 10.0.0.1 - &gt; 00 : 11 : 22 : AA : BB : CC ) .
Not sending to the local network ?
Slap that MAC as the target packet ; the router interface gets the packet , reads the IP , says " Hmm that 's not my IP address , " checks routing table , slaps a new MAC on , and transmits out the appropriate interface .
Well , if I 'm at a point where I can eaves drop your packet ( self-signed certs protect against eavesdropping ) , say on your Wifi AP , I can send a spoofed ARP response at you .
Knock off your ARP table entry , replace 10.0.0.1 's entry with DD : EE : FF : 11 : 23 : 45 ( mine ) .
Now you 'll send the packet to me ; I MitM you ; then I slap on 00 : 11 : 22 : AA : BB : CC as the destination addr of the new packet and it routes as normal .
ALL SSL attacks are MitM attacks .
An eaves drop attack is a lazy MitM that could become an active MitM if he cared .
Mitigation is complex and prone to causing catastrophic breakage ; in uncontrolled environments it causes breakage immediately , and in huge controlled environments ( corporate LAN ) it becomes impossible to reconfigure things on the fly without causing a network storm and outages-- and mistakes require manually walking to each affected machine to undo them .
Note that many people , of course , do n't understand SSL .
Many programmers get the implementation wrong ( it supplies encryption ; ignore all these weird certificate anomaly bullshits , shit 's encrypted so it 's fine ) .
Users do n't know what they 're worrying about .
Notice further that SSL is very well designed , but on like version 4 ?
( SSL3.0 - &gt; TLS1.0 ) The designers are well aware that the issue is hard to understand , and that they 've not gotten it quite right yet ; they are , however , intelligent , and managing a pretty fucking good job .</tokentext>
<sentencetext>The funny part is a lot of people argue, strongly, that self-signed certs aren't any less secure than CA-signed certs.
When routing, you have a default gateway IP... no, that's wrong.
You configure such a thing; but what you have is an ARP request finding the MAC of the default gateway (say 10.0.0.1 -&gt; 00:11:22:AA:BB:CC).
Not sending to the local network?
Slap that MAC as the target packet; the router interface gets the packet, reads the IP, says "Hmm that's not my IP address," checks routing table, slaps a new MAC on, and transmits out the appropriate interface.
Well, if I'm at a point where I can eaves drop your packet (self-signed certs protect against eavesdropping), say on your Wifi AP, I can send a spoofed ARP response at you.
Knock off your ARP table entry, replace 10.0.0.1's entry with DD:EE:FF:11:23:45 (mine).
Now you'll send the packet to me; I MitM you; then I slap on 00:11:22:AA:BB:CC as the destination addr of the new packet and it routes as normal.
ALL SSL attacks are MitM attacks.
An eaves drop attack is a lazy MitM that could become an active MitM if he cared.
Mitigation is complex and prone to causing catastrophic breakage; in uncontrolled environments it causes breakage immediately, and in huge controlled environments (corporate LAN) it becomes impossible to reconfigure things on the fly without causing a network storm and outages-- and mistakes require manually walking to each affected machine to undo them.
Note that many people, of course, don't understand SSL.
Many programmers get the implementation wrong (it supplies encryption; ignore all these weird certificate anomaly bullshits, shit's encrypted so it's fine).
Users don't know what they're worrying about.
Notice further that SSL is very well designed, but on like version 4?
(SSL3.0 -&gt; TLS1.0)  The designers are well aware that the issue is hard to understand, and that they've not gotten it quite right yet; they are, however, intelligent, and managing a pretty fucking good job.
</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948</id>
	<title>Use PGP/GNUPG auth</title>
	<author>elucido</author>
	<datestamp>1257437220000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Maybe its time we stop using SSL and just use GNUPG Auth. Let the user generate their own key and be responsible for their own security, or lets just use smart card readers. We make impossible to secure our machines due to our institutional insecurity. This way we can use it as an excuse to blame terrorists and get the feds involved.</p><p>Why aren't smart cards the norm? Why are we using passwords at all?</p></htmltext>
<tokenext>Maybe its time we stop using SSL and just use GNUPG Auth .
Let the user generate their own key and be responsible for their own security , or lets just use smart card readers .
We make impossible to secure our machines due to our institutional insecurity .
This way we can use it as an excuse to blame terrorists and get the feds involved.Why are n't smart cards the norm ?
Why are we using passwords at all ?</tokentext>
<sentencetext>Maybe its time we stop using SSL and just use GNUPG Auth.
Let the user generate their own key and be responsible for their own security, or lets just use smart card readers.
We make impossible to secure our machines due to our institutional insecurity.
This way we can use it as an excuse to blame terrorists and get the feds involved.Why aren't smart cards the norm?
Why are we using passwords at all?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995242</id>
	<title>ZRTP</title>
	<author>cool\_arrow</author>
	<datestamp>1257438660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've been reading about ZRTP <a href="http://en.wikipedia.org/wiki/ZRTP" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/ZRTP</a> [wikipedia.org]  as it relates to VOIP.  I was wondering if it might have some use for these types of problems.</htmltext>
<tokenext>I 've been reading about ZRTP http : //en.wikipedia.org/wiki/ZRTP [ wikipedia.org ] as it relates to VOIP .
I was wondering if it might have some use for these types of problems .</tokentext>
<sentencetext>I've been reading about ZRTP http://en.wikipedia.org/wiki/ZRTP [wikipedia.org]  as it relates to VOIP.
I was wondering if it might have some use for these types of problems.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30005542</id>
	<title>Re:This is news? Come on!</title>
	<author>jonadab</author>
	<datestamp>1257522360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Attacks based on using the MAC (or anything else related to the data link layer) require the attacker to already be on the local network segment.  An upstream middle-man attacker can't do that stuff, because routers (well, sane routers anyway) don't forward anything below the network layer.<br><br>That doesn't mean such attacks have no relevance at all.  The principle of defense in depth dictates that you *do* want to defend, as much as possible, against attacks originating on the LAN.  But these attacks are not as prevalent or dangerous as ones that can be perpetrated from a remote or upstream system, such as the MITM vulnerability discussed in the article.</htmltext>
<tokenext>Attacks based on using the MAC ( or anything else related to the data link layer ) require the attacker to already be on the local network segment .
An upstream middle-man attacker ca n't do that stuff , because routers ( well , sane routers anyway ) do n't forward anything below the network layer.That does n't mean such attacks have no relevance at all .
The principle of defense in depth dictates that you * do * want to defend , as much as possible , against attacks originating on the LAN .
But these attacks are not as prevalent or dangerous as ones that can be perpetrated from a remote or upstream system , such as the MITM vulnerability discussed in the article .</tokentext>
<sentencetext>Attacks based on using the MAC (or anything else related to the data link layer) require the attacker to already be on the local network segment.
An upstream middle-man attacker can't do that stuff, because routers (well, sane routers anyway) don't forward anything below the network layer.That doesn't mean such attacks have no relevance at all.
The principle of defense in depth dictates that you *do* want to defend, as much as possible, against attacks originating on the LAN.
But these attacks are not as prevalent or dangerous as ones that can be perpetrated from a remote or upstream system, such as the MITM vulnerability discussed in the article.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995634</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996162</id>
	<title>Another one!  Is the Web fundamentally insecure?</title>
	<author>John Hasler</author>
	<datestamp>1257443040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>They just keep coming.  Is the Web fundamentally, unfixably, insecure?</p><p>(That's the Web, not the Net)</p></htmltext>
<tokenext>They just keep coming .
Is the Web fundamentally , unfixably , insecure ?
( That 's the Web , not the Net )</tokentext>
<sentencetext>They just keep coming.
Is the Web fundamentally, unfixably, insecure?
(That's the Web, not the Net)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474</id>
	<title>We need to invest in Quantum Physics.</title>
	<author>Anonymous</author>
	<datestamp>1257434700000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>Only with quantum physics can we actually get a secure data transfer.  Or not or both.</p></htmltext>
<tokenext>Only with quantum physics can we actually get a secure data transfer .
Or not or both .</tokentext>
<sentencetext>Only with quantum physics can we actually get a secure data transfer.
Or not or both.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995268</id>
	<title>Re:Dissabling SSL re-negotiation?</title>
	<author>Anonymous</author>
	<datestamp>1257438720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext>It's more than changing the cipher type, it's also negotiating up from anonymous client to verified client. The second situation occurs ALL THE TIME in web services that require different levels of trust for different content within the same site. So it's not a "seldom-used" feature in the least.</htmltext>
<tokenext>It 's more than changing the cipher type , it 's also negotiating up from anonymous client to verified client .
The second situation occurs ALL THE TIME in web services that require different levels of trust for different content within the same site .
So it 's not a " seldom-used " feature in the least .</tokentext>
<sentencetext>It's more than changing the cipher type, it's also negotiating up from anonymous client to verified client.
The second situation occurs ALL THE TIME in web services that require different levels of trust for different content within the same site.
So it's not a "seldom-used" feature in the least.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30000786</id>
	<title>Re:goodness</title>
	<author>buchner.johannes</author>
	<datestamp>1257420360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It is a complex issue that has no simple/obvious solutions. That's why the usual blah is not occurring.</p><p>It is a huge thing because we used to design web services ala 'Slap SSL onto it, and traffic can not be modified and wiretapped' (assuming the server cert is right).<br>That beauty of SSL, just to add a layer that will take care of it all, is gone<nobr> <wbr></nobr>... as the <a href="http://extendedsubset.com/Renegotiating\_TLS.pdf" title="extendedsubset.com">pdf</a> [extendedsubset.com] states, even if no client certs are involved, the current protocols and all client/server software is vulnerable, and at least some of the attack scenarios are not uncommon.</p><p>all in all -&gt;<nobr> <wbr></nobr>:-(</p></htmltext>
<tokenext>It is a complex issue that has no simple/obvious solutions .
That 's why the usual blah is not occurring.It is a huge thing because we used to design web services ala 'Slap SSL onto it , and traffic can not be modified and wiretapped ' ( assuming the server cert is right ) .That beauty of SSL , just to add a layer that will take care of it all , is gone ... as the pdf [ extendedsubset.com ] states , even if no client certs are involved , the current protocols and all client/server software is vulnerable , and at least some of the attack scenarios are not uncommon.all in all - &gt; : - (</tokentext>
<sentencetext>It is a complex issue that has no simple/obvious solutions.
That's why the usual blah is not occurring.It is a huge thing because we used to design web services ala 'Slap SSL onto it, and traffic can not be modified and wiretapped' (assuming the server cert is right).That beauty of SSL, just to add a layer that will take care of it all, is gone ... as the pdf [extendedsubset.com] states, even if no client certs are involved, the current protocols and all client/server software is vulnerable, and at least some of the attack scenarios are not uncommon.all in all -&gt; :-(</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995916</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712</id>
	<title>This is news?  Come on!</title>
	<author>Anonymous</author>
	<datestamp>1257435960000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>Anyone who knows anything about TLS/SSL knows that MitM attacks are always the biggest risk.</p><p>Heck, appliances like the IronPort devices use exactly that to inspect user traffic.</p></htmltext>
<tokenext>Anyone who knows anything about TLS/SSL knows that MitM attacks are always the biggest risk.Heck , appliances like the IronPort devices use exactly that to inspect user traffic .</tokentext>
<sentencetext>Anyone who knows anything about TLS/SSL knows that MitM attacks are always the biggest risk.Heck, appliances like the IronPort devices use exactly that to inspect user traffic.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994480</id>
	<title>oh joy</title>
	<author>Anonymous</author>
	<datestamp>1257434760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>More cyber terror<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>More cyber terror : )</tokentext>
<sentencetext>More cyber terror :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995656</id>
	<title>Re:Dissabling SSL re-negotiation?</title>
	<author>Anonymous</author>
	<datestamp>1257440760000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>"But let me ask this : who would ever require SSL renegotiation in practice?"</p><p>from,</p><p>http://h71000.www7.hp.com/doc/83final/ba554\_90007/ch04s03.html</p><p>SSL renegotiation is useful in the following situations, once you have established an ordinary SSL session:</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; *     When you require client authentication<br>
&nbsp; &nbsp; &nbsp; &nbsp; *     When you are using a different set of encryption and decryption keys<br>
&nbsp; &nbsp; &nbsp; &nbsp; *    When you are using a different set of encryption and hashing algorithms</p><p>The last two are kind of useless in practice. The first one is very useful to authenticate the client. Actually, if this is the only way to verify client cert, then SSL renegotiation is vital part of SSL.</p></htmltext>
<tokenext>" But let me ask this : who would ever require SSL renegotiation in practice ?
" from,http : //h71000.www7.hp.com/doc/83final/ba554 \ _90007/ch04s03.htmlSSL renegotiation is useful in the following situations , once you have established an ordinary SSL session :         * When you require client authentication         * When you are using a different set of encryption and decryption keys         * When you are using a different set of encryption and hashing algorithmsThe last two are kind of useless in practice .
The first one is very useful to authenticate the client .
Actually , if this is the only way to verify client cert , then SSL renegotiation is vital part of SSL .</tokentext>
<sentencetext>"But let me ask this : who would ever require SSL renegotiation in practice?
"from,http://h71000.www7.hp.com/doc/83final/ba554\_90007/ch04s03.htmlSSL renegotiation is useful in the following situations, once you have established an ordinary SSL session:
        *     When you require client authentication
        *     When you are using a different set of encryption and decryption keys
        *    When you are using a different set of encryption and hashing algorithmsThe last two are kind of useless in practice.
The first one is very useful to authenticate the client.
Actually, if this is the only way to verify client cert, then SSL renegotiation is vital part of SSL.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30005820</id>
	<title>Re:This is news? Come on!</title>
	<author>jonadab</author>
	<datestamp>1257524100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&gt; The funny part is a lot of people argue, strongly, that<br>&gt; self-signed certs aren't any less secure than CA-signed certs.<br><br>It's not significantly harder for the bad guys to get a CA-signed cert than it is for the good guys.  Ipso facto, CA signing does not add any significant security.  It only *seems* to do so, if you ignore the question of who can get a certificate.<br><br>What does add significant security is if the client software flashes big red glowing alarm bells if the certificate changes compared to last time.  OpenSSH does this.  Mail clients don't and definitely should.  Web browsers don't and perhaps should (although there would need to be some provision for legitimately transitioning to a new certificate without setting off said alarms, which in order to be secure would require nontrivial design changes to the way https certs are handled on the server as well as the client).<br><br>The lesson here is that application of encryption often results in an overall system that is much weaker than you might think based on the strength of the encryption itself.  When you are looking at designing a secure system, selecting strong encryption can be useful, but only if you apply it in a secure way.  It is my considered opinion that the use of SSL on the web adds very little security -- not due to any inherent flaw in the design of SSL, but due to the way in which https uses it.</htmltext>
<tokenext>&gt; The funny part is a lot of people argue , strongly , that &gt; self-signed certs are n't any less secure than CA-signed certs.It 's not significantly harder for the bad guys to get a CA-signed cert than it is for the good guys .
Ipso facto , CA signing does not add any significant security .
It only * seems * to do so , if you ignore the question of who can get a certificate.What does add significant security is if the client software flashes big red glowing alarm bells if the certificate changes compared to last time .
OpenSSH does this .
Mail clients do n't and definitely should .
Web browsers do n't and perhaps should ( although there would need to be some provision for legitimately transitioning to a new certificate without setting off said alarms , which in order to be secure would require nontrivial design changes to the way https certs are handled on the server as well as the client ) .The lesson here is that application of encryption often results in an overall system that is much weaker than you might think based on the strength of the encryption itself .
When you are looking at designing a secure system , selecting strong encryption can be useful , but only if you apply it in a secure way .
It is my considered opinion that the use of SSL on the web adds very little security -- not due to any inherent flaw in the design of SSL , but due to the way in which https uses it .</tokentext>
<sentencetext>&gt; The funny part is a lot of people argue, strongly, that&gt; self-signed certs aren't any less secure than CA-signed certs.It's not significantly harder for the bad guys to get a CA-signed cert than it is for the good guys.
Ipso facto, CA signing does not add any significant security.
It only *seems* to do so, if you ignore the question of who can get a certificate.What does add significant security is if the client software flashes big red glowing alarm bells if the certificate changes compared to last time.
OpenSSH does this.
Mail clients don't and definitely should.
Web browsers don't and perhaps should (although there would need to be some provision for legitimately transitioning to a new certificate without setting off said alarms, which in order to be secure would require nontrivial design changes to the way https certs are handled on the server as well as the client).The lesson here is that application of encryption often results in an overall system that is much weaker than you might think based on the strength of the encryption itself.
When you are looking at designing a secure system, selecting strong encryption can be useful, but only if you apply it in a secure way.
It is my considered opinion that the use of SSL on the web adds very little security -- not due to any inherent flaw in the design of SSL, but due to the way in which https uses it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995634</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30007872</id>
	<title>What password is that?</title>
	<author>elucido</author>
	<datestamp>1257536940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What password of random characters can you actually store in your mind and how many? If anyone actually has access to your machine then all your passwords are useless. Assuming your passwords cannot be cracked is silly. The smartcard removes the need to enter a password into a machine, this prevents remote users from using a software keylogger.</p><p>Passwords are why everyone is so easy to hack today. Nobody picks a secure password because those passwords cannot be remembered, and the passwords which can be remembered can usually be cracked. Smartcards are as secure as credit cards, passwords aren't very secure because you have to type them into a computer and thats writing it down for everyone to see.</p></htmltext>
<tokenext>What password of random characters can you actually store in your mind and how many ?
If anyone actually has access to your machine then all your passwords are useless .
Assuming your passwords can not be cracked is silly .
The smartcard removes the need to enter a password into a machine , this prevents remote users from using a software keylogger.Passwords are why everyone is so easy to hack today .
Nobody picks a secure password because those passwords can not be remembered , and the passwords which can be remembered can usually be cracked .
Smartcards are as secure as credit cards , passwords are n't very secure because you have to type them into a computer and thats writing it down for everyone to see .</tokentext>
<sentencetext>What password of random characters can you actually store in your mind and how many?
If anyone actually has access to your machine then all your passwords are useless.
Assuming your passwords cannot be cracked is silly.
The smartcard removes the need to enter a password into a machine, this prevents remote users from using a software keylogger.Passwords are why everyone is so easy to hack today.
Nobody picks a secure password because those passwords cannot be remembered, and the passwords which can be remembered can usually be cracked.
Smartcards are as secure as credit cards, passwords aren't very secure because you have to type them into a computer and thats writing it down for everyone to see.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266</id>
	<title>How does this compromise SSL?</title>
	<author>Dan Ost</author>
	<datestamp>1257438720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I read the first article (second won't load...probably hosed by the<nobr> <wbr></nobr>/. effect) and it's still not clear to me why this is a big deal. Can someone explain how injecting prefixes compromises my secure datastream?</p></htmltext>
<tokenext>I read the first article ( second wo n't load...probably hosed by the / .
effect ) and it 's still not clear to me why this is a big deal .
Can someone explain how injecting prefixes compromises my secure datastream ?</tokentext>
<sentencetext>I read the first article (second won't load...probably hosed by the /.
effect) and it's still not clear to me why this is a big deal.
Can someone explain how injecting prefixes compromises my secure datastream?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30124810</id>
	<title>Re:How does this compromise SSL?</title>
	<author>Lehk228</author>
	<datestamp>1258383060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"prefix" contains an HTML page that looks like your bank page, and asks for your bank password, and your browser "confirms" that you really are at your bank's website.</htmltext>
<tokenext>" prefix " contains an HTML page that looks like your bank page , and asks for your bank password , and your browser " confirms " that you really are at your bank 's website .</tokentext>
<sentencetext>"prefix" contains an HTML page that looks like your bank page, and asks for your bank password, and your browser "confirms" that you really are at your bank's website.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995888</id>
	<title>SSL is broken and the world has ended?</title>
	<author>Anonymous</author>
	<datestamp>1257441780000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Most people don't use client authentication and there is typically little reason to ever configure a server to change ciphers or otherwise initiate renegotiation.</p><p>If the server does not initiate renegotiation the MITM attack does not apply! This is why there is such focus on client authentication because this is realistically the only real world case where renegotiation makes any logical sense.  Sure you can dream up other scenarios where the server forces you to use a higher strenght cipher to access specific content but realistically this is nonsensical.  Operators make a global stand WRT cipher strength at the site level.</p><p>TLS was written back in the day when we had low and ultra low export quality ciphers and more international encryption issues than exist today.  All sane operators have since disabled these and all browsers that matter have reasonably high strength ciphers available to them mitigating any reason to renegotiate.</p><p>Yes it should be fixed.<br>No its not the end of the world.</p></htmltext>
<tokenext>Most people do n't use client authentication and there is typically little reason to ever configure a server to change ciphers or otherwise initiate renegotiation.If the server does not initiate renegotiation the MITM attack does not apply !
This is why there is such focus on client authentication because this is realistically the only real world case where renegotiation makes any logical sense .
Sure you can dream up other scenarios where the server forces you to use a higher strenght cipher to access specific content but realistically this is nonsensical .
Operators make a global stand WRT cipher strength at the site level.TLS was written back in the day when we had low and ultra low export quality ciphers and more international encryption issues than exist today .
All sane operators have since disabled these and all browsers that matter have reasonably high strength ciphers available to them mitigating any reason to renegotiate.Yes it should be fixed.No its not the end of the world .</tokentext>
<sentencetext>Most people don't use client authentication and there is typically little reason to ever configure a server to change ciphers or otherwise initiate renegotiation.If the server does not initiate renegotiation the MITM attack does not apply!
This is why there is such focus on client authentication because this is realistically the only real world case where renegotiation makes any logical sense.
Sure you can dream up other scenarios where the server forces you to use a higher strenght cipher to access specific content but realistically this is nonsensical.
Operators make a global stand WRT cipher strength at the site level.TLS was written back in the day when we had low and ultra low export quality ciphers and more international encryption issues than exist today.
All sane operators have since disabled these and all browsers that matter have reasonably high strength ciphers available to them mitigating any reason to renegotiate.Yes it should be fixed.No its not the end of the world.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30010038</id>
	<title>Re:Use PGP/GNUPG auth</title>
	<author>bratgitarre</author>
	<datestamp>1257503280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In TSL's RSA mode the user is actually generating the session key, and in the Diffie-Hellman modes s/he generates at least half of it.</htmltext>
<tokenext>In TSL 's RSA mode the user is actually generating the session key , and in the Diffie-Hellman modes s/he generates at least half of it .</tokentext>
<sentencetext>In TSL's RSA mode the user is actually generating the session key, and in the Diffie-Hellman modes s/he generates at least half of it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30011980</id>
	<title>Re:Dissabling SSL re-negotiation?</title>
	<author>Anonymous</author>
	<datestamp>1257520200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Well, changing the keys is also frequent and in fact is a good practice to do while sending a large amounts of data.</p></htmltext>
<tokenext>Well , changing the keys is also frequent and in fact is a good practice to do while sending a large amounts of data .</tokentext>
<sentencetext>Well, changing the keys is also frequent and in fact is a good practice to do while sending a large amounts of data.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995656</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996532</id>
	<title>Re:Use PGP/GNUPG auth</title>
	<author>schon</author>
	<datestamp>1257444840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>Let the user [...] be responsible for their own security</p></div><p>Yes, because as all of the botnets have shown, that works <i>so</i> well in practice.</p></div>
	</htmltext>
<tokenext>Let the user [ ... ] be responsible for their own securityYes , because as all of the botnets have shown , that works so well in practice .</tokentext>
<sentencetext>Let the user [...] be responsible for their own securityYes, because as all of the botnets have shown, that works so well in practice.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996546</id>
	<title>Re:Use PGP/GNUPG auth</title>
	<author>Anonymous</author>
	<datestamp>1257444900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Note that using a smartcard in this case would not help you.  Smartcards provide a protected place to put your keys and do "private" stuff (like signing) but all the same protocols are usually used on top of that (including SSL/TLS).</p><p>I doubt GNUPG Auth is without fault itself.  It's really hard to do security and crypto stuff correctly.  Really, really hard as even the best mathematicians, theorists and developers in the world get caught out all the time.</p></htmltext>
<tokenext>Note that using a smartcard in this case would not help you .
Smartcards provide a protected place to put your keys and do " private " stuff ( like signing ) but all the same protocols are usually used on top of that ( including SSL/TLS ) .I doubt GNUPG Auth is without fault itself .
It 's really hard to do security and crypto stuff correctly .
Really , really hard as even the best mathematicians , theorists and developers in the world get caught out all the time .</tokentext>
<sentencetext>Note that using a smartcard in this case would not help you.
Smartcards provide a protected place to put your keys and do "private" stuff (like signing) but all the same protocols are usually used on top of that (including SSL/TLS).I doubt GNUPG Auth is without fault itself.
It's really hard to do security and crypto stuff correctly.
Really, really hard as even the best mathematicians, theorists and developers in the world get caught out all the time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995774</id>
	<title>Re:This is news? Come on!</title>
	<author>ArsonSmith</author>
	<datestamp>1257441300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The difference here is that the client thinks it has a "verified" secure connection to the named host.  Other SSL MiM attacks work by providing a fake certificate.</p></htmltext>
<tokenext>The difference here is that the client thinks it has a " verified " secure connection to the named host .
Other SSL MiM attacks work by providing a fake certificate .</tokentext>
<sentencetext>The difference here is that the client thinks it has a "verified" secure connection to the named host.
Other SSL MiM attacks work by providing a fake certificate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994542</id>
	<title>We need</title>
	<author>Anonymous</author>
	<datestamp>1257435120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>We need someone who can eliminate these middle men! Where's Tom Shane on this??</htmltext>
<tokenext>We need someone who can eliminate these middle men !
Where 's Tom Shane on this ?
?</tokentext>
<sentencetext>We need someone who can eliminate these middle men!
Where's Tom Shane on this?
?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996352</id>
	<title>Re:How does this compromise SSL?</title>
	<author>WhiplashII</author>
	<datestamp>1257443940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>Let's say you have a web service exposed to your clients that processes orders.  The error allows an arbitrary amount of data to be injected into the beginning of the client request - so the "bad guy" takes your request:<br><br>
&nbsp; &nbsp; &nbsp; POST<nobr> <wbr></nobr>/OrderTheFrogs HTTP/1.0<br>
&nbsp; &nbsp; &nbsp; content-length: 20<br><br>
&nbsp; &nbsp; &nbsp; &lt; xml &gt;&lt; orderafrog number=1/ &gt;&lt; address &gt; my address &lt;<nobr> <wbr></nobr>/address &gt; &lt;<nobr> <wbr></nobr>/xml &gt;<br><br>And converts it to:<br><br>
&nbsp; &nbsp; &nbsp; POST<nobr> <wbr></nobr>/OrderTheFrogs HTTP/1.0<br>
&nbsp; &nbsp; &nbsp; content-length: 24<br><br>
&nbsp; &nbsp; &nbsp; &lt; xml &gt;&lt; orderafrog number=100/ &gt;&lt; address &gt; evil address &lt;<nobr> <wbr></nobr>/address &gt; &lt;<nobr> <wbr></nobr>/xml &gt;<br><br>
&nbsp; &nbsp; &nbsp; POST<nobr> <wbr></nobr>/OrderTheFrogs HTTP/1.0<br>
&nbsp; &nbsp; &nbsp; content-length: 20<br><br>
&nbsp; &nbsp; &nbsp; &lt; xml &gt;&lt; orderafrog number=1/ &gt;&lt; address &gt; my address &lt;<nobr> <wbr></nobr>/address &gt; &lt;<nobr> <wbr></nobr>/xml &gt;<br><br>by using this attack to insert the evil request before yours.  Now 100 items are sent to the evil address, and presumably are billed to you!</htmltext>
<tokenext>Let 's say you have a web service exposed to your clients that processes orders .
The error allows an arbitrary amount of data to be injected into the beginning of the client request - so the " bad guy " takes your request :       POST /OrderTheFrogs HTTP/1.0       content-length : 20       my address /address &gt; /xml &gt; And converts it to :       POST /OrderTheFrogs HTTP/1.0       content-length : 24       evil address /address &gt; /xml &gt;       POST /OrderTheFrogs HTTP/1.0       content-length : 20       my address /address &gt; /xml &gt; by using this attack to insert the evil request before yours .
Now 100 items are sent to the evil address , and presumably are billed to you !</tokentext>
<sentencetext>Let's say you have a web service exposed to your clients that processes orders.
The error allows an arbitrary amount of data to be injected into the beginning of the client request - so the "bad guy" takes your request:
      POST /OrderTheFrogs HTTP/1.0
      content-length: 20
       my address  /address &gt;  /xml &gt;And converts it to:
      POST /OrderTheFrogs HTTP/1.0
      content-length: 24
       evil address  /address &gt;  /xml &gt;
      POST /OrderTheFrogs HTTP/1.0
      content-length: 20
       my address  /address &gt;  /xml &gt;by using this attack to insert the evil request before yours.
Now 100 items are sent to the evil address, and presumably are billed to you!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995862</id>
	<title>Re:Dissabling SSL re-negotiation?</title>
	<author>Anonymous</author>
	<datestamp>1257441660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>But let me ask this : who would ever require SSL renegotiation in practice?</p><p>I mean seriously -- changing the cipher in the middle of an SSL session??</p><p>
&nbsp; -- no mainstream scenario would ever do this.</p><p>A question comes to mind why renegotiation was ever supported in the first place.</p></div><p>If I remember correctly, SSL renegotation was (and probably ever is) used for upgrading cryptographic strength when transaction are done with financial institutions. Encryption is/was subject to some legal restrictions in some countries, wich ones have/had some exceptions (obviously for exchanging financial or other sensible data).</p></div>
	</htmltext>
<tokenext>But let me ask this : who would ever require SSL renegotiation in practice ? I mean seriously -- changing the cipher in the middle of an SSL session ? ?
  -- no mainstream scenario would ever do this.A question comes to mind why renegotiation was ever supported in the first place.If I remember correctly , SSL renegotation was ( and probably ever is ) used for upgrading cryptographic strength when transaction are done with financial institutions .
Encryption is/was subject to some legal restrictions in some countries , wich ones have/had some exceptions ( obviously for exchanging financial or other sensible data ) .</tokentext>
<sentencetext>But let me ask this : who would ever require SSL renegotiation in practice?I mean seriously -- changing the cipher in the middle of an SSL session??
  -- no mainstream scenario would ever do this.A question comes to mind why renegotiation was ever supported in the first place.If I remember correctly, SSL renegotation was (and probably ever is) used for upgrading cryptographic strength when transaction are done with financial institutions.
Encryption is/was subject to some legal restrictions in some countries, wich ones have/had some exceptions (obviously for exchanging financial or other sensible data).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996878</id>
	<title>Re:Dissabling SSL re-negotiation?</title>
	<author>cananian</author>
	<datestamp>1257446580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>RC4? Really?!  Dude, that's totally broken -- see  <a href="http://en.wikipedia.org/wiki/RC4#Security" title="wikipedia.org">http://en.wikipedia.org/wiki/RC4#Security</a> [wikipedia.org] and especially  <a href="http://en.wikipedia.org/wiki/Fluhrer,\_Mantin,\_and\_Shamir\_attack" title="wikipedia.org">http://en.wikipedia.org/wiki/Fluhrer,\_Mantin,\_and\_Shamir\_attack</a> [wikipedia.org] .  Ron Rivest makes lots of good stuff, but all of "Ron's Codes" have been broken.  (Except maybe RC6, but the AES committee determined that Rijndael was better than it.)

Classic example of amateur cryptography actually resulting in a system that is *weaker* than the alternative.  Le sigh.</htmltext>
<tokenext>RC4 ?
Really ? ! Dude , that 's totally broken -- see http : //en.wikipedia.org/wiki/RC4 # Security [ wikipedia.org ] and especially http : //en.wikipedia.org/wiki/Fluhrer , \ _Mantin , \ _and \ _Shamir \ _attack [ wikipedia.org ] .
Ron Rivest makes lots of good stuff , but all of " Ron 's Codes " have been broken .
( Except maybe RC6 , but the AES committee determined that Rijndael was better than it .
) Classic example of amateur cryptography actually resulting in a system that is * weaker * than the alternative .
Le sigh .</tokentext>
<sentencetext>RC4?
Really?!  Dude, that's totally broken -- see  http://en.wikipedia.org/wiki/RC4#Security [wikipedia.org] and especially  http://en.wikipedia.org/wiki/Fluhrer,\_Mantin,\_and\_Shamir\_attack [wikipedia.org] .
Ron Rivest makes lots of good stuff, but all of "Ron's Codes" have been broken.
(Except maybe RC6, but the AES committee determined that Rijndael was better than it.
)

Classic example of amateur cryptography actually resulting in a system that is *weaker* than the alternative.
Le sigh.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994580</id>
	<title>This vulnerability is brought to you...</title>
	<author>Anonymous</author>
	<datestamp>1257435300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>...by the CIA/NSA/[insert your favorite spying agency]</p></htmltext>
<tokenext>...by the CIA/NSA/ [ insert your favorite spying agency ]</tokentext>
<sentencetext>...by the CIA/NSA/[insert your favorite spying agency]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30011574</id>
	<title>Anonymous Coward.</title>
	<author>Anonymous</author>
	<datestamp>1257514920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>For well structured secure apps, a one-way hash token check would prevent this problem.   That is, if session hash-check fails, drop connection from client end.  Granted this won't work for pure ssl html apps.   Maybe session hashing should be built into the protocol???</p></htmltext>
<tokenext>For well structured secure apps , a one-way hash token check would prevent this problem .
That is , if session hash-check fails , drop connection from client end .
Granted this wo n't work for pure ssl html apps .
Maybe session hashing should be built into the protocol ? ?
?</tokentext>
<sentencetext>For well structured secure apps, a one-way hash token check would prevent this problem.
That is, if session hash-check fails, drop connection from client end.
Granted this won't work for pure ssl html apps.
Maybe session hashing should be built into the protocol??
?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995152</id>
	<title>Another way of MITM on NSS SSL/TLS implementation</title>
	<author>Anonymous</author>
	<datestamp>1257438240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf<br>http://www.thoughtcrime.org/papers/ocsp-attack.pdf</p><p>http://www.thoughtcrime.org/software/sslsniff/</p></htmltext>
<tokenext>http : //www.thoughtcrime.org/papers/null-prefix-attacks.pdfhttp : //www.thoughtcrime.org/papers/ocsp-attack.pdfhttp : //www.thoughtcrime.org/software/sslsniff/</tokentext>
<sentencetext>http://www.thoughtcrime.org/papers/null-prefix-attacks.pdfhttp://www.thoughtcrime.org/papers/ocsp-attack.pdfhttp://www.thoughtcrime.org/software/sslsniff/</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994750</id>
	<title>Its a quantum man in the middle attack</title>
	<author>Anonymous</author>
	<datestamp>1257436080000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>Its the same man in all 3 places.</p></htmltext>
<tokenext>Its the same man in all 3 places .</tokentext>
<sentencetext>Its the same man in all 3 places.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998944</id>
	<title>Re:Use PGP/GNUPG auth</title>
	<author>Hurricane78</author>
	<datestamp>1257412500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Because you haven't understood security at all!</p><p>Smartcards <em>still</em> need a password, or they are no more secure than a fingerprint (cut off the finger) or a credit card (buy something immediately after stealing it).</p><p>Passwords alone of course a also not great. But at least nobody can steal a password that is stored only in your mind.</p></htmltext>
<tokenext>Because you have n't understood security at all ! Smartcards still need a password , or they are no more secure than a fingerprint ( cut off the finger ) or a credit card ( buy something immediately after stealing it ) .Passwords alone of course a also not great .
But at least nobody can steal a password that is stored only in your mind .</tokentext>
<sentencetext>Because you haven't understood security at all!Smartcards still need a password, or they are no more secure than a fingerprint (cut off the finger) or a credit card (buy something immediately after stealing it).Passwords alone of course a also not great.
But at least nobody can steal a password that is stored only in your mind.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994676</id>
	<title>Re:We need to invest in Quantum Physics.</title>
	<author>Anonymous</author>
	<datestamp>1257435720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I LOLed.  +1</p></htmltext>
<tokenext>I LOLed .
+ 1</tokentext>
<sentencetext>I LOLed.
+1</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995894</id>
	<title>Re:Dissabling SSL re-negotiation?</title>
	<author>Anonymous</author>
	<datestamp>1257441780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>But let me ask this : who would ever require SSL renegotiation in practice?</p><p>

I mean seriously -- changing the cipher in the middle of an SSL session??
  -- no mainstream scenario would ever do this.</p><p>

A question comes to mind why renegotiation was ever supported in the first place.</p></div><p>Client certificates need this.</p></div>
	</htmltext>
<tokenext>But let me ask this : who would ever require SSL renegotiation in practice ?
I mean seriously -- changing the cipher in the middle of an SSL session ? ?
-- no mainstream scenario would ever do this .
A question comes to mind why renegotiation was ever supported in the first place.Client certificates need this .</tokentext>
<sentencetext>But let me ask this : who would ever require SSL renegotiation in practice?
I mean seriously -- changing the cipher in the middle of an SSL session??
-- no mainstream scenario would ever do this.
A question comes to mind why renegotiation was ever supported in the first place.Client certificates need this.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996864</id>
	<title>Re:Use PGP/GNUPG auth</title>
	<author>the\_womble</author>
	<datestamp>1257446460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That will not happen, because there is no money in it. Tunnelling over ssh has the same problem.</p></htmltext>
<tokenext>That will not happen , because there is no money in it .
Tunnelling over ssh has the same problem .</tokentext>
<sentencetext>That will not happen, because there is no money in it.
Tunnelling over ssh has the same problem.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999192</id>
	<title>Re:Its a quantum man in the middle attack</title>
	<author>jonaskoelker</author>
	<datestamp>1257413460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Just like DRM, then?<nobr> <wbr></nobr>;-)</p></htmltext>
<tokenext>Just like DRM , then ?
; - )</tokentext>
<sentencetext>Just like DRM, then?
;-)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30000382</id>
	<title>Re:How does this compromise SSL?</title>
	<author>CompMD</author>
	<datestamp>1257418500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>As Admiral Kirk taught us when facing Khan, when you inject prefixes over a datastream like a comm channel to another Starfleet vessel, you can take command of their consoles and lower their shields.</p></htmltext>
<tokenext>As Admiral Kirk taught us when facing Khan , when you inject prefixes over a datastream like a comm channel to another Starfleet vessel , you can take command of their consoles and lower their shields .</tokentext>
<sentencetext>As Admiral Kirk taught us when facing Khan, when you inject prefixes over a datastream like a comm channel to another Starfleet vessel, you can take command of their consoles and lower their shields.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938</id>
	<title>Dissabling SSL re-negotiation?</title>
	<author>AbbeyRoad</author>
	<datestamp>1257437160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Am OpenSSL patch (http://www.links.org/files/no-renegotiation-2.patch) disables SSL<br>renegotiation, closing the security hole.</p><p>But let me ask this : who would ever require SSL renegotiation in practice?</p><p>I mean seriously -- changing the cipher in the middle of an SSL session??<br>
&nbsp; -- no mainstream scenario would ever do this.</p><p>A question comes to mind why renegotiation was ever supported in the first place.</p><p>The next question is what OTHER seldom-used "features" are supported by<br>most SSL implementations that are just supported so that the implementation<br>can claim full RFC compliance, but are never actually used by real web sites.</p><p>My own SSL builds disable everything except RC4-*-RSA</p></htmltext>
<tokenext>Am OpenSSL patch ( http : //www.links.org/files/no-renegotiation-2.patch ) disables SSLrenegotiation , closing the security hole.But let me ask this : who would ever require SSL renegotiation in practice ? I mean seriously -- changing the cipher in the middle of an SSL session ? ?
  -- no mainstream scenario would ever do this.A question comes to mind why renegotiation was ever supported in the first place.The next question is what OTHER seldom-used " features " are supported bymost SSL implementations that are just supported so that the implementationcan claim full RFC compliance , but are never actually used by real web sites.My own SSL builds disable everything except RC4- * -RSA</tokentext>
<sentencetext>Am OpenSSL patch (http://www.links.org/files/no-renegotiation-2.patch) disables SSLrenegotiation, closing the security hole.But let me ask this : who would ever require SSL renegotiation in practice?I mean seriously -- changing the cipher in the middle of an SSL session??
  -- no mainstream scenario would ever do this.A question comes to mind why renegotiation was ever supported in the first place.The next question is what OTHER seldom-used "features" are supported bymost SSL implementations that are just supported so that the implementationcan claim full RFC compliance, but are never actually used by real web sites.My own SSL builds disable everything except RC4-*-RSA</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998110</id>
	<title>Clever</title>
	<author>Anonymous</author>
	<datestamp>1257452100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Extremely clever, I will say that. But doesn't this require that the client just plainly ignore that it is getting data from the server that it never requested? Seems somewhat odd that a client would do that, but not completely unexpected anymore.</p></htmltext>
<tokenext>Extremely clever , I will say that .
But does n't this require that the client just plainly ignore that it is getting data from the server that it never requested ?
Seems somewhat odd that a client would do that , but not completely unexpected anymore .</tokentext>
<sentencetext>Extremely clever, I will say that.
But doesn't this require that the client just plainly ignore that it is getting data from the server that it never requested?
Seems somewhat odd that a client would do that, but not completely unexpected anymore.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995916</id>
	<title>goodness</title>
	<author>MagicM</author>
	<datestamp>1257441900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Phew!  2 hours later and only 51 comments.  This must not be a big deal.</p><p>Y'all had me worried there...</p></htmltext>
<tokenext>Phew !
2 hours later and only 51 comments .
This must not be a big deal.Y'all had me worried there.. .</tokentext>
<sentencetext>Phew!
2 hours later and only 51 comments.
This must not be a big deal.Y'all had me worried there...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995380</id>
	<title>Re:How does this compromise SSL?</title>
	<author>Anonymous</author>
	<datestamp>1257439320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Let's say you are paying your mortgage, putting in your bank account information for a transfer.  An attacker could inject additional HTML (Javascript, etc.) that sends your response to the attacker's server instead of the mortgage company's server, compromising your account info.</p><p>Or a simpler attack would be the bank's online banking login page: again, inject additional HTML to the bank's response, and now you submit your username/password to the attacker's server.</p></htmltext>
<tokenext>Let 's say you are paying your mortgage , putting in your bank account information for a transfer .
An attacker could inject additional HTML ( Javascript , etc .
) that sends your response to the attacker 's server instead of the mortgage company 's server , compromising your account info.Or a simpler attack would be the bank 's online banking login page : again , inject additional HTML to the bank 's response , and now you submit your username/password to the attacker 's server .</tokentext>
<sentencetext>Let's say you are paying your mortgage, putting in your bank account information for a transfer.
An attacker could inject additional HTML (Javascript, etc.
) that sends your response to the attacker's server instead of the mortgage company's server, compromising your account info.Or a simpler attack would be the bank's online banking login page: again, inject additional HTML to the bank's response, and now you submit your username/password to the attacker's server.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30007872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998944
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29997586
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30000786
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995916
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30011980
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995656
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994980
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999802
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995190
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30126622
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995774
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996310
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996352
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995546
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996028
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995596
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996532
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999410
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996546
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30010038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995862
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995596
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30010978
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995656
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999192
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996126
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995596
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999282
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30004718
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995656
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30005542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995634
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995414
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30005820
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995634
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998156
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995634
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995268
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996878
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996864
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994676
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30124810
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_05_144252_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30000382
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994474
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994750
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999410
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999192
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994676
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999282
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30126622
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998108
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994938
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995268
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995656
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30011980
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30010978
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30004718
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995894
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995862
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996878
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995190
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29999802
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994542
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995916
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30000786
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994480
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998110
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994486
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995596
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996126
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995900
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996028
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994712
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994980
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995634
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30005820
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998156
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30005542
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995774
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995266
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995380
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30124810
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995414
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996352
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996310
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29995546
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30000382
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996906
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994580
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_05_144252.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29994948
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29997586
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29998944
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30007872
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996532
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.30010038
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996546
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_05_144252.29996864
</commentlist>
</conversation>
