csh
/
y.st.
forknuté z y.st./y.st.


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169
							<?xml version="1.0" encoding="utf-8"?>
<!--
                                                                                     
 h       t     t                ::       /     /                     t             / 
 h       t     t                ::      //    //                     t            // 
 h     ttttt ttttt ppppp sssss         //    //  y   y       sssss ttttt         //  
 hhhh    t     t   p   p s            //    //   y   y       s       t          //   
 h  hh   t     t   ppppp sssss       //    //    yyyyy       sssss   t         //    
 h   h   t     t   p         s  ::   /     /         y  ..       s   t    ..   /     
 h   h   t     t   p     sssss  ::   /     /     yyyyy  ..   sssss   t    ..   /     
                                                                                     
	<https://y.st./>
	Copyright © 2016 Alex Yst <mailto:copyright@y.st>

	This program is free software: you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation, either version 3 of the License, or
	(at your option) any later version.

	This program is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with this program. If not, see <https://www.gnu.org./licenses/>.
-->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<base href="https://y.st./en/URI_research/SNI_bug.xhtml" />
		<title>The SNI bug &lt;https://y.st./en/URI_research/SNI_bug.xhtml&gt;</title>
		<link rel="icon" type="image/png" href="/link/CC_BY-SA_4.0/y.st./icon.png" />
		<link rel="stylesheet" type="text/css" href="/link/basic.css" />
		<link rel="stylesheet" type="text/css" href="/link/site-specific.css" />
		<script type="text/javascript" src="/script/javascript.js" />
		<meta name="viewport" content="width=device-width" />
	</head>
	<body>
		<nav>
			<p>
				<a href="/en/">Home</a> |
				<a href="/en/a/about.xhtml">About</a> |
				<a href="/en/a/contact.xhtml">Contact</a> |
				<a href="/a/canary.txt">Canary</a> |
				<a href="/en/URI_research/"><abbr title="Uniform Resource Identifier">URI</abbr> research</a> |
				<a href="/en/opinion/">Opinions</a> |
				<a href="/en/coursework/">Coursework</a> |
				<a href="/en/law/">Law</a> |
				<a href="/en/a/links.xhtml">Links</a> |
				<a href="/en/URI_research/SNI_bug.xhtml.asc">{this page}.asc</a>
			</p>
			<hr/>
		</nav>
		<header>
			<h1>The <abbr title="Server Name Indication">SNI</abbr> bug</h1>
			<p>Most Web browsers are broken.</p>
		</header>
<p>Before we get started, I have a small disclaimer. The <abbr title="Request for Comments">RFC</abbr> documents are copyrighted. However, I feel that my quoting passages from there here should be considered fair use under United States copyright law because I am both including these passages for the purpose of making comments on them and I am linking directly to the documents that the passages came from on the <abbr title="Internet Engineering Task Force">IETF</abbr>&apos;s website.</p>
<h2>Malformed <abbr title="Server Name Indication">SNI</abbr> host names</h2>
<p>Many Web browsers exhibit a bug of one form or another when dealing with <abbr title="Uniform Resource Identifier">URI</abbr>s that have a trailing dot in their host component. First, some background. To quote a couple specifications:</p>
<p><a href="https://tools.ietf.org./html/rfc6066#section-3"><abbr title="Request for Comments">RFC</abbr> 6066 (<abbr title="Server Name Indication">SNI</abbr>)</a> says:</p>

<blockquote><pre>&quot;HostName&quot; contains the fully qualified DNS hostname of the server,
as understood by the client.  The hostname is represented as a byte
string using ASCII encoding without a trailing dot.</pre></blockquote>

<p>While <a href="https://tools.ietf.org./html/rfc7230#section-5.4"><abbr title="Request for Comments">RFC</abbr> 7230 (<abbr title="Hypertext Transfer Protocol">HTTP</abbr>)</a> has this to say:</p>

<blockquote><pre>A client MUST send a Host header field in all HTTP/1.1 request
messages.  If the target URI includes an authority component, then a
client MUST send a field-value for Host that is identical to that
authority component, excluding any userinfo subcomponent and its &quot;@&quot;
delimiter (Section 2.7.1).</pre></blockquote>

