<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_03_26_1334254</id>
	<title>Government Could Forge SSL Certificates</title>
	<author>Soulskill</author>
	<datestamp>1269612840000</datestamp>
	<htmltext>FutureDomain writes <i>"Is SSL becoming pointless? Researchers are <a href="http://www.betanews.com/article/Has-SSL-become-pointless-Researchers-suspect-statesponsored-CA-forgery/1269551694">poking holes in the chain of trust for SSL certificates</a> which protect sensitive data. According to these hypothesized attacks, governments could <a href="http://www.wired.com/threatlevel/2010/03/packet-forensics/">compel certificate authorities to give them phony certificates</a> that are signed by the CA, which are then used to perform man in the middle attacks. They point out that Verisign already makes large sums of money by facilitating the disclosure of US consumers' private data to US government law enforcement. The researchers are <a href="http://files.cloudprivacy.net/ssl-mitm.pdf">developing a Firefox plugin</a> (PDF) that checks past certificates and warns of anomalies in the issuing country, but not much can help if government starts spying on the secure connections of its own citizens."</i></htmltext>
<tokenext>FutureDomain writes " Is SSL becoming pointless ?
Researchers are poking holes in the chain of trust for SSL certificates which protect sensitive data .
According to these hypothesized attacks , governments could compel certificate authorities to give them phony certificates that are signed by the CA , which are then used to perform man in the middle attacks .
They point out that Verisign already makes large sums of money by facilitating the disclosure of US consumers ' private data to US government law enforcement .
The researchers are developing a Firefox plugin ( PDF ) that checks past certificates and warns of anomalies in the issuing country , but not much can help if government starts spying on the secure connections of its own citizens .
"</tokentext>
<sentencetext>FutureDomain writes "Is SSL becoming pointless?
Researchers are poking holes in the chain of trust for SSL certificates which protect sensitive data.
According to these hypothesized attacks, governments could compel certificate authorities to give them phony certificates that are signed by the CA, which are then used to perform man in the middle attacks.
They point out that Verisign already makes large sums of money by facilitating the disclosure of US consumers' private data to US government law enforcement.
The researchers are developing a Firefox plugin (PDF) that checks past certificates and warns of anomalies in the issuing country, but not much can help if government starts spying on the secure connections of its own citizens.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627280</id>
	<title>What about a DNS TXT record with hints?</title>
	<author>Anonymous</author>
	<datestamp>1269622380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So the problem is that two different CAs could issue certs for the same host, and some have essentially back doors?</p><p>Know what I'd like to see?  How about a DNS TXT record that tells you what the real, trusted CA for a given site is?  Like, let people assert "for my domain, do not trust any certs unless they come from this particular CA", using DNS as an out-of-band channel that would have to be compromised separately from the SSL negotiation.</p><p>Wouldn't that be relatively easy to implement (for those who care to), and reasonably effective against anyone who can't compromise the root DNS servers?</p></htmltext>
<tokenext>So the problem is that two different CAs could issue certs for the same host , and some have essentially back doors ? Know what I 'd like to see ?
How about a DNS TXT record that tells you what the real , trusted CA for a given site is ?
Like , let people assert " for my domain , do not trust any certs unless they come from this particular CA " , using DNS as an out-of-band channel that would have to be compromised separately from the SSL negotiation.Would n't that be relatively easy to implement ( for those who care to ) , and reasonably effective against anyone who ca n't compromise the root DNS servers ?</tokentext>
<sentencetext>So the problem is that two different CAs could issue certs for the same host, and some have essentially back doors?Know what I'd like to see?
How about a DNS TXT record that tells you what the real, trusted CA for a given site is?
Like, let people assert "for my domain, do not trust any certs unless they come from this particular CA", using DNS as an out-of-band channel that would have to be compromised separately from the SSL negotiation.Wouldn't that be relatively easy to implement (for those who care to), and reasonably effective against anyone who can't compromise the root DNS servers?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626326</id>
	<title>Paranoia is all well and good...</title>
	<author>DrgnDancer</author>
	<datestamp>1269618600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Essentially if you really want secure end to end communication with someone that is more or less fool proof and not subject to outside interference you have to manually exchange keys.  It's always been this way.  Any time you do less you are trusting *someone* other than yourself and person at the remote end.  The simple point is that we *have* to trust someone to exist in society.  We trust that the government will not suddenly decide to print "Braquats" and declare Dollars (or Pounds, or Euros, or whatever) useless.  We trust that the bank won't wander off with all our money.  We trust that our ISP isn't just putting up servers that pretend to be the Internet and are slowly stealing everything we type into our browsers.  We trust that the grocery store hasn't poisoned all the produce. Virtually every social action we take involves some modicum of trust that the "other guy" is acting in reasonably good faith.</p><p>Thus far the certificate authorities have been trustworthy.  Could they be compromised?  Of course.  Could the clerk at the grocery store be bribed to poison all the produce? Of course.  Do we have any reason to think the CAs *have* been compromised?  Not that I'm aware of.  It's pretty straightforward. Are you doing something that needs to be *completely* secret?  Exchange keys with the remote end manually.  Are you doing something that needs to be as secret as one can reasonably expect while still dealing public entities?  Use the CAs.  They have an extremely good track record and seem to be about as trustworthy as anyone can reasonably expect.</p></htmltext>
<tokenext>Essentially if you really want secure end to end communication with someone that is more or less fool proof and not subject to outside interference you have to manually exchange keys .
It 's always been this way .
Any time you do less you are trusting * someone * other than yourself and person at the remote end .
The simple point is that we * have * to trust someone to exist in society .
We trust that the government will not suddenly decide to print " Braquats " and declare Dollars ( or Pounds , or Euros , or whatever ) useless .
We trust that the bank wo n't wander off with all our money .
We trust that our ISP is n't just putting up servers that pretend to be the Internet and are slowly stealing everything we type into our browsers .
We trust that the grocery store has n't poisoned all the produce .
Virtually every social action we take involves some modicum of trust that the " other guy " is acting in reasonably good faith.Thus far the certificate authorities have been trustworthy .
Could they be compromised ?
Of course .
Could the clerk at the grocery store be bribed to poison all the produce ?
Of course .
Do we have any reason to think the CAs * have * been compromised ?
Not that I 'm aware of .
It 's pretty straightforward .
Are you doing something that needs to be * completely * secret ?
Exchange keys with the remote end manually .
Are you doing something that needs to be as secret as one can reasonably expect while still dealing public entities ?
Use the CAs .
They have an extremely good track record and seem to be about as trustworthy as anyone can reasonably expect .</tokentext>
<sentencetext>Essentially if you really want secure end to end communication with someone that is more or less fool proof and not subject to outside interference you have to manually exchange keys.
It's always been this way.
Any time you do less you are trusting *someone* other than yourself and person at the remote end.
The simple point is that we *have* to trust someone to exist in society.
We trust that the government will not suddenly decide to print "Braquats" and declare Dollars (or Pounds, or Euros, or whatever) useless.
We trust that the bank won't wander off with all our money.
We trust that our ISP isn't just putting up servers that pretend to be the Internet and are slowly stealing everything we type into our browsers.
We trust that the grocery store hasn't poisoned all the produce.
Virtually every social action we take involves some modicum of trust that the "other guy" is acting in reasonably good faith.Thus far the certificate authorities have been trustworthy.
Could they be compromised?
Of course.
Could the clerk at the grocery store be bribed to poison all the produce?
Of course.
Do we have any reason to think the CAs *have* been compromised?
Not that I'm aware of.
It's pretty straightforward.
Are you doing something that needs to be *completely* secret?
Exchange keys with the remote end manually.
Are you doing something that needs to be as secret as one can reasonably expect while still dealing public entities?
Use the CAs.
They have an extremely good track record and seem to be about as trustworthy as anyone can reasonably expect.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626166</id>
	<title>no duh</title>
	<author>Sloppy</author>
	<datestamp>1269618060000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Nobody would ever seriously say that x.509's single point of failure for trusted introducers is a good idea; it just happened to be easy to deploy and got some encouragement along the way because some people could make money on it.  But as soon as you look at it in terms of security, it doesn't fare very well.</p><p>OpenPGP encourages multiple certifiers for an identity: so they're <em>all</em> required to conspire to sell you out.  Conspiracies are <em>hard</em>. Build your next network app on top of Gnu TLS and make sure you test with OpenPGP, so that some day we can switch to modern (and by modern, I mean about 1990-level tech) crypto.</p><p>BTW, governments are a great example, but always remember that they are not the only entities with capability or motivation to point a gun at someone.  And even if you don't believe that, you've got to admit there are <em>multiple</em> governments, and only one of them at most, is accountable to <em>you.</em>  Anyone who says that the cert system <em>should</em> be left vulnerable because the public has an interest in making sure that communications aren't "too secure," definitely isn't thinking about all the angles.  The inherent weaknesses of X.509 should never have been used as an argument <em>for</em> building the web on it.</p></htmltext>
<tokenext>Nobody would ever seriously say that x.509 's single point of failure for trusted introducers is a good idea ; it just happened to be easy to deploy and got some encouragement along the way because some people could make money on it .
But as soon as you look at it in terms of security , it does n't fare very well.OpenPGP encourages multiple certifiers for an identity : so they 're all required to conspire to sell you out .
Conspiracies are hard .
Build your next network app on top of Gnu TLS and make sure you test with OpenPGP , so that some day we can switch to modern ( and by modern , I mean about 1990-level tech ) crypto.BTW , governments are a great example , but always remember that they are not the only entities with capability or motivation to point a gun at someone .
And even if you do n't believe that , you 've got to admit there are multiple governments , and only one of them at most , is accountable to you .
Anyone who says that the cert system should be left vulnerable because the public has an interest in making sure that communications are n't " too secure , " definitely is n't thinking about all the angles .
The inherent weaknesses of X.509 should never have been used as an argument for building the web on it .</tokentext>
<sentencetext>Nobody would ever seriously say that x.509's single point of failure for trusted introducers is a good idea; it just happened to be easy to deploy and got some encouragement along the way because some people could make money on it.
But as soon as you look at it in terms of security, it doesn't fare very well.OpenPGP encourages multiple certifiers for an identity: so they're all required to conspire to sell you out.
Conspiracies are hard.
Build your next network app on top of Gnu TLS and make sure you test with OpenPGP, so that some day we can switch to modern (and by modern, I mean about 1990-level tech) crypto.BTW, governments are a great example, but always remember that they are not the only entities with capability or motivation to point a gun at someone.
And even if you don't believe that, you've got to admit there are multiple governments, and only one of them at most, is accountable to you.
Anyone who says that the cert system should be left vulnerable because the public has an interest in making sure that communications aren't "too secure," definitely isn't thinking about all the angles.
The inherent weaknesses of X.509 should never have been used as an argument for building the web on it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629174</id>
	<title>Re:what no one wants you to know</title>
	<author>Anonymous</author>
	<datestamp>1269628500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Pfft! Anyone with really real security would string their own fiber directly to each router and create their own private network kicking everyone else off the end network while they use it, and then dismantle everything afterward. You kids and your 'certificates'.</p></htmltext>
<tokenext>Pfft !
Anyone with really real security would string their own fiber directly to each router and create their own private network kicking everyone else off the end network while they use it , and then dismantle everything afterward .
You kids and your 'certificates' .</tokentext>
<sentencetext>Pfft!
Anyone with really real security would string their own fiber directly to each router and create their own private network kicking everyone else off the end network while they use it, and then dismantle everything afterward.
You kids and your 'certificates'.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625862</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31633110</id>
	<title>Re:If security is really important to you</title>
	<author>Anonymous</author>
	<datestamp>1269600600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What you are really saying is that, once again, this is only going to impact the naive, stupid and honest users, crooks, terrorists, governments and the careful will continue to do as you suggest and not TRUST the public CAs.</p></htmltext>
