<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Technicalities &#187; tls</title>
	<atom:link href="http://www.sirena.org.uk/log/tag/tls/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sirena.org.uk/log</link>
	<description>Just another random blog</description>
	<lastBuildDate>Sat, 21 Jan 2012 23:41:17 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Buffer overflows ahoy</title>
		<link>http://www.sirena.org.uk/log/2009/02/18/buffer-overflows-ahoy/</link>
		<comments>http://www.sirena.org.uk/log/2009/02/18/buffer-overflows-ahoy/#comments</comments>
		<pubDate>Wed, 18 Feb 2009 10:50:36 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[e-mail]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[email]]></category>
		<category><![CDATA[ssl]]></category>
		<category><![CDATA[tls]]></category>
		<category><![CDATA[windows]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=158</guid>
		<description><![CDATA[I may be wrong on this but it looks like Microsoft SMTP clients (at least Windows Mail and Outlook) don&#8217;t like being sent a large volume of SSL certificate information when opening a TLS connection. They appear to assume that the data they are being sent is malformed and assume that STARTTLS failed, continuing with [...]]]></description>
			<content:encoded><![CDATA[<p>I may be wrong on this but it looks like Microsoft SMTP clients (at least Windows Mail and Outlook) don&#8217;t like being sent a large volume of SSL certificate information when opening a TLS connection. They appear to assume that the data they are being sent is malformed and assume that STARTTLS failed, continuing with an unencrypted  SMTP dialogue.</p>
<p>This can be triggered relatively easily on a Debian system by telling Exim to use all the certificates provided by the ca-certificates package (which is the default configuration). The Windows clients will give an unhelpful &#8220;the remote end dropped the connection&#8221; style error, caused by the server getting upset by the unexpected fallback to unencrypted SMTP. The server logs will show something like this:</p>
<pre>2009-02-17 21:32:55 TLS error on connection from client.example.com (Client) [192.168.192.168] (gnutls_handshake): A TLS packet with unexpected length was received.
2009-02-17 21:33:00 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=client.example.com [192.168.192.168] input="EHLO Client\r\n"</pre>
<p>Configuring the MAIN_VERIFY_TLS_CERTIFICATES option in the Debian Exim configuration (which sets the tls_verifiy_certificates option in the actual Exim configuration) to point to something with less certificates in should avoid the issue.</p>
<p>On the bright side, at least they&#8217;re making an effort to avoid overflows.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2009/02/18/buffer-overflows-ahoy/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