<p>On that second one, the emphasis is in the original document. I didn&apos;t add it.</p>
<p>If you pay attention to what these documents are saying, the <abbr title="Server Name Indication">SNI</abbr> host name and <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host header do not always match. The <abbr title="Server Name Indication">SNI</abbr> host name must never have a trailing dot, but the <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host header must reflect a host name that is identical to the host name of the <abbr title="Uniform Resource Identifier">URI</abbr>, so if the <abbr title="Uniform Resource Identifier">URI</abbr>&apos;s host has a trailing dot, the <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host header must include that trailing dot. For example, if the <abbr title="Uniform Resource Identifier">URI</abbr> of a page is <a href="https://alice.sni.velox.ch./"><code>https://alice.sni.velox.ch./</code></a>, the following values should be sent by the Web browser:</p>
<p><abbr title="Server Name Indication">SNI</abbr> host: alice.sni.velox.ch</p>
<p><abbr title="Hypertext Transfer Protocol">HTTP</abbr> host: alice.sni.velox.ch.</p>
<p>While I agree that requiring that the <abbr title="Server Name Indication">SNI</abbr> host name have its trailing dot stripped is kind of dumb, the fact is, some servers conform to this. If you send an <a href="apt:apache2">Apache Web server</a> a request with an invalid <abbr title="Server Name Indication">SNI</abbr> host name that is invalid only because it contains a trailing dot, Apache will throw a 400 error at you. You can&apos;t really argue with the Apache developers for setting this up, either. After all, they followed the standard to the letter. However, most Web clients seem to have a bug that causes them to fail to trim off this trailing dot from the <abbr title="Server Name Indication">SNI</abbr> host name. This limits the practicality of using &quot;https&quot;-scheme <abbr title="Uniform Resource Identifier">URI</abbr>s. These <abbr title="Uniform Resource Identifier">URI</abbr>s are perfectly valid, but Web clients don&apos;t handle them correctly. In fact, you could even say that these dotted domain <abbr title="Uniform Resource Identifier">URI</abbr>s are <strong>*more*</strong> valid than their non-dotted counterparts. <a href="https://tools.ietf.org./html/rfc7230#section-2.7.1"><abbr title="Request for Comments">RFC</abbr> 7230</a> (<abbr title="Hypertext Transfer Protocol">HTTP</abbr>) makes no comments on trailing dots, and in fact, doesn&apos;t even require that the host component of the <abbr title="Uniform Resource Identifier">URI</abbr> be a <abbr title="Domain Name System">DNS</abbr> name:</p>

<blockquote><pre>If host is a registered name, the registered name is an
indirect identifier for use with a name resolution service, such as
DNS, to find an address for that origin server.</pre></blockquote>

<p><q>Such as <abbr title="Domain Name System">DNS</abbr></q>. <abbr title="Domain Name System">DNS</abbr> isn&apos;t a requirement. Most of us do use <abbr title="Domain Name System">DNS</abbr> to make sense of &quot;https&quot;-scheme <abbr title="Uniform Resource Identifier">URI</abbr>s though. <a href="https://tools.ietf.org./html/rfc3986#section-3.2.2"><abbr title="Request for Comments">RFC</abbr> 3986 (<abbr title="Uniform Resource Identifier">URI</abbr>s)</a> has this to say about using a <abbr title="Domain Name System">DNS</abbr> domain name in a <abbr title="Uniform Resource Identifier">URI</abbr>:</p>

<blockquote><pre>A host identified by a registered name is a sequence of characters
usually intended for lookup within a locally defined host or service
name registry, though the URI&apos;s scheme-specific semantics may require
that a specific registry (or fixed name table) be used instead.  The
most common name registry mechanism is the Domain Name System (DNS).
A registered name intended for lookup in the DNS uses the syntax
defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
Such a name consists of a sequence of domain labels separated by &quot;.&quot;,
each domain label starting and ending with an alphanumeric character
and possibly also containing &quot;-&quot; characters.  The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single &quot;.&quot; and should be if it is necessary to distinguish between
the complete domain name and some local domain.</pre></blockquote>