<tokenext>What you are really saying is that , once again , this is only going to impact the naive , stupid and honest users , crooks , terrorists , governments and the careful will continue to do as you suggest and not TRUST the public CAs .</tokentext>
<sentencetext>What you are really saying is that, once again, this is only going to impact the naive, stupid and honest users, crooks, terrorists, governments and the careful will continue to do as you suggest and not TRUST the public CAs.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625860</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625884</id>
	<title>SSL / HTTPS</title>
	<author>bbroerman</author>
	<datestamp>1269617100000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>One more nail in the coffin... (See <a href="http://nearlyperfectsoftware.com/secureajax.html" title="nearlyperf...ftware.com" rel="nofollow">http://nearlyperfectsoftware.com/secureajax.html</a> [nearlyperf...ftware.com] for other hacks). Good thing I'm working on a protocol and libraries / utilities that can be used to replace it for all of my work, and my clients... Starting with a secure ajax framework, then on to things like POP, IMAP,  SMTP, FTP, Telnet, etc.  Should be cool once I get them all done.</htmltext>
<tokenext>One more nail in the coffin... ( See http : //nearlyperfectsoftware.com/secureajax.html [ nearlyperf...ftware.com ] for other hacks ) .
Good thing I 'm working on a protocol and libraries / utilities that can be used to replace it for all of my work , and my clients... Starting with a secure ajax framework , then on to things like POP , IMAP , SMTP , FTP , Telnet , etc .
Should be cool once I get them all done .</tokentext>
<sentencetext>One more nail in the coffin... (See http://nearlyperfectsoftware.com/secureajax.html [nearlyperf...ftware.com] for other hacks).
Good thing I'm working on a protocol and libraries / utilities that can be used to replace it for all of my work, and my clients... Starting with a secure ajax framework, then on to things like POP, IMAP,  SMTP, FTP, Telnet, etc.
Should be cool once I get them all done.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626470</id>
	<title>YOU FAIL IT!?</title>
	<author>Anonymous</author>
	<datestamp>1269619140000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext>words, don't gemt B7ig picture. What</htmltext>
<tokenext>words , do n't gemt B7ig picture .
What</tokentext>
<sentencetext>words, don't gemt B7ig picture.
What</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626214</id>
	<title>Re:If security is really important to you</title>
	<author>Cassini2</author>
	<datestamp>1269618300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.</p></div></blockquote><p>Precisely.  Otherwise, you are always open to a sufficiently sophisticated man in the middle attack.</p></div>
	</htmltext>
<tokenext>If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.Precisely .
Otherwise , you are always open to a sufficiently sophisticated man in the middle attack .</tokentext>
<sentencetext>If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.Precisely.
Otherwise, you are always open to a sufficiently sophisticated man in the middle attack.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625860</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626096</id>
	<title>Banking secrecy laws</title>
	<author>Anonymous</author>
	<datestamp>1269617820000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>Not a theoretical concern, but a very real one.<p>
Many European countries (Germany, Belgium) now have electronic identity cards, which double as PKI signing tokens, with which you can authenticate yourself to web services, such as your bank.</p><p>
When Luxembourg introduced a <a href="http://www.luxtrust.lu/" title="luxtrust.lu">similar system</a> [luxtrust.lu] they <em>didn't</em> piggy back it on an id card, but issued "signing stick" and smart cards just for the purpose of PKI.</p><p>
You may wonder why, especially since an electronic id card is already in planning in Luxembourg as well.</p><p>
The answer is obvious: many customers of Luxembourgish banks are foreigners, couldn't thus get a Luxembourgish id card, but wouldn't trust their own government's id cards, so an ad-hoc system was needed: Luxtrust.</p><p>
Unfortunately, Luxembourg doesn't have any native smartcard industry, so they had to buy the chips from the <a href="http://www.gemalto.com/" title="gemalto.com">French</a> [gemalto.com]... who just shipped units with a predictable random number generator, dramatically reducing the number of possible private keys. FAIL.</p><p>
And the <a href="http://www.bsi.de/" title="www.bsi.de">BSI</a> [www.bsi.de] institute (which "certified" the cards) "overlooked" this weakness, because the Germans too have a vested interested in spying on communications with Luxembourgish banks. DOUBLE FAIL.</p></htmltext>
<tokenext>Not a theoretical concern , but a very real one .
Many European countries ( Germany , Belgium ) now have electronic identity cards , which double as PKI signing tokens , with which you can authenticate yourself to web services , such as your bank .
When Luxembourg introduced a similar system [ luxtrust.lu ] they did n't piggy back it on an id card , but issued " signing stick " and smart cards just for the purpose of PKI .
You may wonder why , especially since an electronic id card is already in planning in Luxembourg as well .
The answer is obvious : many customers of Luxembourgish banks are foreigners , could n't thus get a Luxembourgish id card , but would n't trust their own government 's id cards , so an ad-hoc system was needed : Luxtrust .
Unfortunately , Luxembourg does n't have any native smartcard industry , so they had to buy the chips from the French [ gemalto.com ] ... who just shipped units with a predictable random number generator , dramatically reducing the number of possible private keys .
FAIL . And the BSI [ www.bsi.de ] institute ( which " certified " the cards ) " overlooked " this weakness , because the Germans too have a vested interested in spying on communications with Luxembourgish banks .
DOUBLE FAIL .</tokentext>
<sentencetext>Not a theoretical concern, but a very real one.
Many European countries (Germany, Belgium) now have electronic identity cards, which double as PKI signing tokens, with which you can authenticate yourself to web services, such as your bank.
When Luxembourg introduced a similar system [luxtrust.lu] they didn't piggy back it on an id card, but issued "signing stick" and smart cards just for the purpose of PKI.
You may wonder why, especially since an electronic id card is already in planning in Luxembourg as well.
The answer is obvious: many customers of Luxembourgish banks are foreigners, couldn't thus get a Luxembourgish id card, but wouldn't trust their own government's id cards, so an ad-hoc system was needed: Luxtrust.
Unfortunately, Luxembourg doesn't have any native smartcard industry, so they had to buy the chips from the French [gemalto.com]... who just shipped units with a predictable random number generator, dramatically reducing the number of possible private keys.
FAIL.
And the BSI [www.bsi.de] institute (which "certified" the cards) "overlooked" this weakness, because the Germans too have a vested interested in spying on communications with Luxembourgish banks.
DOUBLE FAIL.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628882</id>
	<title>About f*cking time</title>
	<author>Yvanhoe</author>
	<datestamp>1269627540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This whole CA thing is based on a hierarchical chain of trust, you can't keep it invisible for long. All certs are not equally trustable. We shouldn't get used to assimilate the "secure" icon to a completely trusted user, but just as a second grade security that our (incompetent) banks rely on. When they are not simply using http...</htmltext>
<tokenext>This whole CA thing is based on a hierarchical chain of trust , you ca n't keep it invisible for long .
All certs are not equally trustable .
We should n't get used to assimilate the " secure " icon to a completely trusted user , but just as a second grade security that our ( incompetent ) banks rely on .
When they are not simply using http.. .</tokentext>
<sentencetext>This whole CA thing is based on a hierarchical chain of trust, you can't keep it invisible for long.
All certs are not equally trustable.
We shouldn't get used to assimilate the "secure" icon to a completely trusted user, but just as a second grade security that our (incompetent) banks rely on.
When they are not simply using http...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31637854</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>Zarhan</author>
	<datestamp>1269684300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>SSL is, and always has been, and ugly hack. End-to-end encryption should be done at the IP layer, not the TCP layer. </i></p><p>
&nbsp; &nbsp; No way. The higher layer encryption is conducted, the better. The lowest layer where there even is any concept of "end-to-end" is transport.</p><p>
&nbsp; &nbsp; Same reason you don't think about doing online banking over WPA-shielded wireless LAN, because you know that the security only extends to the access point.</p><p>
&nbsp; &nbsp; Especially with all the locator-identity divergence work going on, or even if IP(v6) anycast comes along as a load balancing method, you really don't want to worry about things in IP layer affecting your security - so just take it higher.</p></htmltext>
<tokenext>SSL is , and always has been , and ugly hack .
End-to-end encryption should be done at the IP layer , not the TCP layer .
    No way .
The higher layer encryption is conducted , the better .
The lowest layer where there even is any concept of " end-to-end " is transport .
    Same reason you do n't think about doing online banking over WPA-shielded wireless LAN , because you know that the security only extends to the access point .
    Especially with all the locator-identity divergence work going on , or even if IP ( v6 ) anycast comes along as a load balancing method , you really do n't want to worry about things in IP layer affecting your security - so just take it higher .</tokentext>
<sentencetext>SSL is, and always has been, and ugly hack.
End-to-end encryption should be done at the IP layer, not the TCP layer.
    No way.
The higher layer encryption is conducted, the better.
The lowest layer where there even is any concept of "end-to-end" is transport.
    Same reason you don't think about doing online banking over WPA-shielded wireless LAN, because you know that the security only extends to the access point.
    Especially with all the locator-identity divergence work going on, or even if IP(v6) anycast comes along as a load balancing method, you really don't want to worry about things in IP layer affecting your security - so just take it higher.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626184</id>
	<title>So trust the CAs a little less</title>
	<author>johndoe42</author>
	<datestamp>1269618120000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>There a "fix" that should help a lot: have browsers cache all certificates that they've accepted.  Then, whenever a site *changes* its certificate, give a bit fat warning and optionally send the new certificate to some repository of questionable certificates.</p><p>If that repository starts to see bogus certificates signed by a CA, revoke that CA's root certificate.</p><p>To really make it work, HTTPS should have a mechanism to indicate that a certificate may not be changed until such-and-such a time, and there should be a way to (later, when using a different internet connection) tell a website what certificates you've seen that claim to identify it.  That way the web site operator can go after bad CAs itself.</p></htmltext>
<tokenext>There a " fix " that should help a lot : have browsers cache all certificates that they 've accepted .
Then , whenever a site * changes * its certificate , give a bit fat warning and optionally send the new certificate to some repository of questionable certificates.If that repository starts to see bogus certificates signed by a CA , revoke that CA 's root certificate.To really make it work , HTTPS should have a mechanism to indicate that a certificate may not be changed until such-and-such a time , and there should be a way to ( later , when using a different internet connection ) tell a website what certificates you 've seen that claim to identify it .
That way the web site operator can go after bad CAs itself .</tokentext>
<sentencetext>There a "fix" that should help a lot: have browsers cache all certificates that they've accepted.
Then, whenever a site *changes* its certificate, give a bit fat warning and optionally send the new certificate to some repository of questionable certificates.If that repository starts to see bogus certificates signed by a CA, revoke that CA's root certificate.To really make it work, HTTPS should have a mechanism to indicate that a certificate may not be changed until such-and-such a time, and there should be a way to (later, when using a different internet connection) tell a website what certificates you've seen that claim to identify it.
That way the web site operator can go after bad CAs itself.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625878</id>
	<title>and remember...</title>
	<author>presarioD</author>
	<datestamp>1269617100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>...all this is for your own good...government by the people for the people type of thing...smile...</htmltext>
<tokenext>...all this is for your own good...government by the people for the people type of thing...smile.. .</tokentext>
<sentencetext>...all this is for your own good...government by the people for the people type of thing...smile...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31636958</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>Anonymous</author>
	<datestamp>1269626040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You know, with a PKI, the main problem is man-in-the-middle. It's quite possible to defeat that though, using computationally intensive calculations and latency analysis, getting to around 1 in 4 billion chance in only 32 rounds. I should really publish a paper on this, it's pretty cool.</p></htmltext>
<tokenext>You know , with a PKI , the main problem is man-in-the-middle .
It 's quite possible to defeat that though , using computationally intensive calculations and latency analysis , getting to around 1 in 4 billion chance in only 32 rounds .
I should really publish a paper on this , it 's pretty cool .</tokentext>
<sentencetext>You know, with a PKI, the main problem is man-in-the-middle.
It's quite possible to defeat that though, using computationally intensive calculations and latency analysis, getting to around 1 in 4 billion chance in only 32 rounds.
I should really publish a paper on this, it's pretty cool.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625776</id>
	<title>who can we trust?</title>
	<author>Mantis8</author>
	<datestamp>1269616680000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext>This reminds me of a bumper sticker many of us have seen..."Don't steal, the government hates competition!"</htmltext>
<tokenext>This reminds me of a bumper sticker many of us have seen... " Do n't steal , the government hates competition !
"</tokentext>
<sentencetext>This reminds me of a bumper sticker many of us have seen..."Don't steal, the government hates competition!
"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628530</id>
	<title>NSA has lots of CPU power</title>
	<author>Anonymous</author>
	<datestamp>1269626400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The NSA has lots of CPU power.  What makes us think they need the CA's cooperation to spoof a cert?  That's so 1990's thinking.</p></htmltext>
<tokenext>The NSA has lots of CPU power .
What makes us think they need the CA 's cooperation to spoof a cert ?
That 's so 1990 's thinking .</tokentext>
<sentencetext>The NSA has lots of CPU power.
What makes us think they need the CA's cooperation to spoof a cert?
That's so 1990's thinking.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626188</id>
	<title>I call bullsh*t</title>
	<author>Sardonis</author>
	<datestamp>1269618180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Quoth the website:<p><div class="quote"><p>Distribution of encryption keys and code is performed with a Patent Pending process that is immune to man-in-the-middle attacks
</p><p>Does NOT use SSL or third party certificates.</p></div><p>Can't do authentication without some trusted authority or web-of-trust. I'd like to see this 'Patent Pending process' examined by experts...</p></div>
	</htmltext>
<tokenext>Quoth the website : Distribution of encryption keys and code is performed with a Patent Pending process that is immune to man-in-the-middle attacks Does NOT use SSL or third party certificates.Ca n't do authentication without some trusted authority or web-of-trust .
I 'd like to see this 'Patent Pending process ' examined by experts.. .</tokentext>
<sentencetext>Quoth the website:Distribution of encryption keys and code is performed with a Patent Pending process that is immune to man-in-the-middle attacks
Does NOT use SSL or third party certificates.Can't do authentication without some trusted authority or web-of-trust.
I'd like to see this 'Patent Pending process' examined by experts...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628648</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>Sir\_Lewk</author>
	<datestamp>1269626880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The layer encryption is done on is really irrelevant to this issue, it is the trust model that is broken.</p></htmltext>
<tokenext>The layer encryption is done on is really irrelevant to this issue , it is the trust model that is broken .</tokentext>
<sentencetext>The layer encryption is done on is really irrelevant to this issue, it is the trust model that is broken.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626510</id>
	<title>Told you so</title>
	<author>ugen</author>
	<datestamp>1269619260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Here is a link to my own reply previously: <a href="http://slashdot.org/comments.pl?sid=1534366&amp;cid=31004066" title="slashdot.org">http://slashdot.org/comments.pl?sid=1534366&amp;cid=31004066</a> [slashdot.org]</p><p>To summarize - I don't see how the "trust system" has any meaning. I don't actually know anyone at those 160+ companies and I sure as hell don't *trust* any one of them, not as far as I can throw them.</p><p>In fact, I don't really trust anyone<nobr> <wbr></nobr>:) and based on that - see no reason that my SSL connection is more or less safe whether the cert for counterparty is signed by a "good" or "bad" CA. Frankly, I trust my bank or Google mail even less than a CA - so what exactly is there to protect?</p></htmltext>
<tokenext>Here is a link to my own reply previously : http : //slashdot.org/comments.pl ? sid = 1534366&amp;cid = 31004066 [ slashdot.org ] To summarize - I do n't see how the " trust system " has any meaning .
I do n't actually know anyone at those 160 + companies and I sure as hell do n't * trust * any one of them , not as far as I can throw them.In fact , I do n't really trust anyone : ) and based on that - see no reason that my SSL connection is more or less safe whether the cert for counterparty is signed by a " good " or " bad " CA .
Frankly , I trust my bank or Google mail even less than a CA - so what exactly is there to protect ?</tokentext>
<sentencetext>Here is a link to my own reply previously: http://slashdot.org/comments.pl?sid=1534366&amp;cid=31004066 [slashdot.org]To summarize - I don't see how the "trust system" has any meaning.
I don't actually know anyone at those 160+ companies and I sure as hell don't *trust* any one of them, not as far as I can throw them.In fact, I don't really trust anyone :) and based on that - see no reason that my SSL connection is more or less safe whether the cert for counterparty is signed by a "good" or "bad" CA.
Frankly, I trust my bank or Google mail even less than a CA - so what exactly is there to protect?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626650</id>
	<title>Re:Is it time yet?</title>
	<author>Z00L00K</author>
	<datestamp>1269619800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In any case - this will work only when the CA authority is cooperating with the government, but if you are your own CA then you will be in control of the chain.</p><p>Of course - your CA server may suffer an intrusion, but it will require a physical attack from an intruder. Especially if your CA server isn't connected to the net. And there are a large number of tricks to pull to detect intrusions in your facilities. Some of them are centuries old.</p></htmltext>
<tokenext>In any case - this will work only when the CA authority is cooperating with the government , but if you are your own CA then you will be in control of the chain.Of course - your CA server may suffer an intrusion , but it will require a physical attack from an intruder .
Especially if your CA server is n't connected to the net .
And there are a large number of tricks to pull to detect intrusions in your facilities .
Some of them are centuries old .</tokentext>
<sentencetext>In any case - this will work only when the CA authority is cooperating with the government, but if you are your own CA then you will be in control of the chain.Of course - your CA server may suffer an intrusion, but it will require a physical attack from an intruder.
Especially if your CA server isn't connected to the net.
And there are a large number of tricks to pull to detect intrusions in your facilities.
Some of them are centuries old.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625760</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627840</id>
	<title>Mechanisms exist to prevent these "attacks"</title>
	<author>Halo-</author>
	<datestamp>1269624480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
A lot of these "attacks" can be prevented by properly implementing your PKI.  For example, some of the articles (and several commenters) make mention of "using a Root CA to generate sub-CA's which then generate rogue certs".  Sure, the system allows this to happen, but it also provides constraints to prevent it.  One of usual "basic constraints" (which is an X.509 attribute) of a certificate is:  "Max path length" which means:  "how deep can a signature chain extend from me, if I am trusted"  For most people, there should never be a trusted CA in their keystore which has a max path length greater than 1.  (Meaning it can vouch for others, but those others cannot vouch for a second level of trust).
</p><p>
Additionally, all X.509 certificates contain a "Key Usage" field, which specifies what the key can be used to validly sign.  For most people, they should never have a certificate in their root store which has the "CA signing" bit set.  This is another way to prevent a "trusted" CA from creating a rogue CA which can then issue bad certs.
</p><p>
Finally, there are multiple methods for checking if a certificate is still trusted as part of a regular, ongoing, and sometimes even per-use basis.  (<a href="http://en.wikipedia.org/wiki/Online\_Certificate\_Status\_Protocol" title="wikipedia.org">OCSP</a> [wikipedia.org], CRL, etc...)  In the past, when I worked on PKI's, these often weren't implemented, but increasingly they are today most browsers support them.  (Which is not to say browsers are the only users of X.509 certs.)
</p><p>
What this <i>should</i> mean is that as soon as evidence emerges that a formally "trusted" CA has done something shady, it can quickly be disabled in the field.
</p><p>
In a perfect world, a CA should be sufficiently incented by the threat of being "revoked" via OCSP or whatever that it would <i>never</i> entertain the idea of creating a rogue cert.  Imagine the pressure on a large CA like Verisign if they got a root cert yanked.  Suddenly ALL of their customers get labeled as compromised.
</p></htmltext>
<tokenext>A lot of these " attacks " can be prevented by properly implementing your PKI .
For example , some of the articles ( and several commenters ) make mention of " using a Root CA to generate sub-CA 's which then generate rogue certs " .
Sure , the system allows this to happen , but it also provides constraints to prevent it .
One of usual " basic constraints " ( which is an X.509 attribute ) of a certificate is : " Max path length " which means : " how deep can a signature chain extend from me , if I am trusted " For most people , there should never be a trusted CA in their keystore which has a max path length greater than 1 .
( Meaning it can vouch for others , but those others can not vouch for a second level of trust ) .
Additionally , all X.509 certificates contain a " Key Usage " field , which specifies what the key can be used to validly sign .
For most people , they should never have a certificate in their root store which has the " CA signing " bit set .
This is another way to prevent a " trusted " CA from creating a rogue CA which can then issue bad certs .
Finally , there are multiple methods for checking if a certificate is still trusted as part of a regular , ongoing , and sometimes even per-use basis .
( OCSP [ wikipedia.org ] , CRL , etc... ) In the past , when I worked on PKI 's , these often were n't implemented , but increasingly they are today most browsers support them .
( Which is not to say browsers are the only users of X.509 certs .
) What this should mean is that as soon as evidence emerges that a formally " trusted " CA has done something shady , it can quickly be disabled in the field .
In a perfect world , a CA should be sufficiently incented by the threat of being " revoked " via OCSP or whatever that it would never entertain the idea of creating a rogue cert .
Imagine the pressure on a large CA like Verisign if they got a root cert yanked .
Suddenly ALL of their customers get labeled as compromised .</tokentext>
<sentencetext>
A lot of these "attacks" can be prevented by properly implementing your PKI.
For example, some of the articles (and several commenters) make mention of "using a Root CA to generate sub-CA's which then generate rogue certs".
Sure, the system allows this to happen, but it also provides constraints to prevent it.
One of usual "basic constraints" (which is an X.509 attribute) of a certificate is:  "Max path length" which means:  "how deep can a signature chain extend from me, if I am trusted"  For most people, there should never be a trusted CA in their keystore which has a max path length greater than 1.
(Meaning it can vouch for others, but those others cannot vouch for a second level of trust).
Additionally, all X.509 certificates contain a "Key Usage" field, which specifies what the key can be used to validly sign.
For most people, they should never have a certificate in their root store which has the "CA signing" bit set.
This is another way to prevent a "trusted" CA from creating a rogue CA which can then issue bad certs.
Finally, there are multiple methods for checking if a certificate is still trusted as part of a regular, ongoing, and sometimes even per-use basis.
(OCSP [wikipedia.org], CRL, etc...)  In the past, when I worked on PKI's, these often weren't implemented, but increasingly they are today most browsers support them.
(Which is not to say browsers are the only users of X.509 certs.
)

What this should mean is that as soon as evidence emerges that a formally "trusted" CA has done something shady, it can quickly be disabled in the field.
In a perfect world, a CA should be sufficiently incented by the threat of being "revoked" via OCSP or whatever that it would never entertain the idea of creating a rogue cert.
Imagine the pressure on a large CA like Verisign if they got a root cert yanked.
Suddenly ALL of their customers get labeled as compromised.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625946</id>
	<title>Does that mean...</title>
	<author>alexhs</author>
	<datestamp>1269617340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Does that mean that self-signed certificates are now more secure ?<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>Does that mean that self-signed certificates are now more secure ?
: )</tokentext>
<sentencetext>Does that mean that self-signed certificates are now more secure ?
:)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628070</id>
	<title>Re:Banking secrecy laws</title>
	<author>Cyberax</author>
	<datestamp>1269625020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Are you sure they haven't just shipped Debian on these sticks?<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>Are you sure they have n't just shipped Debian on these sticks ?
: )</tokentext>
<sentencetext>Are you sure they haven't just shipped Debian on these sticks?
:)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626096</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626566</id>
	<title>Re:Is it time yet?</title>
	<author>Timothy Brownawell</author>
	<datestamp>1269619560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>For the return to tin can and string?</p></div><p>
