<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: How Does Secure Socket Layer (SSL or TLS) Work?</title>
	<atom:link href="http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/feed" rel="self" type="application/rss+xml" />
	<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html</link>
	<description>News, solutions and insider insight from LuxSci: provider of Secure Email and Web Security</description>
	<lastBuildDate>Thu, 08 Mar 2012 02:57:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=110</generator>
	<item>
		<title>By: iPhone Security Apps and Configuration Tips &#124; LuxSci FYI</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-1286</link>
		<dc:creator>iPhone Security Apps and Configuration Tips &#124; LuxSci FYI</dc:creator>
		<pubDate>Wed, 18 May 2011 16:55:22 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-1286</guid>
		<description>[...] your iPhone for general access to email (sending or receiving), be sure that your provider supports SSL or TLS for POP/IMAP/SMTP access.  Without use of  SSL or TLS, your usernames, passwords, and message [...]</description>
		<content:encoded><![CDATA[<p>[...] your iPhone for general access to email (sending or receiving), be sure that your provider supports SSL or TLS for POP/IMAP/SMTP access.  Without use of  SSL or TLS, your usernames, passwords, and message [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steps for Protecting Your Passwords from Theft &#124; LuxSci FYI</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-1263</link>
		<dc:creator>Steps for Protecting Your Passwords from Theft &#124; LuxSci FYI</dc:creator>
		<pubDate>Tue, 03 May 2011 15:49:11 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-1263</guid>
		<description>[...] should always use connections encrypted using SSL or TLS, so no one can eavesdrop on you.  This is especially true in public places, like wifi hot [...]</description>
		<content:encoded><![CDATA[<p>[...] should always use connections encrypted using SSL or TLS, so no one can eavesdrop on you.  This is especially true in public places, like wifi hot [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik Kangas</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-965</link>
		<dc:creator>Erik Kangas</dc:creator>
		<pubDate>Thu, 16 Sep 2010 12:34:54 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-965</guid>
		<description>For SSL and other asymmetric encryption systems, there are two keys involved.  The key built into the SSL certificate is the asymmetric key.  Due to how the math works, the asymmetric keys are easier to break than symmetric encryption keys.  As a result, asymmetric keys must be longer (have larger bit lengths, like 1024, 2048, or more).

The asymmetric key is used together with the asymmetric encryption algorithm during the initial client-server communications.  During that phase, identity is checked and verified, etc.  Also, because asymmetric encryption is much slower than symmetric encryption, the client and server agree on a symmetric encryption algorithm and new symmetric key to use for the remainder of their communications session.  They then switch from asymmetric to symmetric encryption (using something like AES) for the rest of the session. The 128bit or 256bit encryption key is that used for the specific symmetric encryption session.

So:
* The 1024+ key is the asymmetric key used for all initial communications over SSL with a specific server. 
* The 128-256 bit key is the symmetric encryption session key used for a single specific session of encrypted communications between client and server.  It is negotiated during the start of the session, that communication protected using the asymmetric encryption.
* Because of the mathematical nature of asymmetric encryption, the key length for asymmetric keys must be much longer than that for symmetric keys to ensure security</description>
		<content:encoded><![CDATA[<p>For SSL and other asymmetric encryption systems, there are two keys involved.  The key built into the SSL certificate is the asymmetric key.  Due to how the math works, the asymmetric keys are easier to break than symmetric encryption keys.  As a result, asymmetric keys must be longer (have larger bit lengths, like 1024, 2048, or more).</p>
<p>The asymmetric key is used together with the asymmetric encryption algorithm during the initial client-server communications.  During that phase, identity is checked and verified, etc.  Also, because asymmetric encryption is much slower than symmetric encryption, the client and server agree on a symmetric encryption algorithm and new symmetric key to use for the remainder of their communications session.  They then switch from asymmetric to symmetric encryption (using something like AES) for the rest of the session. The 128bit or 256bit encryption key is that used for the specific symmetric encryption session.</p>
<p>So:<br />
* The 1024+ key is the asymmetric key used for all initial communications over SSL with a specific server.<br />
* The 128-256 bit key is the symmetric encryption session key used for a single specific session of encrypted communications between client and server.  It is negotiated during the start of the session, that communication protected using the asymmetric encryption.<br />
* Because of the mathematical nature of asymmetric encryption, the key length for asymmetric keys must be much longer than that for symmetric keys to ensure security</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Rogers</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-963</link>
		<dc:creator>Dan Rogers</dc:creator>
		<pubDate>Thu, 16 Sep 2010 03:30:07 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-963</guid>
		<description>Thanks for the great article!

Could you please explain the difference between the following two terminologies and if they are related in any way

1028 - 2048 bit keys 
128 - 256 bit encryption

i know that the 128 &amp; 256 is the encryption level that the client-server agree on using, what about the term 1024 or 2048, where dose this fit in?

Thanks</description>
		<content:encoded><![CDATA[<p>Thanks for the great article!</p>
<p>Could you please explain the difference between the following two terminologies and if they are related in any way</p>
<p>1028 &#8211; 2048 bit keys<br />
128 &#8211; 256 bit encryption</p>
<p>i know that the 128 &amp; 256 is the encryption level that the client-server agree on using, what about the term 1024 or 2048, where dose this fit in?</p>
<p>Thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik Kangas</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-875</link>
		<dc:creator>Erik Kangas</dc:creator>
		<pubDate>Mon, 26 Jul 2010 12:47:14 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-875</guid>
		<description>Not correct.  In public key cryptography, any message encrypted with a private key can be decrypted only with the public key and any message encrypted with the public key can be decrypted only with the private key.  Encrypting with the private key allows anyone to open it, but the process of opening it proves it was sent by someone with the private key, and thus validates identity.  Encrypting with the public key ensures that only someone with the private one can open it, and thus ensures security (only the recipient can open it). 

Used together, these mechanisms permit validation and prevent eavesdroppng, among other things.</description>
		<content:encoded><![CDATA[<p>Not correct.  In public key cryptography, any message encrypted with a private key can be decrypted only with the public key and any message encrypted with the public key can be decrypted only with the private key.  Encrypting with the private key allows anyone to open it, but the process of opening it proves it was sent by someone with the private key, and thus validates identity.  Encrypting with the public key ensures that only someone with the private one can open it, and thus ensures security (only the recipient can open it). </p>
<p>Used together, these mechanisms permit validation and prevent eavesdroppng, among other things.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eitam Doodai</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-873</link>
		<dc:creator>Eitam Doodai</dc:creator>
		<pubDate>Mon, 26 Jul 2010 10:44:22 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-873</guid>
		<description>There is another mistake, It is stated that Thawte&#039;s public key is stored on the computer of the client. This does not mean that the computer can decrypt messages encrypted by Thawte with their private key.

It may be the other way around, but it&#039;s most surly not like it&#039;s mentioned right now.</description>
		<content:encoded><![CDATA[<p>There is another mistake, It is stated that Thawte&#8217;s public key is stored on the computer of the client. This does not mean that the computer can decrypt messages encrypted by Thawte with their private key.</p>
<p>It may be the other way around, but it&#8217;s most surly not like it&#8217;s mentioned right now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Is Blackberry HIPAA Compliant? What You Need To Know &#124; LuxSci FYI</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-849</link>
		<dc:creator>Is Blackberry HIPAA Compliant? What You Need To Know &#124; LuxSci FYI</dc:creator>
		<pubDate>Wed, 14 Jul 2010 01:39:24 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-849</guid>
		<description>[...] email over POP or IMAP on your Blackberry as long as your email provider supports secure, SSL-enabled POP and IMAP connections, and can ensure that the Blackberry will not be permitted to make insecure [...]</description>
		<content:encoded><![CDATA[<p>[...] email over POP or IMAP on your Blackberry as long as your email provider supports secure, SSL-enabled POP and IMAP connections, and can ensure that the Blackberry will not be permitted to make insecure [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik Kangas</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-802</link>
		<dc:creator>Erik Kangas</dc:creator>
		<pubDate>Sat, 29 May 2010 02:31:08 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-802</guid>
		<description>Thanks for your comments.  However, the terminology here is targeted at the newbie and is thus errors on the side of common parlance versus being explicitly technically accurate.  Most people refer to needing an &quot;SSL certificate&quot; or buying an &quot;SSL Certificate&quot; and by this they mean the public key, private key, and even the signing of the public key by the authority.  While &quot;certificate&quot; technically means only the signed public key, people generally use it inclusively and thay is why it was used as such here.

This is the same reason why we state that Thawte gives back a new &quot;public key with more information&quot;.  True, the key itself is the same, but the file is modified with more information.  For a common, simple description of the process, this gets the point across.

That you for your clarifications, however.</description>
		<content:encoded><![CDATA[<p>Thanks for your comments.  However, the terminology here is targeted at the newbie and is thus errors on the side of common parlance versus being explicitly technically accurate.  Most people refer to needing an &#8220;SSL certificate&#8221; or buying an &#8220;SSL Certificate&#8221; and by this they mean the public key, private key, and even the signing of the public key by the authority.  While &#8220;certificate&#8221; technically means only the signed public key, people generally use it inclusively and thay is why it was used as such here.</p>
<p>This is the same reason why we state that Thawte gives back a new &#8220;public key with more information&#8221;.  True, the key itself is the same, but the file is modified with more information.  For a common, simple description of the process, this gets the point across.</p>
<p>That you for your clarifications, however.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Belushi</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-801</link>
		<dc:creator>John Belushi</dc:creator>
		<pubDate>Fri, 28 May 2010 23:16:50 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-801</guid>
		<description>This is a pretty good article, but you&#039;ve got some incorrect information.  For example:
(i) You state: &quot;They create a public and private key for company.com (this is also known as a “certificate”)&quot;.  Not true.  The &quot;certificate&quot; does not contain the private key.  It contains only the public key of the entity (along with a digital signature of the CA and other useful identifying information).
(ii) You state: &quot;Once the verification is complete, Thawte gives the company a new public key that has some additional information in it...&quot;  Again, not true.  You&#039;re confusing the public key with the digital certificate here.  A public key has only one corresponding private key.  If a &quot;new public key&quot; was issued, the existing private key would no longer work.  Thawte would provide company.com with a digitally signed certificate certifying that company.com&#039;s public key (which company.com provided to Thawte) is in fact their public key.  There is no need for anyone at Thawte to see company.com&#039;s private key.</description>
		<content:encoded><![CDATA[<p>This is a pretty good article, but you&#8217;ve got some incorrect information.  For example:<br />
(i) You state: &#8220;They create a public and private key for company.com (this is also known as a “certificate”)&#8221;.  Not true.  The &#8220;certificate&#8221; does not contain the private key.  It contains only the public key of the entity (along with a digital signature of the CA and other useful identifying information).<br />
(ii) You state: &#8220;Once the verification is complete, Thawte gives the company a new public key that has some additional information in it&#8230;&#8221;  Again, not true.  You&#8217;re confusing the public key with the digital certificate here.  A public key has only one corresponding private key.  If a &#8220;new public key&#8221; was issued, the existing private key would no longer work.  Thawte would provide company.com with a digitally signed certificate certifying that company.com&#8217;s public key (which company.com provided to Thawte) is in fact their public key.  There is no need for anyone at Thawte to see company.com&#8217;s private key.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SecureForm Now Support SMTP TLS for Secure Form Email Delivery &#124; LuxSci FYI</title>
		<link>http://luxsci.com/blog/how-does-secure-socket-layer-ssl-or-tls-work.html/comment-page-1#comment-720</link>
		<dc:creator>SecureForm Now Support SMTP TLS for Secure Form Email Delivery &#124; LuxSci FYI</dc:creator>
		<pubDate>Fri, 09 Apr 2010 20:54:53 +0000</pubDate>
		<guid isPermaLink="false">http://luxsci.com/blog/?p=1500#comment-720</guid>
		<description>[...] the emailed form data can be secured using PGP or S/MIME.  This, combined with enforced use of SSL, ensures that the form data is secured from end-to-end &#8230; from submission by the end user to [...]</description>
		<content:encoded><![CDATA[<p>[...] the emailed form data can be secured using PGP or S/MIME.  This, combined with enforced use of SSL, ensures that the form data is secured from end-to-end &#8230; from submission by the end user to [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