<p>The dot should be included when there is a chance that not including the dot results in ambiguity with some local domain. You don&apos;t know the setup of your users. You don&apos;t know if they have local domains defined. There is <strong>*always*</strong> a chance of this ambiguity. Furthermore, <a href="https://tools.ietf.org./html/rfc7230#section-9.1"><abbr title="Request for Comments">RFC</abbr> 7230</a> (<abbr title="Hypertext Transfer Protocol">HTTP</abbr>) makes a comment about <abbr title="Domain Name System">DNS</abbr> returning different results to different users:</p>

<blockquote><pre>When a registered name is used in the authority component, the &quot;http&quot;
URI scheme (Section 2.7.1) relies on the user&apos;s local name resolution
service to determine where it can find authoritative responses.  This
means that any attack on a user&apos;s network host table, cached names,
or name resolution libraries becomes an avenue for attack on
establishing authority.  Likewise, the user&apos;s choice of server for
Domain Name Service (DNS), and the hierarchy of servers from which it
obtains resolution results, could impact the authenticity of address
mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
improve authenticity.</pre></blockquote>

<p>The user&apos;s choice of server and the hierarchy of servers can impact the result. Admittedly, upon first glance, I thought that it was talking about the <abbr title="Domain Name System">DNS</abbr> name hierarchy, which would have directly validated my point. However, while that&apos;s not exactly what is said, it has a similar impact. Depending on which server you use, <abbr title="Domain Name System">DNS</abbr> results can come out differently. One of the main and completely standard reasons that a <abbr title="Domain Name System">DNS</abbr> server (or for that matter, any <abbr title="Domain Name System">DNS</abbr> server in a chain of <abbr title="Domain Name System">DNS</abbr> servers) might return different results than another, is that one or both <abbr title="Domain Name System">DNS</abbr> servers is resolving the name within a local domain name space. The obvious way to insure that the domain is resolved in a global context is to include the trailing dot, and as a result, it is helpful for clients to be able to correctly handle <abbr title="Uniform Resource Identifier">URI</abbr>s that include the trailing dot.</p>