No, but it might be time for people to start using <a href="http://www.cs.cmu.edu/~perspectives/firefox.html" title="cmu.edu">Perspectives</a> [cmu.edu]. Which I'd guess is a better version of the new extension these people are making, although I can't really tell due to the PDF being broken (slashdotted?).
</p></div>
	</htmltext>
<tokenext>For the return to tin can and string ?
No , but it might be time for people to start using Perspectives [ cmu.edu ] .
Which I 'd guess is a better version of the new extension these people are making , although I ca n't really tell due to the PDF being broken ( slashdotted ?
) .</tokentext>
<sentencetext>For the return to tin can and string?
No, but it might be time for people to start using Perspectives [cmu.edu].
Which I'd guess is a better version of the new extension these people are making, although I can't really tell due to the PDF being broken (slashdotted?
).

	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625760</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629710</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>mlts</author>
	<datestamp>1269630240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Even with IPSec, I'd still use SSL because it does encryption on a higher level, and in some cases, is controlled by app versus app.  It also allows for client certificates, so I can lock out a host of problems by having a critical external-facing Web server only allow for authentication via a cert on a smart card.  Of course, more sophisticated malware can run a MITM attack by compromising the browser and changing text in flight before it leaves the client machine, but that isn't what SSL is designed to protect against.</p><p>IPSec can work keys on the machine layer, but I like packing my own parachute on a higher layer with SSL or SSH.</p></htmltext>
<tokenext>Even with IPSec , I 'd still use SSL because it does encryption on a higher level , and in some cases , is controlled by app versus app .
It also allows for client certificates , so I can lock out a host of problems by having a critical external-facing Web server only allow for authentication via a cert on a smart card .
Of course , more sophisticated malware can run a MITM attack by compromising the browser and changing text in flight before it leaves the client machine , but that is n't what SSL is designed to protect against.IPSec can work keys on the machine layer , but I like packing my own parachute on a higher layer with SSL or SSH .</tokentext>
<sentencetext>Even with IPSec, I'd still use SSL because it does encryption on a higher level, and in some cases, is controlled by app versus app.
It also allows for client certificates, so I can lock out a host of problems by having a critical external-facing Web server only allow for authentication via a cert on a smart card.
Of course, more sophisticated malware can run a MITM attack by compromising the browser and changing text in flight before it leaves the client machine, but that isn't what SSL is designed to protect against.IPSec can work keys on the machine layer, but I like packing my own parachute on a higher layer with SSL or SSH.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625862</id>
	<title>what no one wants you to know</title>
	<author>yup2000</author>
	<datestamp>1269617040000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>And it took you how long to figure this out? Anyone with real security in mind would create their own certificates and sign them. What's always been missing is a convenient way to verify the identify of the person you're communicating with. CAs only help in certain situations. SSL has always been more about encrypted content than identification no matter what people try to tell you.</p></htmltext>
<tokenext>And it took you how long to figure this out ?
Anyone with real security in mind would create their own certificates and sign them .
What 's always been missing is a convenient way to verify the identify of the person you 're communicating with .
CAs only help in certain situations .
SSL has always been more about encrypted content than identification no matter what people try to tell you .</tokentext>
<sentencetext>And it took you how long to figure this out?
Anyone with real security in mind would create their own certificates and sign them.
What's always been missing is a convenient way to verify the identify of the person you're communicating with.
CAs only help in certain situations.
SSL has always been more about encrypted content than identification no matter what people try to tell you.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627416</id>
	<title>mi8us 1, Troll)</title>
	<author>Anonymous</author>
	<datestamp>1269622980000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>-1</modscore>
	<htmltext>kn0ws that ever</htmltext>
