After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 641080 - doesn't support TLS SNI (Server Name Indication)
doesn't support TLS SNI (Server Name Indication)
Status: RESOLVED DUPLICATE of bug 581342
Product: glib
Classification: Platform
Component: network
2.27.x
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-01-31 21:51 UTC by Sascha Silbe
Modified: 2011-08-07 17:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sascha Silbe 2011-01-31 21:51:00 UTC
Epiphany doesn't use the Server Name Indication TLS extension to signal the name of the (virtual) host it wishes to contact to the SSL server. At sites where some part of the SSL handshake (which server certificate to present, whether a client certificate gets requested, etc.) is different between virtual hosts, this will cause the connection to fail to work as intended.

An Apache vhost configured with "SSLStrictSNIVHostCheck on" presents a 403 Forbidden page to the user and logs the following error when contacted by Epiphany:

[Mon Jan 31 16:29:48 2011] [error] No hostname was provided via SNI for a name based virtual host

The above check is required on the particular virtual host I've tested against exactly because its configuration differs from that of other virtual hosts on the same server (it needs to request client certificates, whereas we don't want to trigger stupid "select client certificate" popups on the rest of the site).

Wikipedia has some background information about SNI: http://en.wikipedia.org/wiki/Server_Name_Indication
Comment 1 Dan Winship 2011-08-07 17:09:14 UTC
This was because we were always using SSLv3 with no extensions, to support certain broken servers. libsoup has been fixed now to use TLS+extensions first, and then try again with plain SSLv3 only if that fails, so now it should be using SNI on hosts that support it.

*** This bug has been marked as a duplicate of bug 581342 ***