[EFL] - Failed to connect secure Websocket request (wss://)
Created attachment 178188 [details] Patch
To reproduce the issue 1. Fetch http://www.websocket.org/echo.html 2. Click on "Use Secure websocket [TLS]" 3. Connect 4. Disconnect is displayed in the Log Patch is for EFL and other port which uses gnome network libraries. Cause: Fail in TLS Handshake, because "accept-certificate" callback is not registered.
Comment on attachment 178188 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=178188&action=review > Source/WebCore/ChangeLog:3 > + [EFL] - Failed to connect secure Websocket request (wss://) This is not efl specific patch. Use [Soup] prefix instead of [EFL]. Beside '-' is not needed in bug title. > Source/WebCore/ChangeLog:6 > + Failed to connect secure Websocket request (wss://) in EFL Port, I think GTK port also has this problem because GTK and EFL ports use soup. Did you check it ? > Source/WebCore/platform/network/soup/SocketStreamHandleSoup.cpp:298 > + // FIXME : Currently Accepting all the certificate, handle it properly later. Add notImplemented(); > Source/WebCore/platform/network/soup/SocketStreamHandleSoup.cpp:308 > + // FIXME : We don't have a way to get root CA's certificate info here, so, "accept-certificate" will say UNKNOWN_CA for all connection. "FIXME:" is general.
Created attachment 178192 [details] Patch
corrected based on review comments given by Gyuyoung Kim, and Uploaded new patch
Comment on attachment 178192 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=178192&action=review > Source/WebCore/platform/network/soup/SocketStreamHandleSoup.cpp:308 > + // FIXME: We don't have a way to get root CA's certificate info here, so, "accept-certificate" will say UNKNOWN_CA for all connection. That's not true; GTlsConnection will check against the system CA list by default. This change is only needed for connecting to wss servers using unrecognized CAs. IIRC, Safari's behavior is to use the same list of certificate exceptions as it uses for https connections, and not provide any way to override it from the wss side. (ie, you have to have already ok'ed the bad certificate on an https connection before you can use it for wss connections). I think there may be discussion about this in other open bugs here. (For the soup backend, there's currently no way to add certificate exceptions at the webkit level, although I think Epiphany and Midori both implement it for https at higher levels.)
(In reply to comment #6) > (From update of attachment 178192 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=178192&action=review > > > Source/WebCore/platform/network/soup/SocketStreamHandleSoup.cpp:308 > > + // FIXME: We don't have a way to get root CA's certificate info here, so, "accept-certificate" will say UNKNOWN_CA for all connection. > > That's not true; GTlsConnection will check against the system CA list by default. This change is only needed for connecting to wss servers using unrecognized CAs. > > IIRC, Safari's behavior is to use the same list of certificate exceptions as it uses for https connections, and not provide any way to override it from the wss side. (ie, you have to have already ok'ed the bad certificate on an https connection before you can use it for wss connections). I think there may be discussion about this in other open bugs here. (For the soup backend, there's currently no way to add certificate exceptions at the webkit level, although I think Epiphany and Midori both implement it for https at higher levels.) Hi Dan You mean "accept_certificate" callaback will not get triggered or called if WSS servers using recognized CA ? We tried following thing for wss, g_tls_connection_set_database() is used, we get error UNKNOWN_CA in the callback for https when we use g_object_set(SOUP_SESSION, "tls-database",..), we get trusted certificate without any error.. However, we used same database for g_object_set() and g_tls_connection_set_database().
(In reply to comment #7) > You mean "accept_certificate" callaback will not get triggered or called if WSS servers using recognized CA ? Yes, that's how it should work... > for https when we use g_object_set(SOUP_SESSION, "tls-database",..), we get trusted certificate without any error.. > However, we used same database for g_object_set() and g_tls_connection_set_database(). Is the server sending a different certificate for wss than for https maybe?
(In reply to comment #8) > (In reply to comment #7) > > You mean "accept_certificate" callaback will not get triggered or called if WSS servers using recognized CA ? > > Yes, that's how it should work... > > > for https when we use g_object_set(SOUP_SESSION, "tls-database",..), we get trusted certificate without any error.. > > However, we used same database for g_object_set() and g_tls_connection_set_database(). > > Is the server sending a different certificate for wss than for https maybe? Yes
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > You mean "accept_certificate" callaback will not get triggered or called if WSS servers using recognized CA ? > > > > Yes, that's how it should work... > > > > > for https when we use g_object_set(SOUP_SESSION, "tls-database",..), we get trusted certificate without any error.. > > > However, we used same database for g_object_set() and g_tls_connection_set_database(). > > > > Is the server sending a different certificate for wss than for https maybe? > Yes Hi Dan, Dont you think, This patch is usefull, if you want show certificate warning message to the user allow (return TRUE) or deny (return FALSE) for this wss request ?. we can show certificate warning message from "accept-certificate" callback.. Because i saw in Mozilla, they support it, https://bugzilla.mozilla.org/show_bug.cgi?id=594502 Thank You
Comment on attachment 178192 [details] Patch Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.
We should not support this. The server you're connecting to is just broken.