<tokenext>kn0ws that ever</tokentext>
<sentencetext>kn0ws that ever</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626084</id>
	<title>Government CA's</title>
	<author>Anonymous</author>
	<datestamp>1269617760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This isn't any news.. The Dutch government got it's root certificate imported in all popular browsers (named Staat der Nederlanden CA). So they can issue a certificate for a site and no browser would warn you about a invalid certificate or something..</p></htmltext>
<tokenext>This is n't any news.. The Dutch government got it 's root certificate imported in all popular browsers ( named Staat der Nederlanden CA ) .
So they can issue a certificate for a site and no browser would warn you about a invalid certificate or something. .</tokentext>
<sentencetext>This isn't any news.. The Dutch government got it's root certificate imported in all popular browsers (named Staat der Nederlanden CA).
So they can issue a certificate for a site and no browser would warn you about a invalid certificate or something..</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628360</id>
	<title>Re:Paranoia is all well and good...</title>
	<author>Anonymous</author>
	<datestamp>1269625860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Are you doing something that needs to be *completely* secret? Exchange keys with the remote end manually.</p></div></blockquote><p>That is utterly misleading. There is no such thing as complete secrecy. It is also wrong to ask yourself: Do I trust this entity unconditionally? You should only trust an institution conditionally.  It all depends in what you're using the encryption for. Can you trust CAs for financial transactions? So far, apparently yes. Can you trust CAs with your international trade secrets as a non-US company? NOT a good idea. If you have a relatively secure side-channel for key exchange and are a non-US citizen with trade secrets, it's better not to rely on SSL for your communication but on your own certificates. You wouldn't trust SSL for the transmission of secret nuclear missile launch codes either, would you? The trustworthiness of institutions and protocols depends on case-by-case evaluations and the stakes at hand, and this has absolutely nothing to do with paranoia.</p></div>
	</htmltext>
<tokenext>Are you doing something that needs to be * completely * secret ?
Exchange keys with the remote end manually.That is utterly misleading .
There is no such thing as complete secrecy .
It is also wrong to ask yourself : Do I trust this entity unconditionally ?
You should only trust an institution conditionally .
It all depends in what you 're using the encryption for .
Can you trust CAs for financial transactions ?
So far , apparently yes .
Can you trust CAs with your international trade secrets as a non-US company ?
NOT a good idea .
If you have a relatively secure side-channel for key exchange and are a non-US citizen with trade secrets , it 's better not to rely on SSL for your communication but on your own certificates .
You would n't trust SSL for the transmission of secret nuclear missile launch codes either , would you ?
The trustworthiness of institutions and protocols depends on case-by-case evaluations and the stakes at hand , and this has absolutely nothing to do with paranoia .</tokentext>
<sentencetext>Are you doing something that needs to be *completely* secret?
Exchange keys with the remote end manually.That is utterly misleading.
There is no such thing as complete secrecy.
It is also wrong to ask yourself: Do I trust this entity unconditionally?
You should only trust an institution conditionally.
It all depends in what you're using the encryption for.
Can you trust CAs for financial transactions?
So far, apparently yes.
Can you trust CAs with your international trade secrets as a non-US company?
NOT a good idea.
If you have a relatively secure side-channel for key exchange and are a non-US citizen with trade secrets, it's better not to rely on SSL for your communication but on your own certificates.
You wouldn't trust SSL for the transmission of secret nuclear missile launch codes either, would you?
The trustworthiness of institutions and protocols depends on case-by-case evaluations and the stakes at hand, and this has absolutely nothing to do with paranoia.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627088</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>0123456</author>
	<datestamp>1269621540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>End-to-end encryption should be done at the IP layer, not the TCP layer.</p> </div><p>Sorry, but that's nonsense. Encryption should be done at the IP layer as well as by the application; if encryption is only done by IPSEC at a low level, then I have no way of knowing that my connection to my bank is secure, or is even going to the correct site.</p><p>To give an example, for a long time I've had my XP laptop at home configured to use IPSEC to talk to my Ubuntu server. Yesterday I discovered that at some point the Ubuntu server had stopped running the startup script that configures it to require IPSEC for connections from the laptop, so I've been connecting to it without encryption for an indeterminate amount of time; and the only way I found that out was because I ran wireshark.</p><p>IPSEC is a good idea, but it's definitely not a substitute for application-level encryption and authentication. It's also insanely difficult to configure and debug; I took about two days just to get a handful of PCs in my house talking to each other and even now I have to run a cron job on the Ubuntu server to ping the two Windows PCs every minute in order to ensure that IPSEC does get set up correctly once they're booted as initiating the connection from XP is very unreliable.</p></div>
	</htmltext>
<tokenext>End-to-end encryption should be done at the IP layer , not the TCP layer .
Sorry , but that 's nonsense .
Encryption should be done at the IP layer as well as by the application ; if encryption is only done by IPSEC at a low level , then I have no way of knowing that my connection to my bank is secure , or is even going to the correct site.To give an example , for a long time I 've had my XP laptop at home configured to use IPSEC to talk to my Ubuntu server .
Yesterday I discovered that at some point the Ubuntu server had stopped running the startup script that configures it to require IPSEC for connections from the laptop , so I 've been connecting to it without encryption for an indeterminate amount of time ; and the only way I found that out was because I ran wireshark.IPSEC is a good idea , but it 's definitely not a substitute for application-level encryption and authentication .
It 's also insanely difficult to configure and debug ; I took about two days just to get a handful of PCs in my house talking to each other and even now I have to run a cron job on the Ubuntu server to ping the two Windows PCs every minute in order to ensure that IPSEC does get set up correctly once they 're booted as initiating the connection from XP is very unreliable .</tokentext>
<sentencetext>End-to-end encryption should be done at the IP layer, not the TCP layer.
Sorry, but that's nonsense.
Encryption should be done at the IP layer as well as by the application; if encryption is only done by IPSEC at a low level, then I have no way of knowing that my connection to my bank is secure, or is even going to the correct site.To give an example, for a long time I've had my XP laptop at home configured to use IPSEC to talk to my Ubuntu server.
Yesterday I discovered that at some point the Ubuntu server had stopped running the startup script that configures it to require IPSEC for connections from the laptop, so I've been connecting to it without encryption for an indeterminate amount of time; and the only way I found that out was because I ran wireshark.IPSEC is a good idea, but it's definitely not a substitute for application-level encryption and authentication.
It's also insanely difficult to configure and debug; I took about two days just to get a handful of PCs in my house talking to each other and even now I have to run a cron job on the Ubuntu server to ping the two Windows PCs every minute in order to ensure that IPSEC does get set up correctly once they're booted as initiating the connection from XP is very unreliable.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627610</id>
	<title>Certificate Patrol</title>
	<author>hile</author>
	<datestamp>1269623700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>While not a perfect solution, this https://addons.mozilla.org/en-US/firefox/addon/6415" for firefox helps a little bit: it stores the certificates to a sqlite database in your profile and warns if the certificate changes.</p><p>If you get mitm on the <em>first</em> connection, you still have a problem, but the extension can at least detect if someone is trying to do it in future...</p></htmltext>
<tokenext>While not a perfect solution , this https : //addons.mozilla.org/en-US/firefox/addon/6415 " for firefox helps a little bit : it stores the certificates to a sqlite database in your profile and warns if the certificate changes.If you get mitm on the first connection , you still have a problem , but the extension can at least detect if someone is trying to do it in future.. .</tokentext>
<sentencetext>While not a perfect solution, this https://addons.mozilla.org/en-US/firefox/addon/6415" for firefox helps a little bit: it stores the certificates to a sqlite database in your profile and warns if the certificate changes.If you get mitm on the first connection, you still have a problem, but the extension can at least detect if someone is trying to do it in future...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626196</id>
	<title>Story misses the point</title>
	<author>Old97</author>
	<datestamp>1269618180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>The fact that governments can use or abuse technology to spy on its citizens is not news.  That's as newsworthy as saying that if I had possession of your computer long enough I could find out all your secrets.  If you want protection from your government, you have to do something about your government.  In democracies you have some options and generally have laws and the rule of law (mostly).  In such countries being vigilant and vocal can make the government behave if enough citizens participate.  In autocratic countries you have to expect the worst I suppose and try to work around it.  Which ever is the situation, you can't trust technology, especially one relying on a shared infrastructure (e.g. internet, ca's, etc.) to safeguard your secrets from everyone, especially anyone who has physical access to it.</htmltext>
<tokenext>The fact that governments can use or abuse technology to spy on its citizens is not news .
That 's as newsworthy as saying that if I had possession of your computer long enough I could find out all your secrets .
If you want protection from your government , you have to do something about your government .
In democracies you have some options and generally have laws and the rule of law ( mostly ) .
In such countries being vigilant and vocal can make the government behave if enough citizens participate .
In autocratic countries you have to expect the worst I suppose and try to work around it .
Which ever is the situation , you ca n't trust technology , especially one relying on a shared infrastructure ( e.g .
internet , ca 's , etc .
) to safeguard your secrets from everyone , especially anyone who has physical access to it .</tokentext>
<sentencetext>The fact that governments can use or abuse technology to spy on its citizens is not news.
That's as newsworthy as saying that if I had possession of your computer long enough I could find out all your secrets.
If you want protection from your government, you have to do something about your government.
In democracies you have some options and generally have laws and the rule of law (mostly).
In such countries being vigilant and vocal can make the government behave if enough citizens participate.
In autocratic countries you have to expect the worst I suppose and try to work around it.
Which ever is the situation, you can't trust technology, especially one relying on a shared infrastructure (e.g.
internet, ca's, etc.
) to safeguard your secrets from everyone, especially anyone who has physical access to it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</id>
	<title>Can we get rid of SSL now please?</title>
	<author>TheRaven64</author>
	<datestamp>1269617040000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>SSL is, and always has been, and ugly hack.  End-to-end encryption should be done at the IP layer, not the TCP layer.  Now that we have IPSEC, we have a standard way of doing it properly.  The only remaining part of the problem is key distribution, but with DNSSec we can put IPSEC public keys in DNS entries and get end-to-end encryption.
</p><p>
A government able to insert something into the chain of trust is still able to fake a connection, but distributing the chain of trust makes this a bit harder.  The US government won't be able to insert something into a<nobr> <wbr></nobr>.cn domain, for example, although the Chinese government can.  For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two.  Unlike an SSL certificate, the IPSec key is visible to anyone, even people who don't try to make a connection, so it's much easier to spot if someone has tampered with the connection, and will be cached in ISP's DNS caches, making an unnoticed attack much harder.</p></htmltext>
<tokenext>SSL is , and always has been , and ugly hack .
End-to-end encryption should be done at the IP layer , not the TCP layer .
Now that we have IPSEC , we have a standard way of doing it properly .
The only remaining part of the problem is key distribution , but with DNSSec we can put IPSEC public keys in DNS entries and get end-to-end encryption .
A government able to insert something into the chain of trust is still able to fake a connection , but distributing the chain of trust makes this a bit harder .
The US government wo n't be able to insert something into a .cn domain , for example , although the Chinese government can .
For the ultra-paranoid , you can publish the same IPSec public key on both and make clients compare the two .
Unlike an SSL certificate , the IPSec key is visible to anyone , even people who do n't try to make a connection , so it 's much easier to spot if someone has tampered with the connection , and will be cached in ISP 's DNS caches , making an unnoticed attack much harder .</tokentext>
<sentencetext>SSL is, and always has been, and ugly hack.
End-to-end encryption should be done at the IP layer, not the TCP layer.
Now that we have IPSEC, we have a standard way of doing it properly.
The only remaining part of the problem is key distribution, but with DNSSec we can put IPSEC public keys in DNS entries and get end-to-end encryption.
A government able to insert something into the chain of trust is still able to fake a connection, but distributing the chain of trust makes this a bit harder.
The US government won't be able to insert something into a .cn domain, for example, although the Chinese government can.
For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two.
Unlike an SSL certificate, the IPSec key is visible to anyone, even people who don't try to make a connection, so it's much easier to spot if someone has tampered with the connection, and will be cached in ISP's DNS caches, making an unnoticed attack much harder.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31630660</id>
	<title>With fingerprint verification</title>
	<author>Burz</author>
	<datestamp>1269633900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>a self-signed cert becomes <b>more</b> trustworthy than a CA-verified one.</p></htmltext>
<tokenext>a self-signed cert becomes more trustworthy than a CA-verified one .</tokentext>
<sentencetext>a self-signed cert becomes more trustworthy than a CA-verified one.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626342</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626972</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>Anonymous</author>
	<datestamp>1269620880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>The only remaining part of the problem is key distribution</p></div><p>Wow, with all the hard problems solved we just have this easy one left</p></div>
	</htmltext>
