Discussion:
[webkit-gtk] SSL Handshake error
Niranjan Rao
2014-11-12 19:44:45 UTC
Permalink
Greetings,

On Webkit 2.2.6/Ubuntu 12.04

When visiting some sites, I get error SLS handshake error. For example
site https://www.pge.com/eum/login gives SSL handshake error when using
MiniBrowser. Usual browsers are doing ok when visiting the site.

Is there any way to mitigate this problem?

I saw some documentation about TLS errors in webkitgtk web site. Not
clear if this applies to me or not.

Regards,

Niranjan
Michael Catanzaro
2014-11-13 01:11:48 UTC
Permalink
Post by Niranjan Rao
Greetings,
On Webkit 2.2.6/Ubuntu 12.04
When visiting some sites, I get error SLS handshake error. For example
site https://www.pge.com/eum/login gives SSL handshake error when using
MiniBrowser. Usual browsers are doing ok when visiting the site.
Is there any way to mitigate this problem?
Each such site requires individual investigation, unfortunately.
Post by Niranjan Rao
I saw some documentation about TLS errors in webkitgtk web site. Not
clear if this applies to me or not.
Well, that documentation describes how to handle "successful" TLS
connections with unverified TLS certificates, which is important for
developers because older versions of WebKitGTK+ handle this insecurely
by default. But it's not relevant here, since this connection has failed
completely. We use GnuTLS to handle TLS; here's what its command line
debug tool tells us:

$ gnutls-cli www.pge.com
Processed 153 CA certificate(s).
Resolving 'www.pge.com'...
Connecting to '131.89.128.67:443'...
*** Fatal error: The TLS connection was non-properly terminated.
*** Handshake has failed
GnuTLS error: The TLS connection was non-properly terminated.

That error message is misleading:

$ gnutls-cli-debug www.pge.com
Resolving 'www.pge.com'...
Connecting to '131.89.128.67:443'...
Checking for SSL 3.0 support... no
Connecting to '131.89.128.67:443'...
Checking whether %COMPAT is required... yes
Connecting to '131.89.128.67:443'...
Checking for TLS 1.0 support... no
Connecting to '131.89.128.67:443'...
Checking for TLS 1.1 support... no
Connecting to '131.89.128.67:443'...
Checking fallback from TLS 1.1 to... failed
Connecting to '131.89.128.67:443'...
Checking for TLS 1.2 support... no
Connecting to '131.89.128.67:443'...
Checking whether we need to disable TLS 1.2... yes

So GnuTLS thinks this server apparently does not support any TLS
protocol, and you get no connection. But for a second opinion I went to
https://www.ssllabs.com/ssltest/analyze.html?d=pge.com which was able to
connect via TLS 1.0. The server supports very few cipher suites (you can
see that the site is completely inaccessible with the latest Safari, for
example), but we share three in common so I'm not sure what's wrong. The
next step would be to ask on the gnutls-help mailing list [1] to find
out whether there is a GnuTLS bug (not really likely) or why it's
refusing to connect if not. Please do CC me; I'm curious!

Michael

[1] http://lists.gnutls.org/mailman/listinfo/gnutls-help
Niranjan Rao
2014-11-13 02:18:00 UTC
Permalink
Michael,

Thank you for detailed explanation. Though I am not expert I suspected
something on similar lines and hence raised the question about using
webkit TLS functionality.

I'll follow up with gnu tls lists.

Regards,

