To quote a couple specifications: <https://tools.ietf.org/html/rfc6066#section-3> (SNI) "HostName" 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. <https://tools.ietf.org/html/rfc7230#section-5.4> (HTTP) 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 "@" delimiter (Section 2.7.1). That means that the SNI host name and HTTP Host header do not always match. The SNI host name must never have a trailing dot, but the HTTP Host header must reflect a host name that is identical to the host name of the URI, so if the URI's host has a trailing dot, the HTTP Host header must include that trailing dot. For example, if the URI of a page is <https://sni.velox.ch./>, the following values should be sent by the Web browser: SNI host: sni.velox.ch HTTP host: sni.velox.ch. However, Webkit sends "sni.velox.ch." as the SNI host name, causing the server to throw an error.
<rdar://problem/25130631>
I tested Safari, Firefox and Chrome, and all seem to behave in the same way - the server certificate is not trusted (because it doesn't match the hostname), and the server says: "The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection." This looks like correct behavior per the spec paragraphs that you quoted.
That's not the bug I'm talking about, and you're right, that's not a bug at all. That's an "untrusted" certificate error. I'm talking about the SNI host name. You'll run into the certificate error if the certificate isn't set up to use the trailing dot, but even if the certificate does designate the trailing dot as being part of the domain to use, the SNI host name *must not* contain the trailing dot. If you tell your browser to load the website even with the "untrusted" certificate, you'll see the server error that's caused by the malformed SNI host name.
Additionally, this bug is actually present in many Web browsers. I've already reported it in Firefox <https://bugzilla.mozilla.org/show_bug.cgi?id=1255854> and Chromium <https://bugs.chromium.org/p/chromium/issues/detail?id=593952>, though it turns out that the Chromium developers knew about the problem before I reported it <https://bugs.chromium.org/p/chromium/issues/detail?id=496472>. I'm unable to test in Safari, but it wouldn't surprise me if the bug was present in Safari as well. The Qt developers acknowledged the bug in their networking library <https://bugreports.qt.io/browse/QTBUG-51821>, and they sup it up pretty nicely <https://codereview.qt-project.org/#/c/152150/>: Do not send the trailing dot of a hostname as part of the SNI The SNI extension must not include the trailing dot, even though this is legitimate for the host header.
I meant "sum", not "sup", in that last comment.
How does this test demonstrate this bug? The server errors out saying that "host name does not match the Server Name Indication", but that's correct behavior. One is supposed to include the trailing dot, and another to not include it. So, mismatch is expected.
To be honest, I thought that the host name mismatch was caused by the fact that the SNI host name doesn't correspond to any HTTP Host header, and therefor, did not "match" the sent HTTP Host header. However, a little digging showed me that (potentially because the SNI host name is malformed), the server is trying to match the SNI host name against something else. Perhaps a default virtual host or something? Apache would throw a 500 error for the trailing dot in any case. However, the server no longer throws the error if you use <https://alice.sni.velox.ch./> as the URI instead. When using that URI, you can see this message: Great! Your client [Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/538.1 (KHTML, like Gecko) Arora/0.11.0 Safari/538.1] sent the following TLS server name indication extension (RFC 6066) in its ClientHello (negotiated protocol: TLSv1.2, cipher suite: ECDHE-RSA-AES256-GCM-SHA384): carol.sni.velox.ch. As you can see, Webkit is sending an SNI host name that contains a trailing dot, which is disallowed by RFC 6066. When fixing this though, it is important to be sure that the HTTP Host still has the trailing dot if the URI does. The two won't be identical, but they also won't cause the server to throw an error.
Oops, I mixed URIs and messages. I used the URI <https://carol.sni.velox.ch./> to get that Carol message, but both the URI in this post and the last demonstrate that Webkit is sending an SNI host name with a trailing dot.
Thank you! I can still reproduce this not just in Safari, but also in Chrome and Firefox. It's not clear to me if the correct resolution is to change networking libraries or to change the spec. I'll pass this information over to Apple's networking engineers - just as in Qt case, WebKit is not involved in TLS implementation.
Yeah, it's definitely in Firefox and Chrome. I've sent a bug report to Firefox and the Chrome people were already aware of the issue. Thank you for passing this on to Apple! I wouldn't even know how to reach them about bugs. It'll be nice to have this fixed in Safari as well. I apologize for the confusion cased by reporting what turned out to be a non-Webkit bug here. Apparently, I was acting on invalid information. It looks like I've still got some research to do before I can figure out why this buggy behaviour is present in the Arora Web browser.
Oops, it's Surf that thought that this bug came from Webkit, not Arora. Arora thought that their version of the bug came from Qt, but Qt has now been fixed.
> Thank you for passing this on to Apple! I wouldn't even know how to reach them about bugs. If the need arises again, please use http://bugreport.apple.com