<tokenext>The only remaining part of the problem is key distributionWow , with all the hard problems solved we just have this easy one left</tokentext>
<sentencetext>The only remaining part of the problem is key distributionWow, with all the hard problems solved we just have this easy one left
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627366</id>
	<title>Re:If security is really important to you</title>
	<author>mordejai</author>
	<datestamp>1269622800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is how we did it in the pre-internet years (early 90s) with PGP.</p><p>There are two problems with this approach, however:<br>1. While it works fine for use between friends and with your company's sites, it's not practical to do with every site you interact with.<br>2. The tools (browsers, OSs) don't make it easy to add certificates. And, if they did, this would be quickly taken advantage of by malware.</p></htmltext>
<tokenext>This is how we did it in the pre-internet years ( early 90s ) with PGP.There are two problems with this approach , however : 1 .
While it works fine for use between friends and with your company 's sites , it 's not practical to do with every site you interact with.2 .
The tools ( browsers , OSs ) do n't make it easy to add certificates .
And , if they did , this would be quickly taken advantage of by malware .</tokentext>
<sentencetext>This is how we did it in the pre-internet years (early 90s) with PGP.There are two problems with this approach, however:1.
While it works fine for use between friends and with your company's sites, it's not practical to do with every site you interact with.2.
The tools (browsers, OSs) don't make it easy to add certificates.
And, if they did, this would be quickly taken advantage of by malware.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625860</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626452</id>
	<title>A couple interesting quotes I've seen about CA's:</title>
	<author>rwyoder</author>
	<datestamp>1269619020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"A CA will protect you from anyone from whom they won't take money."<br>
-- Paul Vixie - on the NANOG mailing list<br>
(Going from memory here, so the quote may not be exact.)<br>
<br>
"In the real world, you prove your identity with documents provided by a government.<br>
In the digital world, why are we trusting certificates provided by 3rd-party business???"<br>
-- a former coworker</div>
	</htmltext>
<tokenext>" A CA will protect you from anyone from whom they wo n't take money .
" -- Paul Vixie - on the NANOG mailing list ( Going from memory here , so the quote may not be exact .
) " In the real world , you prove your identity with documents provided by a government .
In the digital world , why are we trusting certificates provided by 3rd-party business ? ? ?
" -- a former coworker</tokentext>
<sentencetext>"A CA will protect you from anyone from whom they won't take money.
"
-- Paul Vixie - on the NANOG mailing list
(Going from memory here, so the quote may not be exact.
)

"In the real world, you prove your identity with documents provided by a government.
In the digital world, why are we trusting certificates provided by 3rd-party business???
"
-- a former coworker
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629390</id>
	<title>Re:Story misses the point</title>
	<author>psydeshow</author>
	<datestamp>1269629220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Let's say Liechtenstein controls a CA that is trusted by your browser. They can issue a fake cert for mail.google.com and happily MITM all your GMail connections provided they can rig your hosts file or own your router.</p><p>As we all know, there is very little you can do about the Liechtensteiner government.</p></htmltext>
<tokenext>Let 's say Liechtenstein controls a CA that is trusted by your browser .
They can issue a fake cert for mail.google.com and happily MITM all your GMail connections provided they can rig your hosts file or own your router.As we all know , there is very little you can do about the Liechtensteiner government .</tokentext>
<sentencetext>Let's say Liechtenstein controls a CA that is trusted by your browser.
They can issue a fake cert for mail.google.com and happily MITM all your GMail connections provided they can rig your hosts file or own your router.As we all know, there is very little you can do about the Liechtensteiner government.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626196</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627536</id>
	<title>There's a simlpe way to do this yourself.</title>
	<author>DamnStupidElf</author>
	<datestamp>1269623400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Disable trust in the root certificates so that your browser always prompts you to verify an SSL certificate until you mark it as trusted.  The first time you visit a site, hit it from a few different IP addresses and make sure the SSL cert matches on all the different connections to rule out a MITM attack, then verify the chain of trust up to the now-untrusted root CAs.  If you think you can still trust whichever root CA signed the cert, mark the site's cert as fully trusted and the browser won't bug you until the cert changes (either due to legitimate replacement or a MITM attack).<br>
<br>
Of course this is mostly a moot point because just about any company will happily comply with law enforcement requests to intercept your connections through a legitimate SSL session.</htmltext>
<tokenext>Disable trust in the root certificates so that your browser always prompts you to verify an SSL certificate until you mark it as trusted .
The first time you visit a site , hit it from a few different IP addresses and make sure the SSL cert matches on all the different connections to rule out a MITM attack , then verify the chain of trust up to the now-untrusted root CAs .
If you think you can still trust whichever root CA signed the cert , mark the site 's cert as fully trusted and the browser wo n't bug you until the cert changes ( either due to legitimate replacement or a MITM attack ) .
Of course this is mostly a moot point because just about any company will happily comply with law enforcement requests to intercept your connections through a legitimate SSL session .</tokentext>
<sentencetext>Disable trust in the root certificates so that your browser always prompts you to verify an SSL certificate until you mark it as trusted.
The first time you visit a site, hit it from a few different IP addresses and make sure the SSL cert matches on all the different connections to rule out a MITM attack, then verify the chain of trust up to the now-untrusted root CAs.
If you think you can still trust whichever root CA signed the cert, mark the site's cert as fully trusted and the browser won't bug you until the cert changes (either due to legitimate replacement or a MITM attack).
Of course this is mostly a moot point because just about any company will happily comply with law enforcement requests to intercept your connections through a legitimate SSL session.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626882</id>
	<title>Re:Is it time yet?</title>
	<author>petermgreen</author>
	<datestamp>1269620520000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>The problem is they don't need to get the cooperation of the CA that is actually in use, only that of one of the long list that your browser trusts.</p></htmltext>
<tokenext>The problem is they do n't need to get the cooperation of the CA that is actually in use , only that of one of the long list that your browser trusts .</tokentext>
<sentencetext>The problem is they don't need to get the cooperation of the CA that is actually in use, only that of one of the long list that your browser trusts.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626650</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625860</id>
	<title>If security is really important to you</title>
	<author>Anonymous</author>
	<datestamp>1269617040000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.</p></htmltext>
<tokenext>If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band .</tokentext>
<sentencetext>If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627286</id>
	<title>That's what Government is supposed to do...</title>
	<author>mi</author>
	<datestamp>1269622440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Enforcing the Law &mdash; using, among other things, eavesdropping on communications &mdash; and prosecuting wars, are practically <em>the only</em> things, a government of a free country is supposed to do. Because no one else can be allowed to do these things...

</p><p> <em>Everything</em> else &mdash; and I do mean everything: elementary and higher education, personal retirement, health care, communications, transportation &mdash; should be left to the <em>competing</em> enterprises. If only because they are much easier to switch from one to another, than it is to change the government...</p></htmltext>
<tokenext>Enforcing the Law    using , among other things , eavesdropping on communications    and prosecuting wars , are practically the only things , a government of a free country is supposed to do .
Because no one else can be allowed to do these things.. . Everything else    and I do mean everything : elementary and higher education , personal retirement , health care , communications , transportation    should be left to the competing enterprises .
If only because they are much easier to switch from one to another , than it is to change the government.. .</tokentext>
<sentencetext>Enforcing the Law — using, among other things, eavesdropping on communications — and prosecuting wars, are practically the only things, a government of a free country is supposed to do.
Because no one else can be allowed to do these things...

 Everything else — and I do mean everything: elementary and higher education, personal retirement, health care, communications, transportation — should be left to the competing enterprises.
If only because they are much easier to switch from one to another, than it is to change the government...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627496</id>
	<title>Re:They've Always Been Pointless</title>
	<author>owlstead</author>
	<datestamp>1269623280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>SSL certificates only provide the ability to encrypt communication between a browser and a server. That's all it's for.</p></div><p>No they are not. They are for providing authentication. You would not need any certificates to encrypt communications. Of course, you can then do a man in the middle attack, but you can only get around that by authentication anyway.</p><p><div class="quote"><p>Alas, many people have have tried to build in some level of 'trust' to SSL as well, and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone's browser doesn't complain needs to go the journey.</p></div><p>This has indeed be identified. There are a couple of things with that. 1) SSL certificates are, normally, just issued to the owner of the site. That already provides some security. 2) you can get certificates that provide more trust nowadays.</p><p><div class="quote"><p>Those root certificates in your browser are just money for old rope. We definitely need something better.</p></div><p>I'm not so sure that the current SSL certificate scheme could not be fixed. Just saying we need something better does not fix anything.</p><p>People could e.g. vote for SSL certificates for a specific site (same as PGP uses certificates signed by many persons to create trust). Another idea is to very clearly notify the user when a previously unused root certificate is used (I'll get suspicious when a banking site suddenly uses the [insert suspicious country of choice] certificate for its root. An option to display changeover of server certificates may also be a good idea.</p><p>Especially if you try and trick users on a large scale, it only takes one person to alert the authorities that something is amiss.</p></div>
	</htmltext>
<tokenext>SSL certificates only provide the ability to encrypt communication between a browser and a server .
That 's all it 's for.No they are not .
They are for providing authentication .
You would not need any certificates to encrypt communications .
Of course , you can then do a man in the middle attack , but you can only get around that by authentication anyway.Alas , many people have have tried to build in some level of 'trust ' to SSL as well , and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone 's browser does n't complain needs to go the journey.This has indeed be identified .
There are a couple of things with that .
1 ) SSL certificates are , normally , just issued to the owner of the site .
That already provides some security .
2 ) you can get certificates that provide more trust nowadays.Those root certificates in your browser are just money for old rope .
We definitely need something better.I 'm not so sure that the current SSL certificate scheme could not be fixed .
Just saying we need something better does not fix anything.People could e.g .
vote for SSL certificates for a specific site ( same as PGP uses certificates signed by many persons to create trust ) .
Another idea is to very clearly notify the user when a previously unused root certificate is used ( I 'll get suspicious when a banking site suddenly uses the [ insert suspicious country of choice ] certificate for its root .
An option to display changeover of server certificates may also be a good idea.Especially if you try and trick users on a large scale , it only takes one person to alert the authorities that something is amiss .</tokentext>
<sentencetext>SSL certificates only provide the ability to encrypt communication between a browser and a server.
That's all it's for.No they are not.
They are for providing authentication.
You would not need any certificates to encrypt communications.
Of course, you can then do a man in the middle attack, but you can only get around that by authentication anyway.Alas, many people have have tried to build in some level of 'trust' to SSL as well, and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone's browser doesn't complain needs to go the journey.This has indeed be identified.
There are a couple of things with that.
1) SSL certificates are, normally, just issued to the owner of the site.
That already provides some security.
2) you can get certificates that provide more trust nowadays.Those root certificates in your browser are just money for old rope.
We definitely need something better.I'm not so sure that the current SSL certificate scheme could not be fixed.
Just saying we need something better does not fix anything.People could e.g.
vote for SSL certificates for a specific site (same as PGP uses certificates signed by many persons to create trust).
Another idea is to very clearly notify the user when a previously unused root certificate is used (I'll get suspicious when a banking site suddenly uses the [insert suspicious country of choice] certificate for its root.
An option to display changeover of server certificates may also be a good idea.Especially if you try and trick users on a large scale, it only takes one person to alert the authorities that something is amiss.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625958</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629412</id>
	<title>Re:Does that mean...</title>
	<author>Anonymous</author>
	<datestamp>1269629340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Of course there's a mechanism causing the CA to work in your favor: if they don't, and if they give a government fake certificates, and if that becomes known, they would be pulled from the default list of CAs installed in browsers. That would cause the certificates they sold to all their customers to pop up with a warning, and their customers would migrate to a different CA within days, and the offending CA would lose all their business and fold up. It's a web of trust, and if you prove that you're not trustworthy you're going to lose your business.</p></htmltext>
<tokenext>Of course there 's a mechanism causing the CA to work in your favor : if they do n't , and if they give a government fake certificates , and if that becomes known , they would be pulled from the default list of CAs installed in browsers .
That would cause the certificates they sold to all their customers to pop up with a warning , and their customers would migrate to a different CA within days , and the offending CA would lose all their business and fold up .
It 's a web of trust , and if you prove that you 're not trustworthy you 're going to lose your business .</tokentext>
<sentencetext>Of course there's a mechanism causing the CA to work in your favor: if they don't, and if they give a government fake certificates, and if that becomes known, they would be pulled from the default list of CAs installed in browsers.
That would cause the certificates they sold to all their customers to pop up with a warning, and their customers would migrate to a different CA within days, and the offending CA would lose all their business and fold up.
It's a web of trust, and if you prove that you're not trustworthy you're going to lose your business.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627628</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627628</id>
	<title>Re:Does that mean...</title>
	<author>u38cg</author>
	<datestamp>1269623760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I complain about this every time the subject comes up, but the problem is a contractual one.  You are having to place trust in a CA you have no contractual relationship, so what mechanism causes that CA to work in your favour?  None.  Browsers should ship without any root certificates, and users should pay to subscribe to whoever they choose to provide them with root signing services.  Economics would help enforce the trust issues.  It isn't a magic bullet, of course, but to me it takes the biggest weakness out of the way.</htmltext>
<tokenext>I complain about this every time the subject comes up , but the problem is a contractual one .
You are having to place trust in a CA you have no contractual relationship , so what mechanism causes that CA to work in your favour ?
None. Browsers should ship without any root certificates , and users should pay to subscribe to whoever they choose to provide them with root signing services .
Economics would help enforce the trust issues .
It is n't a magic bullet , of course , but to me it takes the biggest weakness out of the way .</tokentext>
<sentencetext>I complain about this every time the subject comes up, but the problem is a contractual one.
You are having to place trust in a CA you have no contractual relationship, so what mechanism causes that CA to work in your favour?
None.  Browsers should ship without any root certificates, and users should pay to subscribe to whoever they choose to provide them with root signing services.
Economics would help enforce the trust issues.
It isn't a magic bullet, of course, but to me it takes the biggest weakness out of the way.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626242</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628864</id>
	<title>No kidding.</title>
	<author>Anonymous</author>
	<datestamp>1269627540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Most of these people just don't get it.  The other obvious clue is that the entire PKI infrastructure was created and put into motion by the NSA. I mean, duh.</htmltext>
<tokenext>Most of these people just do n't get it .
The other obvious clue is that the entire PKI infrastructure was created and put into motion by the NSA .
I mean , duh .</tokentext>
<sentencetext>Most of these people just don't get it.
The other obvious clue is that the entire PKI infrastructure was created and put into motion by the NSA.
I mean, duh.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626854</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>Meneth</author>
	<datestamp>1269620460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>sudo mod me up</p></div><p>ok<nobr> <wbr></nobr>:)</p></div>
	</htmltext>
