Will be secure WebSocket (wss://) required in future versions of Chromium when in a https website?

[Iñaki Baz Castillo]

Hi,

In current Chrome stable 34 the JavaScript can open a non-secure WebSocket connection (ws:// scheme) when the website has https:// scheme. This is not true in Firefox not in Canary in which it shows this error:

-------------

[blocked] The page at 'https://xxxxxxxxxx.xxx' was loaded over HTTPS, but ran insecure content from 'ws://xxxxxxxx.xxx/': this content should also be loaded over HTTPS.

-------------

My question is: will this be a requirement in future stable versions of Chrome stable too? or just in Canary?

Thanks a lot.

[Torne (Richard Coles)]

Yes, all versions of chrome will require this as the change makes its way through the release process. The spec requires it, and so do other browsers; Chrome's old behaviour was wrong.

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Iñaki Baz Castillo]

Hi, thanks a lot for the response.

Please let me tell about my use case and needs: Chrome loads a HTTPS
web and the JavaScript code opens a WebSocket communication with a
local application listening into 127.0.0.1. Of course it is not
possible to get a truly certificate for a domain pointing to 127.0.0.1
and the trick involves generating a self-signed certificate, a fake
domain pointing to 127.0.0.1, and manually adding such a certificate
into the computer and/or browser.

Does it not make sense to let an exception so browsers can communicate
with localhost applications without requiring secure transport (for
both WSS and HTTPS)? Any other alternative we could try?

Thanks a lot.


2014-05-19 19:54 GMT+02:00 Torne (Richard Coles) <to...@google.com>:
> This will be required in all versions of chrome once the change makes its
> way through the release process. The spec requires this and other browsers
> agree; chtome's previous behaviour was wrong.

>
> On 19 May 2014 17:50, "Iñaki Baz Castillo" <i...@aliax.net> wrote:
>>

>> --
>> --
>> Chromium Discussion mailing list: chromium...@chromium.org
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/a/chromium.org/group/chromium-discuss
>>
>

--
Iñaki Baz Castillo
<i...@aliax.net>

[Yuta Kitamura]

I think a command-line option "--disable-web-security" should do the trick. Of course the flag is for testing purposes, so don't use it on your daily browsing.

Thanks,

Yuta

[Torne (Richard Coles)]

No, localhost is not a special case for origin security anywhere else (you can't load JS from http://localhost/ on a secure page either), so I don't think it makes any sense to do that here either.

On 20 May 2014 15:37, Iñaki Baz Castillo <i...@aliax.net> wrote:

2014-05-20 11:57 GMT+02:00 Yuta Kitamura <yu...@chromium.org>:

> I think a command-line option "--disable-web-security" should do the trick.
> Of course the flag is for testing purposes, so don't use it on your daily
> browsing.

Thanks, but that is not a feasible solution for clients (as they will
not run Chrome form a terminal).

Anyhow, does not make sense to relax the secure transport requirement
if the server is running in 127.0.0.1? AFAIK even Gmail connects to
the http:// server of the gtalk-plugin.

Thanks a lot.

[Iñaki Baz Castillo]

2014-05-20 11:57 GMT+02:00 Yuta Kitamura <yu...@chromium.org>:

> I think a command-line option "--disable-web-security" should do the trick.
> Of course the flag is for testing purposes, so don't use it on your daily
> browsing.

Thanks, but that is not a feasible solution for clients (as they will
not run Chrome form a terminal).

Anyhow, does not make sense to relax the secure transport requirement
if the server is running in 127.0.0.1? AFAIK even Gmail connects to
the http:// server of the gtalk-plugin.

Thanks a lot.