<h2>Web clients that exhibit this bug:</h2>
<h3><a href="apt:arora">Arora</a></h3>
<p>The Arora developer believes that the bug is in the underlying QT networking library, not in Arora itself. A <a href="https://bugreports.qt.io/browse/QTBUG-51821">bug report</a> has been filed with the Qt developers, and a <a href="https://codereview.qt-project.org/#/c/152150/">bug fix</a> has been written and accepted into the version 5.6 code. It seems that version 5.6 has already been released though, so it&apos;s possible that the Gerrit branch won&apos;t be renamed until version 5.7 is ready to be released. At this point, all we need to do is wait for the next Qt release, then wait for the new release to propagate to the software distributions that include Qt.</p>
<h3><a href="apt:chromium">Chromium</a> (Chrome, et cetera)</h3>
<p>Reporting bugs to the Chromium developers requires a Google account, and getting a Google account requires a telephone number. This is moronic. While I wasn&apos;t able to report the bug myself, I did find someone that was willing to file a <a href="https://bugs.chromium.org./p/chromium/issues/detail?id=593952">bug report</a> on my behalf. It turns out though that is was already a <a href="https://bugs.chromium.org./p/chromium/issues/detail?id=496472">known bug</a>. The bug has been known about for almost a year, but has not yet been fixed.</p>
<h3><a href="apt:epiphany-browser">Epiphany</a></h3>
<p>I filed a <a href="https://bugzilla.gnome.org/show_bug.cgi?id=763510">bug report</a> with the <abbr title="GNU Network Object Model Environment">GNOME</abbr> developers and it has been acknowledged. It appears that the bug is believed to be specifically in the glib code.</p>
<h3>Firefox (<a href="apt:iceweasel">Iceweasel</a>, Tor Browser Bundle, Pale Moon, et cetera)</h3>
<p>I filed a <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1255854">bug report</a> with Mozilla, but it turns out that this was a <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1008120">known bug</a>. However, the patch included was from <abbr title="Client for URLs/Client URL Request Library/Curl URL Request Library">cURL</abbr>, which as you can read below, introduces a different bug.</p>
<h3><a href="apt:midori">Midori</a></h3>
<p>I filed a <a href="https://bugs.launchpad.net./midori/+bug/1555823">bug report</a> with the Midori developers, but they have not yet responded.</p>
<h3><a href="apt:konqueror">Konqueror</a></h3>
<p>I filed a <a href="https://bugs.kde.org./show_bug.cgi?id=360423">bug report</a> with the KDE developers. It has not yet been acknowledged, but if it turns out that the issue relates to the underlying Qt networking library like it likely does in Arora, the may resolve itself once the Qt networking library is rereleased and updated in projects that depend on it.</p>
<h3><a href="apt:surf">Surf</a></h3>
<p>Suckless, the developers of Surf, believe that the error isn&apos;t in their own code, but in Webkit, so I filed a <a href="https://bugs.webkit.org./show_bug.cgi?id=155378">bug report</a> with the Webkit developers. However, it turns out that Webkit doesn&apos;t even handle <abbr title="Server Name Indication">SNI</abbr> implementation. I now believe that the bug in Surf is caused by the bug in glib, so hopefully when that is fixed, the fix will trickle into Surf.</p>
<h3>w3m</h3>
<p>Getting an account on SourceForge is a bit of a pain, due to <abbr title="Internet Protocol">IP</abbr> address sniffing on the registration page. If you&apos;re a <a href="apt:tor">Tor</a>-user, you need to write to the SourceForge staff via email and hope you run into a staff member that is nice enough to open an account on your behalf. I&apos;ve filed a <a href="https://sourceforge.net/p/w3m/feature-requests/27/">bug report</a>, but I somehow get the feeling that this project is unmaintained. The last update seems to have been on <a href="https://sourceforge.net/projects/w3m/files/">2011-01-15</a>. If I&apos;m right, a bug fix may not come any time soon. If you use w3m, it might be time to switch to a Web browser that still has support.</p>
<h3><a href="apt:wget">Wget</a></h3>
<p>I filed a <a href="https://savannah.gnu.org/bugs/index.php?47408">bug report</a> with the <abbr title="Free Software Foundation">FSF</abbr>. Most of the conversation occurred via email though, and I don&apos;t know how to find the relevant bits in the online archive. Long story short, is sounds like if they decide to fix this bug, they will add a new bug, the one from <abbr title="Client for URLs/Client URL Request Library/Curl URL Request Library">cURL</abbr>.</p>

<h2>Incorrect <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host names</h2>
<p>Sending malformed <abbr title="Server Name Indication">SNI</abbr> host names isn&apos;t the only mis-processing of <abbr title="Uniform Resource Identifier">URI</abbr>s by Web browsers that seems to be triggered by fully-qualified domain names. Some Web browsers send the correct <abbr title="Server Name Indication">SNI</abbr> Host names, but they strip the trailing dot off of not only the <abbr title="Server Name Indication">SNI</abbr> host name, but also the <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host header. The <abbr title="Hypertext Transfer Protocol">HTTP</abbr> Host header is used by the Web server to know what site is being requested, and as mentioned above, this header is <strong>*required*</strong> to contain the host name as it appears in the <abbr title="Uniform Resource Identifier">URI</abbr>. The site that uses the trailing dot host name is not necessarily the same site that uses the host name without the trailing dot. The server administrator can choose to host two different sites using these host names, similar to how a server administrator could host another site using a subdomain. Furthermore, a server administrator may host a single website, but have a preferred host name. This is like when a &quot;www.*&quot; website redirects to a non-&quot;www.*&quot; website or vice versa.</p>
<p>I&apos;ve seen some websites that redirect from a trailing-dot domain to a domain without the trailing dot. These websites have every right to choose the version of the domain without the trailing dot as their canonical version. However, going back to the possibility of domains being resolved in a local name space, redirecting from the domain <code>//example.net.</code> (with a trailing dot) to <code>//example.net</code> (without a trailing dot) could result in the latter being resolved to <code>//example.net.example.org.</code>, causing the user to be unable to reach <code>//example.net.</code>. This is a very unlikely case, but it still means that some server administrators would choose the trailing-dot version of their domain as the canonical host. When Web clients fail to transmit the correct Host header, this will cause an endless redirect loop. The client obviously stops attempting to retrieve the page after a while, but the user is left unable to reach the content that they were after. Again, if you read the standards-setting <abbr title="Request for Comments">RFC</abbr>s, this is the fault of the client software, not the server and not the server&apos;s administrator.</p>
<h2>Web clients that exhibit this bug:</h2>
<h3><a href="apt:curl">cURL</a></h3>
<p>I have filed a <a href="https://github.com/curl/curl/issues/716">bug report</a> with <abbr title="Client for URLs/Client URL Request Library/Curl URL Request Library">cURL</abbr>&apos;s developers, but they seem convinced that this is a feature, not a bug.</p>
<h3><a href="apt:elinks">Elinks</a></h3>
<p>I have not yet filed a bug report with the Elinks developers.</p>
<h3><a href="apt:lynx">Lynx</a></h3>
<p>I have not yet filed a bug report with the Lynx developers.</p>

