GNOME Bugzilla – Bug 763510
Epiphany sends malformed SNI host names
Last modified: 2018-05-29 06:38:00 UTC
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, Epiphany sends "sni.velox.ch." as the SNI host name, causing the server to throw an error.
Thanks for debugging this. I grepped both WebKit and libsoup for "SNI" and "sni " but didn't get any hits. Guessing libsoup.
(In reply to Michael Catanzaro from comment #1) > Thanks for debugging this. > > I grepped both WebKit and libsoup for "SNI" and "sni " but didn't get any > hits. Guessing libsoup. Moving the bug there, then
(In reply to Matthias Clasen from comment #2) > Moving the bug there, then Dan moved it to glib-networking.
yeah, it's glib-networking's fault
So... all that needs to be done here is check for a dot at the end and strip it off before calling gnutls_server_name_set()? That's used in two places in gtlsclientconnection-gnutls.c. I have no idea how we would write a test case for this, though.
Also, does this affect any real sites? I've never seen a hostname that ends with a dot before.
That sounds right. It's only the TLS hat needs the dot removed, it should remain in the HTTP host name. It affects my own website. It's not a bug that affects most websites, but it's still a bug and bugs should be fixed; especially if it's as easy as checking for a dot and removing it in only two spots in the code.
Indeed, the documentation for gnutls_server_name_set() says that there should be no dot at the end of the input.
(In reply to Yst Dawson from comment #0) > 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, Epiphany sends "sni.velox.ch." as the SNI host name, causing the > server to throw an error. Is this server still up and running? I notice I can't connect to it with Firefox, Chromium, or even ping. :)
(In reply to Michael Catanzaro from comment #9) > (In reply to Yst Dawson from comment #0) > > 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, Epiphany sends "sni.velox.ch." as the SNI host name, causing the > > server to throw an error. > > Is this server still up and running? I notice I can't connect to it with > Firefox, Chromium, or even ping. :) No, it looks like that server went down. It's easy enough to test with a script if you've got Web space, I just don't have Web space any more, at least not for the time being. I'm hoping to get a VPS fairly soon though. I'll find a temporary PHP-enabled Web host right now to host such a script, if it'll help.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1145.
Reopening. This bug was migrated to https://gitlab.gnome.org/GNOME/glib, but it should have been migrated to https://gitlab.gnome.org/GNOME/glib-networking.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib-networking/issues/11.