<tokenext>sudo mod me upok : )</tokentext>
<sentencetext>sudo mod me upok :)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629630</id>
	<title>Re:Is it time yet?</title>
	<author>mlts</author>
	<datestamp>1269630000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You can always physically armor your CA server.  One client of mine has a Windows machine which is permanently offline (was activated via phone so it never has touched the Internet directly.)  This machine uses BitLocker with a passphrase to encrypt the volumes, and has inside it a USB card with an Aladdin eToken on an internal port.  For signing stuff, the client inserts a USB flash drive or a SD card, signs it with the commercial version of PGP, or the signcode.exe utility that is used for Authenticode signing, pulls the drive/card out, and copies the signed files back onto the network.</p><p>This way, if someone tries to boot the server from other OS media, they need the recovery key to decrypt the OS, and upon booting back to the OS, it will hang until someone provides the TPM its PIN, (which will show that the machine was rebooted.)  If someone takes the smart card out of the machine, they have 15 guesses to figure out a 32-64 character passphrase.  After that, the eToken will erase itself.</p><p>No, this is not as secure as a dedicated HSM, but for what the client wanted, it provided enough security, and was a lot less expensive.</p><p>Of course an intruder can always use a rubber hose attack against people who have the ability to sign programs and documents, but what this setup gives the client is the ability to have the critical keys protected from some script kiddie who manages to crack into the corporate LAN as their first threat of concern.  The second threat being someone trying to physically steal/compromise a machine while nobody is around.</p></htmltext>
<tokenext>You can always physically armor your CA server .
One client of mine has a Windows machine which is permanently offline ( was activated via phone so it never has touched the Internet directly .
) This machine uses BitLocker with a passphrase to encrypt the volumes , and has inside it a USB card with an Aladdin eToken on an internal port .
For signing stuff , the client inserts a USB flash drive or a SD card , signs it with the commercial version of PGP , or the signcode.exe utility that is used for Authenticode signing , pulls the drive/card out , and copies the signed files back onto the network.This way , if someone tries to boot the server from other OS media , they need the recovery key to decrypt the OS , and upon booting back to the OS , it will hang until someone provides the TPM its PIN , ( which will show that the machine was rebooted .
) If someone takes the smart card out of the machine , they have 15 guesses to figure out a 32-64 character passphrase .
After that , the eToken will erase itself.No , this is not as secure as a dedicated HSM , but for what the client wanted , it provided enough security , and was a lot less expensive.Of course an intruder can always use a rubber hose attack against people who have the ability to sign programs and documents , but what this setup gives the client is the ability to have the critical keys protected from some script kiddie who manages to crack into the corporate LAN as their first threat of concern .
The second threat being someone trying to physically steal/compromise a machine while nobody is around .</tokentext>
<sentencetext>You can always physically armor your CA server.
One client of mine has a Windows machine which is permanently offline (was activated via phone so it never has touched the Internet directly.
)  This machine uses BitLocker with a passphrase to encrypt the volumes, and has inside it a USB card with an Aladdin eToken on an internal port.
For signing stuff, the client inserts a USB flash drive or a SD card, signs it with the commercial version of PGP, or the signcode.exe utility that is used for Authenticode signing, pulls the drive/card out, and copies the signed files back onto the network.This way, if someone tries to boot the server from other OS media, they need the recovery key to decrypt the OS, and upon booting back to the OS, it will hang until someone provides the TPM its PIN, (which will show that the machine was rebooted.
)  If someone takes the smart card out of the machine, they have 15 guesses to figure out a 32-64 character passphrase.
After that, the eToken will erase itself.No, this is not as secure as a dedicated HSM, but for what the client wanted, it provided enough security, and was a lot less expensive.Of course an intruder can always use a rubber hose attack against people who have the ability to sign programs and documents, but what this setup gives the client is the ability to have the critical keys protected from some script kiddie who manages to crack into the corporate LAN as their first threat of concern.
The second threat being someone trying to physically steal/compromise a machine while nobody is around.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626650</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626992</id>
	<title>Self-signed certs are now more secure. Silly.</title>
	<author>X.25</author>
	<datestamp>1269621060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Use self-signed certs. I am not talking about being more secure when doing online shopping and other silly things, but for personal/company usage.</p><p>For example, if I create my own CA and sign my own certs for my mailserver, I will import my CA cert (or accept cert once, on 1st mail retrieval, although more risky), and no matter what certificate government puts when doing mitm - I'll get a warning.</p><p>But if I buy a cert from Verisign and think that I am totally safe now, I would never get any warnings if government inserts their own certificate (generated on-fly by using Verisign issued intermediate cert with CA=TRUE constrain set, for example, if I remember the mechanics right<nobr> <wbr></nobr>:), when doing mitm. Can be done with sslsniff, if I remember correctly (been a while since I bothered with SSL/TLS stuff)</p><p>And government won't be able to get a cert issued by my own CA, so they won't be able to get past the checks, and I will eventually get a popup when any of their certificates show up.</p><p>I think this was a known issue since 2002 or so (look up Moxie's work).</p></htmltext>