<h2>Other strange behavior</h2>
<p>I found a singular strange case when trying to find which Web clients have the <abbr title="Server Name Indication">SNI</abbr> bug and which don&apos;t. Namely, the <a href="apt:netsurf">Netsurf</a> Web browser normalizes <abbr title="Uniform Resource Identifier">URI</abbr>s that have a trailing dot to their form without the trailing dot. Nowhere in any standards-setting documentation can I find any support for this behavior. However, as stated above, &quot;https&quot;- and &quot;http&quot;-scheme <abbr title="Uniform Resource Identifier">URI</abbr>s are not required to be resolved using <abbr title="Domain Name System">DNS</abbr>. Effectively, Netsurf is resolving <abbr title="Uniform Resource Identifier">URI</abbr>s using an internal non-<abbr title="Domain Name System">DNS</abbr> mechanism. Names with a trailing dot are then redirected to their version without the trailing dot, while names without the trailing dot are sent to the <abbr title="Domain Name System">DNS</abbr> resolver. While this behavior has the same problems as simply stripping the dot off of the Host header, I have no foothold with which to call this a bug. It&apos;s certainly undesirable behavior for my use case, but my best guess is that the standards allow it. Perhaps when I have time, I&apos;ll report this issue as a feature request.</p>

<h2>Conclusions</h2>
<p>I&apos;ve stated above that I feel that the trailing-dot version of a domain seems more correct to me than the version without a trailing dot. However, please don&apos;t take that to mean that I think all websites and/or <abbr title="Uniform Resource Identifier">URI</abbr> should make use of the trailing dot. Really, it&apos;s a matter of choice, and both options should be available. All I want is for Web clients to follow the standards so that such a choice is possible. My point about the trailing-dot version being more valid is that if one version of the domain is to be ruled out, it makes far more sense to require the trailing dot than to disallow it.</p>
		<hr/>
		<p>
			Copyright © 2016 Alex Yst;
			You may modify and/or redistribute this document under the terms of the <a rel="license" href="/license/gpl-3.0-standalone.xhtml"><abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="General Public License version Three or later">GPLv3+</abbr></a>.
			If for some reason you would prefer to modify and/or distribute this document under other free copyleft terms, please ask me via email.
			My address is in the source comments near the top of this document.
			This license also applies to embedded content such as images.
			For more information on that, see <a href="/en/a/licensing.xhtml">licensing</a>.
		</p>
		<p>
			<abbr title="World Wide Web Consortium">W3C</abbr> standards are important.
			This document conforms to the <a href="https://validator.w3.org./nu/?doc=https%3A%2F%2Fy.st.%2Fen%2FURI_research%2FSNI_bug.xhtml"><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> 5.1</a> specification and uses style sheets that conform to the <a href="http://jigsaw.w3.org./css-validator/validator?uri=https%3A%2F%2Fy.st.%2Fen%2FURI_research%2FSNI_bug.xhtml"><abbr title="Cascading Style Sheets">CSS</abbr>3</a> specification.
		</p>
	</body>
</html>