Niranjan
Post by Michael Catanzaro
Post by Niranjan Rao
Greetings,
On Webkit 2.2.6/Ubuntu 12.04
When visiting some sites, I get error SLS handshake error. For example
site https://www.pge.com/eum/login gives SSL handshake error when using
MiniBrowser. Usual browsers are doing ok when visiting the site.
Is there any way to mitigate this problem?
Each such site requires individual investigation, unfortunately.
Post by Niranjan Rao
I saw some documentation about TLS errors in webkitgtk web site. Not
clear if this applies to me or not.
Well, that documentation describes how to handle "successful" TLS
connections with unverified TLS certificates, which is important for
developers because older versions of WebKitGTK+ handle this insecurely
by default. But it's not relevant here, since this connection has failed
completely. We use GnuTLS to handle TLS; here's what its command line
$ gnutls-cli www.pge.com
Processed 153 CA certificate(s).
Resolving 'www.pge.com'...
Connecting to '131.89.128.67:443'...
*** Fatal error: The TLS connection was non-properly terminated.
*** Handshake has failed
GnuTLS error: The TLS connection was non-properly terminated.
$ gnutls-cli-debug www.pge.com
Resolving 'www.pge.com'...
Connecting to '131.89.128.67:443'...
Checking for SSL 3.0 support... no
Connecting to '131.89.128.67:443'...
Checking whether %COMPAT is required... yes
Connecting to '131.89.128.67:443'...
Checking for TLS 1.0 support... no
Connecting to '131.89.128.67:443'...
Checking for TLS 1.1 support... no
Connecting to '131.89.128.67:443'...
Checking fallback from TLS 1.1 to... failed
Connecting to '131.89.128.67:443'...
Checking for TLS 1.2 support... no
Connecting to '131.89.128.67:443'...
Checking whether we need to disable TLS 1.2... yes
So GnuTLS thinks this server apparently does not support any TLS
protocol, and you get no connection. But for a second opinion I went to
https://www.ssllabs.com/ssltest/analyze.html?d=pge.com which was able to
connect via TLS 1.0. The server supports very few cipher suites (you can
see that the site is completely inaccessible with the latest Safari, for
example), but we share three in common so I'm not sure what's wrong. The
next step would be to ask on the gnutls-help mailing list [1] to find
out whether there is a GnuTLS bug (not really likely) or why it's
refusing to connect if not. Please do CC me; I'm curious!
Michael
[1] http://lists.gnutls.org/mailman/listinfo/gnutls-help
Carlos Alberto Lopez Perez
2014-11-17 17:09:13 UTC
Permalink
Post by Niranjan Rao
Michael,
Thank you for detailed explanation. Though I am not expert I suspected
something on similar lines and hence raised the question about using
webkit TLS functionality.
I'll follow up with gnu tls lists.
The issue is that GnuTLS by default sends a SSL 3.0 version record in
client hello to advertise TLS (even when SSL 3.0 is disabled), and some
servers have banned this after POODLE [1].

I have submitted a patch [2] to work around this issue on the WebKit
side.

You can also workaround this issue by setting the environment variable
G_TLS_GNUTLS_PRIORITY before launching the WK browser:

$ export G_TLS_GNUTLS_PRIORITY='NORMAL:%COMPAT:%LATEST_RECORD_VERSION:!VERS-SSL3.0'
$ epiphany https://www.pge.com/eum/login


Regards!
--------
[1] http://lists.gnutls.org/pipermail/gnutls-help/2014-November/003673.html
[2] https://bugs.webkit.org/show_bug.cgi?id=138794
Michael Catanzaro
2014-11-17 18:01:13 UTC
Permalink
Post by Carlos Alberto Lopez Perez
You can also workaround this issue by setting the environment variable
$ export G_TLS_GNUTLS_PRIORITY='NORMAL:%COMPAT:%
LATEST_RECORD_VERSION:!VERS-SSL3.0'
$ epiphany https://www.pge.com/eum/login
In particular, please let us know if you find that using this workaround
causes other sites to break!
Niranjan Rao
2014-11-17 18:12:46 UTC
Permalink
Carlos,

Big thank you. Just tested on my local box and it worked for PGE.

Michael,

Monitoring other sites should not be a problem - we visit around large
number of sites every day - all of them using SSL via automated job. Any
abnormal failures will be immediately noticed.

Thank you again,

Regards,

Niranjan
Post by Michael Catanzaro
Post by Carlos Alberto Lopez Perez
You can also workaround this issue by setting the environment variable
$ export G_TLS_GNUTLS_PRIORITY='NORMAL:%COMPAT:%
LATEST_RECORD_VERSION:!VERS-SSL3.0'
$ epiphany https://www.pge.com/eum/login
In particular, please let us know if you find that using this workaround
causes other sites to break!
Continue reading on narkive:
Loading...