<tokenext>Use self-signed certs .
I am not talking about being more secure when doing online shopping and other silly things , but for personal/company usage.For example , if I create my own CA and sign my own certs for my mailserver , I will import my CA cert ( or accept cert once , on 1st mail retrieval , although more risky ) , and no matter what certificate government puts when doing mitm - I 'll get a warning.But if I buy a cert from Verisign and think that I am totally safe now , I would never get any warnings if government inserts their own certificate ( generated on-fly by using Verisign issued intermediate cert with CA = TRUE constrain set , for example , if I remember the mechanics right : ) , when doing mitm .
Can be done with sslsniff , if I remember correctly ( been a while since I bothered with SSL/TLS stuff ) And government wo n't be able to get a cert issued by my own CA , so they wo n't be able to get past the checks , and I will eventually get a popup when any of their certificates show up.I think this was a known issue since 2002 or so ( look up Moxie 's work ) .</tokentext>
<sentencetext>Use self-signed certs.
I am not talking about being more secure when doing online shopping and other silly things, but for personal/company usage.For example, if I create my own CA and sign my own certs for my mailserver, I will import my CA cert (or accept cert once, on 1st mail retrieval, although more risky), and no matter what certificate government puts when doing mitm - I'll get a warning.But if I buy a cert from Verisign and think that I am totally safe now, I would never get any warnings if government inserts their own certificate (generated on-fly by using Verisign issued intermediate cert with CA=TRUE constrain set, for example, if I remember the mechanics right :), when doing mitm.
Can be done with sslsniff, if I remember correctly (been a while since I bothered with SSL/TLS stuff)And government won't be able to get a cert issued by my own CA, so they won't be able to get past the checks, and I will eventually get a popup when any of their certificates show up.I think this was a known issue since 2002 or so (look up Moxie's work).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626138</id>
	<title>Re:DNSSEC has a similar attack against it</title>
	<author>Mr Thinly Sliced</author>
	<datestamp>1269618000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>DNSSEC has a similar attack against it</p></div></blockquote><p>Except with TLS you are putting the logic and handling in every application. Putting it further down the stack makes it easier to update/patch etc.</p><p>There really needs to be just one place to put the necessary functionality and fix the bugs (which we have to fix anyway to get the implementation of IPSec/DNSSec correct).</p></div>
	</htmltext>
<tokenext>DNSSEC has a similar attack against itExcept with TLS you are putting the logic and handling in every application .
Putting it further down the stack makes it easier to update/patch etc.There really needs to be just one place to put the necessary functionality and fix the bugs ( which we have to fix anyway to get the implementation of IPSec/DNSSec correct ) .</tokentext>
<sentencetext>DNSSEC has a similar attack against itExcept with TLS you are putting the logic and handling in every application.
Putting it further down the stack makes it easier to update/patch etc.There really needs to be just one place to put the necessary functionality and fix the bugs (which we have to fix anyway to get the implementation of IPSec/DNSSec correct).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625948</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626278</id>
	<title>Re:SSL / HTTPS</title>
	<author>ArsenneLupin</author>
	<datestamp>1269618420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>How would this secure ajax framework work? A (trusted) plugin to be installed in the client's browser?<p>
Because, if the client-side javascript is being served by the server over the Web, it's vulnerable: an attacker could just intercept the javascript and insert whatever he wants inside, and pass that on to the client, who would be none the wiser. And as it is non-standard, there'd be no tell-tale signs such as http instead of https, that an astute user could see.</p></htmltext>
<tokenext>How would this secure ajax framework work ?
A ( trusted ) plugin to be installed in the client 's browser ?
Because , if the client-side javascript is being served by the server over the Web , it 's vulnerable : an attacker could just intercept the javascript and insert whatever he wants inside , and pass that on to the client , who would be none the wiser .
And as it is non-standard , there 'd be no tell-tale signs such as http instead of https , that an astute user could see .</tokentext>
<sentencetext>How would this secure ajax framework work?
A (trusted) plugin to be installed in the client's browser?
Because, if the client-side javascript is being served by the server over the Web, it's vulnerable: an attacker could just intercept the javascript and insert whatever he wants inside, and pass that on to the client, who would be none the wiser.
And as it is non-standard, there'd be no tell-tale signs such as http instead of https, that an astute user could see.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625760</id>
	<title>Is it time yet?</title>
	<author>Skarecrow77</author>
	<datestamp>1269616620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>For the return to tin can and string?</p></htmltext>
<tokenext>For the return to tin can and string ?</tokentext>
<sentencetext>For the return to tin can and string?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625804</id>
	<title>Damn!</title>
	<author>Anonymous</author>
	<datestamp>1269616860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I'm going to have to go back to using dead drops for communication.</htmltext>
<tokenext>I 'm going to have to go back to using dead drops for communication .</tokentext>
<sentencetext>I'm going to have to go back to using dead drops for communication.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627872</id>
	<title>Re:Paranoia is all well and good...</title>
	<author>pixelpusher220</author>
	<datestamp>1269624540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>Thus far the certificate authorities have been trustworthy.</i>
<br> <br>
not exactly, we only don't know that they haven't been untrustworthy.   There's a pretty big difference.</htmltext>
<tokenext>Thus far the certificate authorities have been trustworthy .
not exactly , we only do n't know that they have n't been untrustworthy .
There 's a pretty big difference .</tokentext>
<sentencetext>Thus far the certificate authorities have been trustworthy.
not exactly, we only don't know that they haven't been untrustworthy.
There's a pretty big difference.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629910</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>durdur</author>
	<datestamp>1269630960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>SSL (more exactly TLS) is an established, mature, well-designed secure protocol. It's not the problem. The "remaining problem" you mention though has always existed with PKI: how do you manage certificates, distribute them to all the sites that need them, handle revocation, etc. That's a big issue and there is no drop in easy solution.</p></htmltext>
<tokenext>SSL ( more exactly TLS ) is an established , mature , well-designed secure protocol .
It 's not the problem .
The " remaining problem " you mention though has always existed with PKI : how do you manage certificates , distribute them to all the sites that need them , handle revocation , etc .
That 's a big issue and there is no drop in easy solution .</tokentext>
<sentencetext>SSL (more exactly TLS) is an established, mature, well-designed secure protocol.
It's not the problem.
The "remaining problem" you mention though has always existed with PKI: how do you manage certificates, distribute them to all the sites that need them, handle revocation, etc.
That's a big issue and there is no drop in easy solution.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628156</id>
	<title>Re:what no one wants you to know</title>
	<author>timeOday</author>
	<datestamp>1269625260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I agree, ssl is really about facilitating secure communications between parties who don't really trust each other, like you and a bank, or you and an online store.  Ultimately, that's a job only government can do, akin to (and derived from) contract enforcement, which is how trade among parties is facilitated when there are no tribal or other bonds.  If the CA decided to sell you online identity to the highest bidder, what's your recourse?  Sue them.  So, ultimately the government is the arbiter.  Ok then, ssl only helps in "certain" situations, but it's an extremely useful set of situations.</htmltext>
<tokenext>I agree , ssl is really about facilitating secure communications between parties who do n't really trust each other , like you and a bank , or you and an online store .
Ultimately , that 's a job only government can do , akin to ( and derived from ) contract enforcement , which is how trade among parties is facilitated when there are no tribal or other bonds .
If the CA decided to sell you online identity to the highest bidder , what 's your recourse ?
Sue them .
So , ultimately the government is the arbiter .
Ok then , ssl only helps in " certain " situations , but it 's an extremely useful set of situations .</tokentext>
<sentencetext>I agree, ssl is really about facilitating secure communications between parties who don't really trust each other, like you and a bank, or you and an online store.
Ultimately, that's a job only government can do, akin to (and derived from) contract enforcement, which is how trade among parties is facilitated when there are no tribal or other bonds.
If the CA decided to sell you online identity to the highest bidder, what's your recourse?
Sue them.
So, ultimately the government is the arbiter.
Ok then, ssl only helps in "certain" situations, but it's an extremely useful set of situations.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625862</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625958</id>
	<title>They've Always Been Pointless</title>
	<author>segedunum</author>
	<datestamp>1269617400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>SSL certificates only provide the ability to encrypt communication between a browser and a server. That's all it's for. Alas, many people have have tried to build in some level of 'trust' to SSL as well, and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone's browser doesn't complain needs to go the journey. Those root certificates in your browser are just money for old rope. We definitely need something better.</htmltext>
<tokenext>SSL certificates only provide the ability to encrypt communication between a browser and a server .
That 's all it 's for .
Alas , many people have have tried to build in some level of 'trust ' to SSL as well , and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone 's browser does n't complain needs to go the journey .
Those root certificates in your browser are just money for old rope .
We definitely need something better .</tokentext>
<sentencetext>SSL certificates only provide the ability to encrypt communication between a browser and a server.
That's all it's for.
Alas, many people have have tried to build in some level of 'trust' to SSL as well, and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone's browser doesn't complain needs to go the journey.
Those root certificates in your browser are just money for old rope.
We definitely need something better.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626342</id>
	<title>Re:Does that mean...</title>
	<author>ArsenneLupin</author>
	<datestamp>1269618660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>No. Without any further verifications, self-signed certificates can be spoofed by the common crook, whereas CA-signed certificates can only be spoofed by governments.<p>
With further verification (customer manually checks certificates finger-print), both self-signed and CA-signed would be secure, but then you wouldn't really rely on the signature at all, but rather on the fingerprint.</p></htmltext>
<tokenext>No .
Without any further verifications , self-signed certificates can be spoofed by the common crook , whereas CA-signed certificates can only be spoofed by governments .
With further verification ( customer manually checks certificates finger-print ) , both self-signed and CA-signed would be secure , but then you would n't really rely on the signature at all , but rather on the fingerprint .</tokentext>
<sentencetext>No.
Without any further verifications, self-signed certificates can be spoofed by the common crook, whereas CA-signed certificates can only be spoofed by governments.
With further verification (customer manually checks certificates finger-print), both self-signed and CA-signed would be secure, but then you wouldn't really rely on the signature at all, but rather on the fingerprint.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625946</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627706</id>
	<title>About time</title>
	<author>Anonymous</author>
	<datestamp>1269624060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I've been crying foul about this for years, and get flame-modded every time.  But even here, the researcher missed the issue.  If I'm going to wiretap somebody, I'm not going to freaking request a fake key for the domain.  I'm going to request the CA's signing key, and *issue* a fake certificate for *EVERY* domain my target goes to.  Maybe their first connection times out at times for some reason...whatever...DNS hickup.</p><p>Most of the math can be precomputed anyway--the average user would never notice.</p><p>My only question is given that somebody "reputable" finally "published" this vulnerability, will firefox finally take self signed keys seriously?  Because their attitude in recent releases is freaking disgusting.  Just give me a tool to know when the key changes already--and give me some extra cautions if it changes outside a specific window of its expiration date.</p></htmltext>
<tokenext>I 've been crying foul about this for years , and get flame-modded every time .
But even here , the researcher missed the issue .
If I 'm going to wiretap somebody , I 'm not going to freaking request a fake key for the domain .
I 'm going to request the CA 's signing key , and * issue * a fake certificate for * EVERY * domain my target goes to .
Maybe their first connection times out at times for some reason...whatever...DNS hickup.Most of the math can be precomputed anyway--the average user would never notice.My only question is given that somebody " reputable " finally " published " this vulnerability , will firefox finally take self signed keys seriously ?
Because their attitude in recent releases is freaking disgusting .
Just give me a tool to know when the key changes already--and give me some extra cautions if it changes outside a specific window of its expiration date .</tokentext>
<sentencetext>I've been crying foul about this for years, and get flame-modded every time.
But even here, the researcher missed the issue.
If I'm going to wiretap somebody, I'm not going to freaking request a fake key for the domain.
I'm going to request the CA's signing key, and *issue* a fake certificate for *EVERY* domain my target goes to.
Maybe their first connection times out at times for some reason...whatever...DNS hickup.Most of the math can be precomputed anyway--the average user would never notice.My only question is given that somebody "reputable" finally "published" this vulnerability, will firefox finally take self signed keys seriously?
Because their attitude in recent releases is freaking disgusting.
Just give me a tool to know when the key changes already--and give me some extra cautions if it changes outside a specific window of its expiration date.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627010</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>TheLink</author>
	<datestamp>1269621180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The Certlock thing should help (assuming they do it right and the software itself can be trusted), but the problem could have been fixed by the browser makers long ago if they took security seriously. If I remember right, the problem was discussed years ago in a firefox bug report.</p><p>Basically the browser should have features to allow you to be warned if:<br>1) The CA has changed (still vulnerable to "Gov can forge SSL certs with CA's help")<br>2) The cert has changed (paranoid mode- the Gov can eavesdrop only if they have the private key of the server - IIRC in the old days for some strange reason certain CAs actually made you send them everything, go figure why<nobr> <wbr></nobr>;) ).</p><p>Now in paranoid mode, some load balancing sites might cause warnings because the certs could be different. For example different certs were installed on the servers serving up the same sites. This could be because they are in the middle of rolling out new certs. However this is not a huge problem, if the sites with the correct certs provide suitable warning in advance the user would realize that and accept the new certs.</p><p>FWIW, I'm wondering if this addon actually is OK: <a href="https://addons.mozilla.org/en-US/firefox/addon/6415" title="mozilla.org">https://addons.mozilla.org/en-US/firefox/addon/6415</a> [mozilla.org]<nobr> <wbr></nobr>:).</p></htmltext>
<tokenext>The Certlock thing should help ( assuming they do it right and the software itself can be trusted ) , but the problem could have been fixed by the browser makers long ago if they took security seriously .
If I remember right , the problem was discussed years ago in a firefox bug report.Basically the browser should have features to allow you to be warned if : 1 ) The CA has changed ( still vulnerable to " Gov can forge SSL certs with CA 's help " ) 2 ) The cert has changed ( paranoid mode- the Gov can eavesdrop only if they have the private key of the server - IIRC in the old days for some strange reason certain CAs actually made you send them everything , go figure why ; ) ) .Now in paranoid mode , some load balancing sites might cause warnings because the certs could be different .
For example different certs were installed on the servers serving up the same sites .
This could be because they are in the middle of rolling out new certs .
However this is not a huge problem , if the sites with the correct certs provide suitable warning in advance the user would realize that and accept the new certs.FWIW , I 'm wondering if this addon actually is OK : https : //addons.mozilla.org/en-US/firefox/addon/6415 [ mozilla.org ] : ) .</tokentext>
<sentencetext>The Certlock thing should help (assuming they do it right and the software itself can be trusted), but the problem could have been fixed by the browser makers long ago if they took security seriously.
If I remember right, the problem was discussed years ago in a firefox bug report.Basically the browser should have features to allow you to be warned if:1) The CA has changed (still vulnerable to "Gov can forge SSL certs with CA's help")2) The cert has changed (paranoid mode- the Gov can eavesdrop only if they have the private key of the server - IIRC in the old days for some strange reason certain CAs actually made you send them everything, go figure why ;) ).Now in paranoid mode, some load balancing sites might cause warnings because the certs could be different.
For example different certs were installed on the servers serving up the same sites.
This could be because they are in the middle of rolling out new certs.
However this is not a huge problem, if the sites with the correct certs provide suitable warning in advance the user would realize that and accept the new certs.FWIW, I'm wondering if this addon actually is OK: https://addons.mozilla.org/en-US/firefox/addon/6415 [mozilla.org] :).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625948</id>
	<title>DNSSEC has a similar attack against it</title>
	<author>Anonymous</author>
	<datestamp>1269617400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>with DNSSec we can put IPSEC public keys in DNS entries</p></div><p>Unless the government compels domain name registrars to sign phony DNS public keys.</p><p><div class="quote"><p>For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two.</p></div><p>Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries.</p></div>
	</htmltext>
<tokenext>with DNSSec we can put IPSEC public keys in DNS entriesUnless the government compels domain name registrars to sign phony DNS public keys.For the ultra-paranoid , you can publish the same IPSec public key on both and make clients compare the two.Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries .</tokentext>
<sentencetext>with DNSSec we can put IPSEC public keys in DNS entriesUnless the government compels domain name registrars to sign phony DNS public keys.For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two.Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625870</id>
	<title>Generate your own certificates...</title>
	<author>Anonymous</author>
	<datestamp>1269617100000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>and distribute them by mail or something.  That doesn't help taking to your bank,<br>but then again if the government wants your bank balance they'll just ask the bank.</p></htmltext>
<tokenext>and distribute them by mail or something .
That does n't help taking to your bank,but then again if the government wants your bank balance they 'll just ask the bank .</tokentext>
<sentencetext>and distribute them by mail or something.
That doesn't help taking to your bank,but then again if the government wants your bank balance they'll just ask the bank.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626122</id>
	<title>Quis custodiet ipsos custodes?</title>
	<author>Bearhouse</author>
	<datestamp>1269617880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think we've had this debate on<nobr> <wbr></nobr>/. before, no?<br>Who do you trust to issue certs?  Certainly not Verisign...the UN, then?</p></htmltext>
<tokenext>I think we 've had this debate on / .
before , no ? Who do you trust to issue certs ?
Certainly not Verisign...the UN , then ?</tokentext>
<sentencetext>I think we've had this debate on /.
before, no?Who do you trust to issue certs?
Certainly not Verisign...the UN, then?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31630132</id>
	<title>Re:Paranoia is all well and good...</title>
	<author>Xylantiel</author>
	<datestamp>1269631800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>... you have to manually exchange keys.</p></div><p>
No.  You can get most of the way there with a model like that of PGP: if multiple entities that you trust have vouched for the this one, then you have some confidence.  This is what the "web of trust" is all about.  The CAs fail both counts -- multiple trust paths are not required and why should I trust any particular CA?  The article is just pointing out another reason to not trust the CAs.
</p><p>
With real PKI management I could choose for any particular communication whether I trusted the CAs under the jurisdiction of a particular government.  But the truth is that such a level of security is rarely necessary in an absolute sense that can't be "repaired" later by, for example, legal remedies.
</p></div>
	</htmltext>
<tokenext>... you have to manually exchange keys .
No. You can get most of the way there with a model like that of PGP : if multiple entities that you trust have vouched for the this one , then you have some confidence .
This is what the " web of trust " is all about .
The CAs fail both counts -- multiple trust paths are not required and why should I trust any particular CA ?
The article is just pointing out another reason to not trust the CAs .
With real PKI management I could choose for any particular communication whether I trusted the CAs under the jurisdiction of a particular government .
But the truth is that such a level of security is rarely necessary in an absolute sense that ca n't be " repaired " later by , for example , legal remedies .</tokentext>
<sentencetext>... you have to manually exchange keys.
No.  You can get most of the way there with a model like that of PGP: if multiple entities that you trust have vouched for the this one, then you have some confidence.
This is what the "web of trust" is all about.
The CAs fail both counts -- multiple trust paths are not required and why should I trust any particular CA?
The article is just pointing out another reason to not trust the CAs.
With real PKI management I could choose for any particular communication whether I trusted the CAs under the jurisdiction of a particular government.
But the truth is that such a level of security is rarely necessary in an absolute sense that can't be "repaired" later by, for example, legal remedies.

	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629836</id>
	<title>So let's fix it</title>
	<author>ecloud</author>
	<datestamp>1269630660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Firefox and webkit and apache are extremely popular.  Why not introduce a new security model, just for that combination at first, in which the browser holds the private key, encrypts the submission with it, and sends the public key to the server with which to encrypt the response, on top of using a server-side key at the same time?  And augment that with a chain-of-trust model in which you can see how many of your friends (people you know personally and trust) have accepted that particular server-side cert as valid.  Or any other such techniques which I don't understand because I'm not a security wonk.<nobr> <wbr></nobr>:-)  Anyone with some clout in the community (Mozilla and/or Apache forefathers) could easily make something like this happen, since free software projects are in control of both ends.  In that light I don't see why this wasn't fixed long ago.</p><p>"Just use SSH" could also be an answer for the web as well, but maybe it's better not to put all our eggs in one basket.</p></htmltext>
<tokenext>Firefox and webkit and apache are extremely popular .
Why not introduce a new security model , just for that combination at first , in which the browser holds the private key , encrypts the submission with it , and sends the public key to the server with which to encrypt the response , on top of using a server-side key at the same time ?
And augment that with a chain-of-trust model in which you can see how many of your friends ( people you know personally and trust ) have accepted that particular server-side cert as valid .
Or any other such techniques which I do n't understand because I 'm not a security wonk .
: - ) Anyone with some clout in the community ( Mozilla and/or Apache forefathers ) could easily make something like this happen , since free software projects are in control of both ends .
In that light I do n't see why this was n't fixed long ago .
" Just use SSH " could also be an answer for the web as well , but maybe it 's better not to put all our eggs in one basket .</tokentext>
<sentencetext>Firefox and webkit and apache are extremely popular.
Why not introduce a new security model, just for that combination at first, in which the browser holds the private key, encrypts the submission with it, and sends the public key to the server with which to encrypt the response, on top of using a server-side key at the same time?
And augment that with a chain-of-trust model in which you can see how many of your friends (people you know personally and trust) have accepted that particular server-side cert as valid.
Or any other such techniques which I don't understand because I'm not a security wonk.
:-)  Anyone with some clout in the community (Mozilla and/or Apache forefathers) could easily make something like this happen, since free software projects are in control of both ends.
In that light I don't see why this wasn't fixed long ago.
"Just use SSH" could also be an answer for the web as well, but maybe it's better not to put all our eggs in one basket.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625886</id>
	<title>The Obama govt isn't evil</title>
	<author>Anonymous</author>
	<datestamp>1269617160000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>Well, at least it would be Obama watching our every move instead of Bush, so it's not that bad.<nobr> <wbr></nobr>//head-smack</p></htmltext>
<tokenext>Well , at least it would be Obama watching our every move instead of Bush , so it 's not that bad .
//head-smack</tokentext>
<sentencetext>Well, at least it would be Obama watching our every move instead of Bush, so it's not that bad.
//head-smack</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627648</id>
	<title>Provable</title>
	<author>fulldecent</author>
	<datestamp>1269623820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A single false, signed certificate from anywhere provides undeniable cause to revoke a CA from all browsers.</p></htmltext>
<tokenext>A single false , signed certificate from anywhere provides undeniable cause to revoke a CA from all browsers .</tokentext>
<sentencetext>A single false, signed certificate from anywhere provides undeniable cause to revoke a CA from all browsers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628856</id>
	<title>Re:What about a DNS TXT record with hints?</title>
	<author>Anonymous</author>
	<datestamp>1269627480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Anyone who is powerful enough to stage a MitM can inject fake DNS responses to you.</p></htmltext>
<tokenext>Anyone who is powerful enough to stage a MitM can inject fake DNS responses to you .</tokentext>
<sentencetext>Anyone who is powerful enough to stage a MitM can inject fake DNS responses to you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627280</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626874</id>
	<title>"Is SSL becoming pointless?"</title>
	<author>John Hasler</author>
	<datestamp>1269620520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Only a fool would rely on SSL based on the certificates that come with a browser to protect against government.  That isn't what it is for.  While I object to government snooping in principle (I object to pretty much all government activity in principle) I really have nothing to fear from the NSA learning what parts I am ordering from Jameco.  Firefox, HTTPS, and Perspectives provide adequate assurance that I am communicating with the company I intend and that some clerk at some ISP can't snoop my credit card number.  For more important stuff I have GPG.</p></htmltext>
<tokenext>Only a fool would rely on SSL based on the certificates that come with a browser to protect against government .
That is n't what it is for .
While I object to government snooping in principle ( I object to pretty much all government activity in principle ) I really have nothing to fear from the NSA learning what parts I am ordering from Jameco .
Firefox , HTTPS , and Perspectives provide adequate assurance that I am communicating with the company I intend and that some clerk at some ISP ca n't snoop my credit card number .
For more important stuff I have GPG .</tokentext>
<sentencetext>Only a fool would rely on SSL based on the certificates that come with a browser to protect against government.
That isn't what it is for.
While I object to government snooping in principle (I object to pretty much all government activity in principle) I really have nothing to fear from the NSA learning what parts I am ordering from Jameco.
Firefox, HTTPS, and Perspectives provide adequate assurance that I am communicating with the company I intend and that some clerk at some ISP can't snoop my credit card number.
For more important stuff I have GPG.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629228</id>
	<title>Corrupted CAs ? What's the point paying them ?</title>
	<author>Thanatiel</author>
	<datestamp>1269628680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Do I understand correctly that Verisign has been corrupted ?<br>If it is true, it means that Verisign authentifed certificate aren't worth zlicht.<br>It's a good thing removing a CA from the CA root is a simple enough thing to do.</p><p>I'm particulary glad my "secured" sites are using a CA I generated (on a non-networked computer) and that I distributed to the users.</p></htmltext>
<tokenext>Do I understand correctly that Verisign has been corrupted ? If it is true , it means that Verisign authentifed certificate are n't worth zlicht.It 's a good thing removing a CA from the CA root is a simple enough thing to do.I 'm particulary glad my " secured " sites are using a CA I generated ( on a non-networked computer ) and that I distributed to the users .</tokentext>
<sentencetext>Do I understand correctly that Verisign has been corrupted ?If it is true, it means that Verisign authentifed certificate aren't worth zlicht.It's a good thing removing a CA from the CA root is a simple enough thing to do.I'm particulary glad my "secured" sites are using a CA I generated (on a non-networked computer) and that I distributed to the users.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626462</id>
	<title>Re:Can we get rid of SSL now please?</title>
	<author>L4t3r4lu5</author>
	<datestamp>1269619080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The US government won't be able to insert something into a<nobr> <wbr></nobr>.cn domain, for example, although the Chinese government can.</p></div><p>I hear you're a looking for a reason for IPSEC and DNSSec not being implemented. Allow me to introduce a candidate answer.</p></div>
	</htmltext>
<tokenext>The US government wo n't be able to insert something into a .cn domain , for example , although the Chinese government can.I hear you 're a looking for a reason for IPSEC and DNSSec not being implemented .
Allow me to introduce a candidate answer .</tokentext>
<sentencetext>The US government won't be able to insert something into a .cn domain, for example, although the Chinese government can.I hear you're a looking for a reason for IPSEC and DNSSec not being implemented.
Allow me to introduce a candidate answer.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626242</id>
	<title>Re:Does that mean...</title>
	<author>fuzzyfuzzyfungus</author>
	<datestamp>1269618360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>Self-signed certs are more secure; but only if you have some way of distinguishing them. "Self signed certs" as a generic class, are man-in-the-middle city because <i>anybody</i> can produce one. The feds don't even have to coerce the CA, they can just sign their own.<br> <br>

A <i>specific</i> self-signed cert, that you have some out-of-band reason for trusting, is extremely secure because <i>only</i> by compromising the computer storing the signing key could an adversary produce a fake one of those.<br> <br>

The problem is, outside of fairly trivial scenarios(corporate intranet with self-signed certs, worker drones' browsers trust that cert by group policy; small group of paranoics who know each other IRL exchange keys under the bridge at midnight), establishing that out of band reason for trusting a cert is a pain in the ass, and not amenable to any particularly clear solution.<br> <br>

CAs are basically the ugly-not-really-all-that-good solution that has the virtue of working in practice. You trust the cert because the big corporation whose business is attesting to the trustworthiness of certs says you should trust it. Easy, simple, and actually works ok from a strictly financial perspective(ie. the amount of money that Verisign can make by selling overpriced sequences of bits that make the magic green bar appear in consumer browsers is greater than the amount that they could make by MiTM attacking a whole bunch of banking sessions and then fleeing to Namibia with their reputation in tatters).<br> <br>

Where it breaks down is non-strictly-financial situations. It is highly unlikely that clandestine cooperation, for surveillance purposes, with state agencies is all that costly to Verisign, or their ilk(and may in fact be lucrative, as doing various sorts of wiretaps is for the telcomms). If your threat space is just occupied by script-kiddies and Ukranian cyber criminals, commercial CAs work pretty well. If it is occupied by state entities who want <i>information</i> rather than money, there is no particular reason to expect them to work.</htmltext>
<tokenext>Self-signed certs are more secure ; but only if you have some way of distinguishing them .
" Self signed certs " as a generic class , are man-in-the-middle city because anybody can produce one .
The feds do n't even have to coerce the CA , they can just sign their own .
A specific self-signed cert , that you have some out-of-band reason for trusting , is extremely secure because only by compromising the computer storing the signing key could an adversary produce a fake one of those .
The problem is , outside of fairly trivial scenarios ( corporate intranet with self-signed certs , worker drones ' browsers trust that cert by group policy ; small group of paranoics who know each other IRL exchange keys under the bridge at midnight ) , establishing that out of band reason for trusting a cert is a pain in the ass , and not amenable to any particularly clear solution .
CAs are basically the ugly-not-really-all-that-good solution that has the virtue of working in practice .
You trust the cert because the big corporation whose business is attesting to the trustworthiness of certs says you should trust it .
Easy , simple , and actually works ok from a strictly financial perspective ( ie .
the amount of money that Verisign can make by selling overpriced sequences of bits that make the magic green bar appear in consumer browsers is greater than the amount that they could make by MiTM attacking a whole bunch of banking sessions and then fleeing to Namibia with their reputation in tatters ) .
Where it breaks down is non-strictly-financial situations .
It is highly unlikely that clandestine cooperation , for surveillance purposes , with state agencies is all that costly to Verisign , or their ilk ( and may in fact be lucrative , as doing various sorts of wiretaps is for the telcomms ) .
If your threat space is just occupied by script-kiddies and Ukranian cyber criminals , commercial CAs work pretty well .
If it is occupied by state entities who want information rather than money , there is no particular reason to expect them to work .</tokentext>
<sentencetext>Self-signed certs are more secure; but only if you have some way of distinguishing them.
"Self signed certs" as a generic class, are man-in-the-middle city because anybody can produce one.
The feds don't even have to coerce the CA, they can just sign their own.
A specific self-signed cert, that you have some out-of-band reason for trusting, is extremely secure because only by compromising the computer storing the signing key could an adversary produce a fake one of those.
The problem is, outside of fairly trivial scenarios(corporate intranet with self-signed certs, worker drones' browsers trust that cert by group policy; small group of paranoics who know each other IRL exchange keys under the bridge at midnight), establishing that out of band reason for trusting a cert is a pain in the ass, and not amenable to any particularly clear solution.
CAs are basically the ugly-not-really-all-that-good solution that has the virtue of working in practice.
You trust the cert because the big corporation whose business is attesting to the trustworthiness of certs says you should trust it.
Easy, simple, and actually works ok from a strictly financial perspective(ie.
the amount of money that Verisign can make by selling overpriced sequences of bits that make the magic green bar appear in consumer browsers is greater than the amount that they could make by MiTM attacking a whole bunch of banking sessions and then fleeing to Namibia with their reputation in tatters).
Where it breaks down is non-strictly-financial situations.
It is highly unlikely that clandestine cooperation, for surveillance purposes, with state agencies is all that costly to Verisign, or their ilk(and may in fact be lucrative, as doing various sorts of wiretaps is for the telcomms).
If your threat space is just occupied by script-kiddies and Ukranian cyber criminals, commercial CAs work pretty well.
If it is occupied by state entities who want information rather than money, there is no particular reason to expect them to work.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625946</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627010
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629710
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627088
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626882
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626650
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625760
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31633110
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625860
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626096
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628360
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629174
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625862
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628648
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628856
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627280
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627366
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625860
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31630660
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626342
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625946
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626138
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625948
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627496
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625958
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629630
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626650
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625760
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31637854
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626462
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629390
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626196
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626188
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629910
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31630132
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625860
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629412
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627628
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626242
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625946
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626854
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626566
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625760
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626278
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31636958
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628156
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625862
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_26_1334254_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626972
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626096
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628070
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625804
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625852
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629710
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628648
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627088
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31637854
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626854
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627010
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629910
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626972
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626462
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31636958
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625948
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626138
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627280
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628856
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626196
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629390
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625886
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625884
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626278
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626188
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625946
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626242
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627628
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629412
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626342
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31630660
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626184
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625862
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628156
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629174
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625760
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626566
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626650
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31629630
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626882
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627648
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625776
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626166
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626326
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31628360
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627872
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31630132
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625870
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625860
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627366
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31626214
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31633110
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_26_1334254.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31625958
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_26_1334254.31627496
</commentlist>
</conversation>
