An update on SSLv3 in Chrome.

60675 views
Skip to first unread message

Adam Langley

unread,
Oct 30, 2014, 2:02:30 PM10/30/14
to securi...@chromium.org
(The update is that we're killing it.)

In Chrome 39 (the next version), fallback to SSLv3 will be disabled by
default. SSLv3-fallback support allows a network attacker to force an
HTTPS connection to a site to use SSLv3. This version of SSL/TLS has
padding weaknesses that Google researchers recently showed can be used
to mount an attack on the confidentiality of the connection[1][2].

SSLv3-fallback is only needed to support buggy HTTPS servers. Servers
that correctly support only SSLv3 will continue to work (for now) but
some buggy servers may stop working. The answer in these cases is to
fix the server -- TLS 1.0 is nearly 15 years old at this point.

Fallback to SSLv3 is disabled on canary, dev and beta channels at the
moment. However, because of a lack of time to translate a specific
error message, beta (and thus stable, in time) will only show a
generic error message when hitting a buggy server. Toggling “Details”
will show ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION, which identifies
this issue.

In Chrome 40, we plan on disabling SSLv3 completely, although we are
keeping an eye on compatibility issues that may arise. In preparation
for this, Chrome 39 will show a yellow badge over the lock icon for
SSLv3 sites. These sites need to be updated to at least TLS 1.0 before
Chrome 40 is released.

(However, a lack of a yellow badge doesn’t mean that everything will
be fine as there could still be subresources of the page that are
served over SSLv3 connections. Developers can run Chrome with
--ssl-version-min=tls1 in order to test their sites.)

The enterprise-policy options SSLVersionMin and SSLVersionFallbackMin
can be used to control the minimum SSL/TLS version and minimum
fallback version in Chrome 39. In Chrome 40, the minimum SSL/TLS
version will also be controllable via about:flags.

In time, SSLv3 client support will be removed from the code, so anyone
re-enabling SSLv3 and/or fallback to it via policy, command line
options or about:flags should not treat that as a long-term solution.

[1] https://www.openssl.org/~bodo/ssl-poodle.pdf
[2] https://www.imperialviolet.org/2014/10/14/poodle.html


Cheers

AGL

Marco Constantino

unread,
Oct 30, 2014, 2:20:19 PM10/30/14
to securi...@chromium.org
Great, Adam!

Congrats for the job.

Regards

Marco

kobra...@gmail.com

unread,
Oct 30, 2014, 3:37:20 PM10/30/14
to securi...@chromium.org
Are you aware of any prominent (Alexa 500 or some other metric) websites that this will break on?

Adam Langley

unread,
Oct 30, 2014, 3:55:05 PM10/30/14
to kobra...@gmail.com, securi...@chromium.org
On Thu, Oct 30, 2014 at 12:37 PM, <kobra...@gmail.com> wrote:
> Are you aware of any prominent (Alexa 500 or some other metric) websites that this will break on?

I think there were a handful in the top 50K based on a quick scan but
I didn't recognise any of the names. However, it's very difficult to
be sure because some features might be on subdomains that aren't in
the Alexa list.


Cheers

AGL

Hanno Böck

unread,
Oct 30, 2014, 3:56:15 PM10/30/14
to securi...@chromium.org
Am Thu, 30 Oct 2014 11:02:08 -0700
schrieb Adam Langley <a...@chromium.org>:

> (However, a lack of a yellow badge doesn’t mean that everything will
> be fine as there could still be subresources of the page that are
> served over SSLv3 connections. Developers can run Chrome with
> --ssl-version-min=tls1 in order to test their sites.)

Does that make sense?
Why not add the yellow badge to everything where any third party
sources are sslv3? I think this would increase the likelyhood
webmasters of pages that will stop working once sslv3 is completely
disabled will notice beforehand would increase.

--
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42
signature.asc

Adam Langley

unread,
Oct 30, 2014, 4:01:12 PM10/30/14
to Hanno Böck, securi...@chromium.org
On Thu, Oct 30, 2014 at 12:56 PM, Hanno Böck <ha...@hboeck.de> wrote:
> Why not add the yellow badge to everything where any third party
> sources are sslv3? I think this would increase the likelyhood
> webmasters of pages that will stop working once sslv3 is completely
> disabled will notice beforehand would increase.

That would be nice, but we don't currently plumb that information into
the pageinfo. For a one-off, and as something that needs to be merge
to the stable branch, I'm afraid something like that (which would need
to be plumbed all the way through Blink too) isn't viable.


Cheers

AGL

lazy.d...@gmail.com

unread,
Oct 30, 2014, 4:12:24 PM10/30/14
to securi...@chromium.org, kobra...@gmail.com

>
> Are you aware of any prominent (Alexa 500 or some other metric) websites that this will break on?

none in the top500, 8 in the top 10.000
https://8ack.de/ssl/ -> see "Bad Sites"

report is from last week


cheers,


mex

Scott Arciszewski

unread,
Oct 30, 2014, 4:14:21 PM10/30/14
to Hanno Böck, securi...@chromium.org
While we're at it, can we add one of those glorious SSL failure screens to any sites that don't use HTTPS in a future version of Chrome?

''""
Warning: this website does not offer a secure connection. It may be possible for others to snoop on your traffic or impersonate the webserver.

[ I understand ] [ Take me out of here ]
"""

Chris Palmer

unread,
Oct 30, 2014, 4:33:12 PM10/30/14
to Scott Arciszewski, Hanno Böck, security-dev
On Thu, Oct 30, 2014 at 1:14 PM, Scott Arciszewski
<kobra...@gmail.com> wrote:

> While we're at it, can we add one of those glorious SSL failure screens to
> any sites that don't use HTTPS in a future version of Chrome?
>
> ''""
> Warning: this website does not offer a secure connection. It may be possible
> for others to snoop on your traffic or impersonate the webserver.
>
> [ I understand ] [ Take me out of here ]
> """

We are working on something like that, but gentler.

derek...@gmail.com

unread,
Oct 31, 2014, 12:39:50 PM10/31/14
to securi...@chromium.org
Any guidance on the expected release dates for v39 or v40?

PhistucK

unread,
Oct 31, 2014, 12:47:00 PM10/31/14
to derek...@gmail.com, security-dev
A new major Chrome version is released roughly every six weeks.
Chrome 38 was released on October 7th, 2014, so just do the math for the next ones. :)


PhistucK

On Fri, Oct 31, 2014 at 6:39 PM, <derek...@gmail.com> wrote:
Any guidance on the expected release dates for v39 or v40?

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

paulo...@gmail.com

unread,
Oct 31, 2014, 9:33:58 PM10/31/14
to securi...@chromium.org
I asked a question when the SSLv3 protocol in Chrome would be disabled by default and gave me the completely wrong information.

Look erroneous advice they gave me on the forum:


https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/chrome/mKEa8vFYGyM/KfMHeI7_AScJ

unfortunate.

Adrienne Porter Felt

unread,
Nov 1, 2014, 2:13:23 AM11/1/14
to paulo...@gmail.com, securi...@chromium.org
I think she simply confused disabling SSLv3 fallback and disabling SSLv3. No deception meant.

zeev.t...@gmail.com

unread,
Nov 2, 2014, 12:48:10 PM11/2/14
to securi...@chromium.org
Hello, I have Chrome Version 40.0.2207.2 canary (64-bit) and I need SSLv3 suppport for my bank. I could not find a way to enable it using about:flags. Did I miss it or something?

Adam Langley

unread,
Nov 3, 2014, 3:49:49 PM11/3/14
to zeev.t...@gmail.com, securi...@chromium.org
On Sun, Nov 2, 2014 at 9:48 AM, <zeev.t...@gmail.com> wrote:
> Hello, I have Chrome Version 40.0.2207.2 canary (64-bit) and I need SSLv3 suppport for my bank. I could not find a way to enable it using about:flags. Did I miss it or something?

Which bank?

(There will be an entry in about:flags in a few days, but it's not
there yet. For the moment, beta or stable will work or you can pass
--ssl-version-min=ssl3 on the command line:
http://www.chromium.org/developers/how-tos/run-chromium-with-flags)


Cheers

AGL

Zeev Tarantov

unread,
Nov 3, 2014, 4:38:38 PM11/3/14
to Adam Langley, securi...@chromium.org
Thank you for your response! Replies inline.


On Mon, Nov 3, 2014 at 10:47 PM, Adam Langley <a...@chromium.org> wrote:
On Sun, Nov 2, 2014 at 9:48 AM,  <zeev.t...@gmail.com> wrote:
> Hello, I have Chrome Version 40.0.2207.2 canary (64-bit) and I need SSLv3 suppport for my bank. I could not find a way to enable it using about:flags. Did I miss it or something?

Which bank?

The bank in question is https://en.wikipedia.org/wiki/Bank_Hapoalim
Landing page:
https://www.ssllabs.com/ssltest/analyze.html?d=www.bankhapoalim.co.il&s=81.218.18.149
iframe with login form that is SSLv3 only (server responds with SSLv3 ServerHello to any version of ClientHello):
https://www.ssllabs.com/ssltest/analyze.html?d=login.bankhapoalim.co.il
I tried complaining, didn't help.
It is the only banking site I know that requires SSLv3, other major Israeli banks work with TLS 1.0 or better (though they all prefer/require RC4).


(There will be an entry in about:flags in a few days, but it's not
there yet. For the moment, beta or stable will work or you can pass
--ssl-version-min=ssl3 on the command line:
http://www.chromium.org/developers/how-tos/run-chromium-with-flags)


Chrome/40.0.2209.0 launched with --ssl-version-min=ssl3 does _not_ have SSLv3 support.

Adam Langley

unread,
Nov 4, 2014, 2:14:24 PM11/4/14
to Zeev Tarantov, securi...@chromium.org
On Mon, Nov 3, 2014 at 1:38 PM, Zeev Tarantov <zeev.t...@gmail.com> wrote:
> https://www.ssllabs.com/ssltest/analyze.html?d=www.bankhapoalim.co.il&s=81.218.18.149
> iframe with login form that is SSLv3 only (server responds with SSLv3
> ServerHello to any version of ClientHello):
> https://www.ssllabs.com/ssltest/analyze.html?d=login.bankhapoalim.co.il
> I tried complaining, didn't help.
> It is the only banking site I know that requires SSLv3, other major Israeli
> banks work with TLS 1.0 or better (though they all prefer/require RC4).

I'm afraid this is why SSLv3 support has lasted as long as it has :(

> Chrome/40.0.2209.0 launched with --ssl-version-min=ssl3 does _not_ have
> SSLv3 support.

Thank you! The code was taking the default minimum version (TLS1) as
the minimum version supported by the code. This will be fixed today
and in Canary either tomorrow or Thursday.


Cheers

AGL

ccb2...@gmail.com

unread,
Nov 18, 2014, 6:38:22 PM11/18/14
to securi...@chromium.org
Version 39.0.2171.65 (64-bit) (linux)

Just pulled this update today unaware of the fact that I'd get locked out
of all of my Tomato and DD-WRT routers.

Adam Langley

unread,
Nov 18, 2014, 6:43:23 PM11/18/14
to ccb2...@gmail.com, securi...@chromium.org
On Tue, Nov 18, 2014 at 3:38 PM, <ccb2...@gmail.com> wrote:
> Just pulled this update today unaware of the fact that I'd get locked out
> of all of my Tomato and DD-WRT routers.

If you need to update the firmware on such devices then it is possible
to use --ssl-version-fallback-min=ssl3 in order to temporarily support
buggy servers, at least long enough to reconfigure/fix them.


Cheers

AGL

Peter Böhler

unread,
Nov 19, 2014, 6:58:33 PM11/19/14
to securi...@chromium.org


Google advances SSL with new Chrome versions


Summary: The latest stable version of Chrome removes the source of the POODLE bug and SSLv3 support will be out altogether over time. The Canary version disparages implementations not up to standards.

Hanno Böck

unread,
Nov 19, 2014, 7:07:29 PM11/19/14
to securi...@chromium.org
Am Tue, 18 Nov 2014 15:43:02 -0800
schrieb Adam Langley <a...@chromium.org>:

> If you need to update the firmware on such devices then it is possible
> to use --ssl-version-fallback-min=ssl3 in order to temporarily support
> buggy servers, at least long enough to reconfigure/fix them.

This seems to be a mostly undocumented commandline (at least man
chromium doesn't show it to me).

Can this also be used to completely disable fallbacks? (and how?)
--ssl-version-fallback-min=tls12?
signature.asc

Adam Langley

unread,
Nov 19, 2014, 7:19:51 PM11/19/14
to Hanno Böck, securi...@chromium.org
On Wed, Nov 19, 2014 at 4:07 PM, Hanno Böck <ha...@hboeck.de> wrote:
> This seems to be a mostly undocumented commandline (at least man
> chromium doesn't show it to me).

It's undocumented and temporary, yes.

> Can this also be used to completely disable fallbacks? (and how?)
> --ssl-version-fallback-min=tls12?

Correct.


Cheers

AGL

aras...@gmail.com

unread,
Dec 5, 2014, 3:22:51 PM12/5/14
to securi...@chromium.org, ccb2...@gmail.com
On Windows 7, I used the following command to launch Chrome v39:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ssl-version-fallback-min=ssl3

but I still get the following error:
ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION

The following command also resulted in the same error:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ssl-version-min=ssl3

My goal is to have a temporary workaround because the server-side fix isn't working for me.

David Benjamin

unread,
Dec 5, 2014, 3:30:27 PM12/5/14
to aras...@gmail.com, securi...@chromium.org, ccb2...@gmail.com
Does the flag appear when you go to about:version? If not, you probably already had Chrome running; if there's already an instance, it messages the existing one and your new flags don't take. You'll have to quit Chrome completely first.

Note, however, that we plan on disabling SSLv3 altogether in Chrome 40, at which point you will also need --ssl-version-min=ssl3. I recommend you fix the server as soon as possible.

aras...@gmail.com

unread,
Dec 5, 2014, 3:52:01 PM12/5/14
to securi...@chromium.org, aras...@gmail.com, ccb2...@gmail.com
Thanks a lot for the quick response. Your diagnosis was spot on.
I shutdown Chrome completely, and started it with the
--ssl-version-fallback-min=ssl3 flag, and now I can successfully
get to the https urls.

I'm using the Oracle HTTP Server (Apache 1.3) and I get the
ERR_SSL_PROTOCOL_ERROR from Chrome when I disable SSLv3 in Apache, as
follows:
SSLProtocol -All +TLSv1

I also get ssl_error_illegal_parameter_alert from Firefox v34, so it
appears to be a problem with Oracle's Apache.

David Benjamin

unread,
Dec 5, 2014, 4:08:01 PM12/5/14
to aras...@gmail.com, securi...@chromium.org, ccb2...@gmail.com
I'm not familiar with this server, but you don't necessarily need to disable SSLv3 on your server to be compatible with Chrome 39 and 40. You just need to make sure something about SSLv3 is also enabled and working (such as TLSv1). If it's breaking without doing that, the server or server configuration is probably buggy and intolerant of TLSv1 somehow. Perhaps try contacting Oracle's support or see if there are updates available?

aras...@gmail.com

unread,
Dec 5, 2014, 4:23:08 PM12/5/14
to securi...@chromium.org, aras...@gmail.com, ccb2...@gmail.com
Thanks. TLSv1 is apparently supported by the server. The default
behavior - i.e., absence of any SSLProtocol directive in ssl.conf -
is supposed to be ALL (meaning SSLv2, SSLv3, and TLSv1) according to Oracle,
but we didn't have any SSLProtocol directive in ssl.conf (default behavior),
and yet Chrome 39 started failing with
ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION.
Oracle's recommendation is to add:

SSLProtocol -All +TLSv1

i.e., explicitly disable "All" and add TLSv1, but that solution isn't
working for us, resulting in ERR_SSL_PROTOCOL_ERROR in Chrome 39.

I do currently have an SR open with Oracle on this.

PhistucK

unread,
Dec 5, 2014, 4:25:30 PM12/5/14
to aras...@gmail.com, security-dev, ccb2...@gmail.com
It makes sense it still throws error, because it would have not tried the fallback if TLSv1 were working correctly.


PhistucK

David Benjamin

unread,
Dec 5, 2014, 4:35:26 PM12/5/14
to PhistucK, aras...@gmail.com, security-dev, ccb2...@gmail.com
When a TLSv1.2-capable ClientHello fails, we fallback to trying only TLSv1.1-capable. Then TLSv1.0 and historically down to SSLv3.0. Note that a properly-behaving server, if it doesn't support 1.2, could simply respond with a lower version. TLS has a perfectly reasonable version negotiation mechanism. Unfortunately, many servers (yours included it seems) are broken and fail to negotiate without the fallback for some reason or other, so all browsers do this fallback dance.

ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION means your server failed all prior attempts and required going all the way down to SSLv3.0. So its TLSv1 support is broken somehow. (In 39, we'll fallback all the way down to 3.0, but if that connection succeeds, it's still discarded and only used to advise this error code. In 40, we don't bother trying 3.0 in the fallback and won't accept a non-fallback 3.0 ServerHello either.)

aras...@gmail.com

unread,
Dec 5, 2014, 5:18:50 PM12/5/14
to securi...@chromium.org, phis...@gmail.com, aras...@gmail.com, ccb2...@gmail.com
Thanks for the explanation.
I believe this Oracle server, which is based on Apache 1.3, only
supports TLSv1.0, but as you say, it should at least fallback to that.

yuhong...@hotmail.com

unread,
Dec 19, 2014, 6:05:32 PM12/19/14
to securi...@chromium.org, phis...@gmail.com, aras...@gmail.com, ccb2...@gmail.com
On Friday, December 5, 2014 2:18:50 PM UTC-8, aras...@gmail.com wrote:
> Thanks for the explanation.
> I believe this Oracle server, which is based on Apache 1.3, only
> supports TLSv1.0, but as you say, it should at least fallback to that.

This may be because the server has TLS extensions intolerance or OCSP stapling intolerance.

rob...@bsn.ie

unread,
Jan 17, 2015, 1:03:31 PM1/17/15
to securi...@chromium.org
We have internal building devices which have no open internet exposure and which only support SSLv3. Given our overall firewall environment we are happy with the security of connection to these devices. We have no access to these chip based servers and therefore can not upgrade. It would be good to allow support for such use cases.

Adam Langley

unread,
Jan 17, 2015, 1:21:43 PM1/17/15
to rob...@bsn.ie, security-dev
On Sat, Jan 17, 2015 at 10:03 AM, <rob...@bsn.ie> wrote:
> We have internal building devices which have no open internet exposure and which only support SSLv3. Given our overall firewall environment we are happy with the security of connection to these devices. We have no access to these chip based servers and therefore can not upgrade. It would be good to allow support for such use cases.

For now, the policy or command line flags allow the SSL minimum
version to be set to SSLv3, but we are only committing to supporting
that for about another six months. However, you can always put a
reverse proxy in front of these devices.


Cheers

AGL

ch...@mesl2.co.uk

unread,
Feb 15, 2015, 2:05:18 PM2/15/15
to securi...@chromium.org, rob...@bsn.ie
We have at least one embedded system which requires this flag to allow Chrome to work with its SSL stack. The equipment vendor is very unlikely to update their firmware (there was a period of about three years between the previous two updates), simply because their system is stable and there no commercial benefit to them in doing so.So please continue to support this flag for a considerable period - I suggest ten years is more appropriate than 6 months.

Hanno Böck

unread,
Feb 15, 2015, 2:34:54 PM2/15/15
to securi...@chromium.org
On Sun, 15 Feb 2015 11:05:18 -0800 (PST)
ch...@mesl2.co.uk wrote:

> We have at least one embedded system which requires this flag to
> allow Chrome to work with its SSL stack. The equipment vendor is
> very unlikely to update their firmware (there was a period of about
> three years between the previous two updates), simply because their
> system is stable and there no commercial benefit to them in doing
> so.So please continue to support this flag for a considerable period
> - I suggest ten years is more appropriate than 6 months.

Why don't you name the vendor? Maybe blaming them for requiring people
to stay with bad security creates a commercial incentive for them.

I think this is part of the problem. People seem to think it's
acceptable that vendors delivered SSLv3-hardware even when the protocol
already was more than 10 years deprecated. It is not. And we should
clearly say so publicly.

Chris Palmer

unread,
Feb 15, 2015, 10:14:43 PM2/15/15
to Hanno Böck, security-dev

Exactly. TLS 1.2 is 6.5 years old, and TLS 1.1 is 9 years old. SSL 3 is dead and gone, and this vendor is, frankly, irresponsible.

Robert Baker

unread,
Feb 16, 2015, 4:24:49 AM2/16/15
to Chris Palmer, Hanno Böck, security-dev
Siemens - not known for patching their embedded systems (as the Iranians will tell you :-) ) 

rjd...@gmail.com

unread,
Apr 14, 2015, 5:54:43 PM4/14/15
to securi...@chromium.org
Of course this will mean no way to access my APC remote switch with Chrome ever again. Thankfully, I still have Netscape Navigator installed so I will go back to that. Thank you very much, big brother, for protecting me.

Chris Palmer

unread,
Apr 14, 2015, 6:08:26 PM4/14/15
to rjd...@gmail.com, security-dev
The Chromium project is not acting unilaterally. Many major browsers
have also removed support for the unsafe and obsolete SSL v3 protocol.

Microsoft has also disabled SSL v3 in IE 11:

https://technet.microsoft.com/library/security/3009008

Mozilla also disabled it in Firefox 34:

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

(verified with FF 36 at https://zmap.io/sslv3/sslv3test.html just now)

I urge you to take up the issue with APC.


On Tue, Apr 14, 2015 at 2:54 PM, <rjd...@gmail.com> wrote:
> Of course this will mean no way to access my APC remote switch with Chrome ever again. Thankfully, I still have Netscape Navigator installed so I will go back to that. Thank you very much, big brother, for protecting me.
>

Donald Stufft

unread,
Apr 14, 2015, 6:12:22 PM4/14/15
to rjd...@gmail.com, securi...@chromium.org

> On Apr 14, 2015, at 5:54 PM, rjd...@gmail.com wrote:
>
> Of course this will mean no way to access my APC remote switch with Chrome ever again. Thankfully, I still have Netscape Navigator installed so I will go back to that. Thank you very much, big brother, for protecting me.
>
> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

This was obviously meant sarcastically, but I’d like to unsarcastically say, yes, thank you all for making Chrome as secure as it can be!

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

signature.asc

kaush...@gmail.com

unread,
Sep 11, 2015, 2:52:11 AM9/11/15
to Security-dev
On Thursday, 30 October 2014 23:32:30 UTC+5:30, Adam Langley wrote:
> (The update is that we're killing it.)
>
> In Chrome 39 (the next version), fallback to SSLv3 will be disabled by
> default. SSLv3-fallback support allows a network attacker to force an
> HTTPS connection to a site to use SSLv3. This version of SSL/TLS has
> padding weaknesses that Google researchers recently showed can be used
> to mount an attack on the confidentiality of the connection[1][2].
>
> SSLv3-fallback is only needed to support buggy HTTPS servers. Servers
> that correctly support only SSLv3 will continue to work (for now) but
> some buggy servers may stop working. The answer in these cases is to
> fix the server -- TLS 1.0 is nearly 15 years old at this point.
>
> Fallback to SSLv3 is disabled on canary, dev and beta channels at the
> moment. However, because of a lack of time to translate a specific
> error message, beta (and thus stable, in time) will only show a
> generic error message when hitting a buggy server. Toggling “Details”
> will show ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION, which identifies
> this issue.
>
> In Chrome 40, we plan on disabling SSLv3 completely, although we are
> keeping an eye on compatibility issues that may arise. In preparation
> for this, Chrome 39 will show a yellow badge over the lock icon for
> SSLv3 sites. These sites need to be updated to at least TLS 1.0 before
> Chrome 40 is released.
>
> (However, a lack of a yellow badge doesn’t mean that everything will
> be fine as there could still be subresources of the page that are
> served over SSLv3 connections. Developers can run Chrome with
> --ssl-version-min=tls1 in order to test their sites.)
>
> The enterprise-policy options SSLVersionMin and SSLVersionFallbackMin
> can be used to control the minimum SSL/TLS version and minimum
> fallback version in Chrome 39. In Chrome 40, the minimum SSL/TLS
> version will also be controllable via about:flags.
>
> In time, SSLv3 client support will be removed from the code, so anyone
> re-enabling SSLv3 and/or fallback to it via policy, command line
> options or about:flags should not treat that as a long-term solution.
>
> [1] https://www.openssl.org/~bodo/ssl-poodle.pdf
> [2] https://www.imperialviolet.org/2014/10/14/poodle.html
>
>
> Cheers
>
> AGL

how can i solve?

Bob DeMattia

unread,
Sep 11, 2015, 7:51:59 AM9/11/15
to kaush...@gmail.com, Security-dev
The problem was solved by downloading a copy of Netscape Navigator, so I'm not
dependent on Chrome any longer.  The long term solution is to completely replace 
the hardware which has an embedded non-updatable web server.

But the larger problem is that browser users have no control over the web sites
they visit.  Completely removing back compatibility on a browser, which is what is
being done, is not a user-friendly idea. :)

Thanks,
Bob

Chris Miller (MESL)

unread,
Sep 11, 2015, 8:19:28 AM9/11/15
to securi...@chromium.org, n...@file.mesl.co.uk
I agree with Bob.
The expectation that small microcontroller-based systems - some of which have service lives of 10 or even 20 years "have to be updated" is not realistic.

It used to be that the browser was a good way of achieving a GUI on embedded systems, but this approach is now questionable, and - as a product developer - I think we are going to have to back to providing dedicated GUI tools for future products.  It is no longer possible to depend on browser behaviour remaining stable for the future if backward compatability is being through out of the window.

Chris

PhistucK

unread,
Sep 11, 2015, 8:52:36 AM9/11/15
to chris....@mesl.co.uk, security-dev, n...@file.mesl.co.uk
Not realistic? Do you mean that advances in security (or worse, fixed vulnerabilities) should just be left out of a device for twenty years, until it simply dies out?
Perhaps twenty years ago, a non updatable device was a common thing. Today, it is not. You have to update your software or firmware, especially if it is connected to the internet somehow, because it will quickly become insecure. No one is perfect, every internet (or even network?) connected software has vulnerabilities.
If you think not updating a vulnerable or outdated firmware or software is the right move for your devices or company (I guess it sounds like the right move business wise - "our devices are not updatable, you must buy a new one in order not to lose your data in case of a known vulnerability exploit" and the customer just buys a new one and you get paid), I think most of the (customer?) world would respectfully disagree.


PhistucK

Craig Francis

unread,
Sep 11, 2015, 9:22:57 AM9/11/15
to chris....@mesl.co.uk, security-dev, n...@file.mesl.co.uk, PhistucK
+1

Chris, I think you are far better off providing a standards based web GUI, as the browsers will provide you with many security benefits over your own proprietary GUI (I'm going to assume that no matter how big or qualified your team is, you are going to make mistakes, and you will have less people reviewing your implementation/code).

Your systems also need to be able to update themselves now (no excuses), and generally keep up with advances in technology.

If you had written your system 10 years ago, and have not upgraded it since, then it would be easy to break into now... after 20 years, it would be a joke (and this comes from someone who is maintaining/improving a couple of 15 year old code bases).

That said, most microcontroller-based systems have amazingly poor security already... often using plain text HTTP, or if they are using HTTPS, don't check the certificate validity when returning data... can't handle a simple nmap without crashing... don't protect against CSRF (but not even internet routers get that right, it's only been a known exploit since 2001)... fail to encode data correctly (XSS/SQLi/etc)... and I've yet to see any one of them using some of the features that browsers are providing (e.g. CSP/HPKP/HSTS headers).

And just as a random tangent, a web based GUI can typically be used by more customers (think basic accessibility), most propitiatory GUI's don't even consider things like screen readers (but then again, some web developers still don't understand what the <label> is for).

So please, upgrade your stuff :-)

Craig

Bob DeMattia

unread,
Sep 11, 2015, 11:43:53 AM9/11/15
to Craig Francis, chris....@mesl.co.uk, security-dev, n...@file.mesl.co.uk, PhistucK
When you say "please upgrade your stuff", who are you asking?  The embedded system provider? Or the customer with an internal network, protected by a firewall?

Imagine a large industrial facility with a private network with a solid firewall.
They could have 1000's of embedded monitors.  This is the kind of stuff that lasts for decades.   
The firewall can be upgraded regularly, but they don't want to take their factory down on a 
frequent basis to update the multitude of embedded devices.

But even if the factory owner wants to do this, if the company who made the monitors doesn't provide an 
upgrade path, or maybe the company went out of business, the customer is stuck.

So while I understand the browser developer strongly recommending an upgrade, and perhaps even putting a
warning on the screen when something is less than fully secure, not having backward compatibility is the
equivalent of Schlage going around and nailing doors shut because homeowners won't upgrade the locks on
their doors.

Are the browser requirements driving the customer's needs?  Or should the customer's needs drive the
browser's requirements?


-Bob


-Bob

Dan Anderson

unread,
Sep 11, 2015, 12:10:32 PM9/11/15
to Bob DeMattia, Craig Francis, chris....@mesl.co.uk, security-dev, n...@file.mesl.co.uk, PhistucK
Having a firewall (or even an air gap) obviously does not mean that you are absolved from ever performing basic security requirements like patching and upgrades.

Admittedly, old unmaintainable hardware and software do exist (and as Craig pointed out - should not be acceptable to anyone going forward).  

But allowing an insecure downgrade to occur for the general population to support a niche, legacy, insecure requirement simply doesn't make sense.

You are suggesting that our modern keys need to work in your vintage locks.  :)

Your use of a 1990's browser to support a specific, legacy 1990's protocol requirement seems appropriate.

Kind of like gopher not being supported in Chrome https://code.google.com/p/chromium/issues/detail?id=11345 :)

Dan


Craig Francis

unread,
Sep 11, 2015, 12:24:16 PM9/11/15
to Bob DeMattia, chris....@mesl.co.uk, security-dev, n...@file.mesl.co.uk, PhistucK
This is going off on a bit of a tangent, but...

I'm asking both the provider and customer.

You seems to be making the mistake of assuming a firewall is the solution to network based attacks.

All it takes is for an attacker to get one machine within the network to establish a connection outbound, then they can connect into the network (ok, glossing over some details, but that is the basic idea).

A classic example is an employee coming in with their malware infested computer/phone and connecting it to the network. It probably won't be targeted at the particular factory, but it might have a look around to see what's there (lets run nmap).

Security is all about layers, and while you should have a firewall, you must assume it has been compromised, and that any network that can get onto the internet is effectively part of the internet (with all of the good and bad parts).

If you can't handle that level of connectivity, you probably should not be using a network (either one that connects to the internet, or one that has any other kind of computing device on it).

So back to updating 1000's of devices... if you want your devices to last, you need to look at making those things upgrade without needing the whole factory to shutdown. Ideally automatically, and with plenty of fallbacks.

Yes it will require the supplier to not go out of business, but how else would libraries such as openssl 1.0.1f be upgraded when it's leaking private information onto the network?

It's not going to be easy, but I think most security auditors are sick and tired of seeing old devices allowing attackers into the network.

britton...@gmail.com

unread,
Sep 11, 2015, 3:10:27 PM9/11/15
to Security-dev
First you stop supporting Java plugins and now this? I can't connect to some internal servers inside my corporate HQ with chrome. I need to do my job, and there is no desire to change the SSL behind a VPN firewall. Thanks, but no thanks. Thank goodness for Firefox... tosses chrome in garbage can.

Adam Langley

unread,
Sep 11, 2015, 3:12:36 PM9/11/15
to britton...@gmail.com, Security-dev
On Fri, Sep 11, 2015 at 12:10 PM, <britton...@gmail.com> wrote:
> Thank goodness for Firefox... tosses chrome in garbage can.

(Firefox removed SSLv3 10 months ago:
https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/)


Cheers

AGL

wkr...@gmail.com

unread,
Sep 17, 2015, 2:07:19 PM9/17/15
to Security-dev
Hello Adam, I am using the Chrome/45.0.2454.93, well for the past few days I have been getting this message when trying to open Zooworld classic, "The client and server don't support a common SSL protocol version or cipher suite. This is usually caused when the server needs SSLv3 support, which has been removed.". Is there anything that can be done so that I might be able to return to playing ZooWorld classic. Thank you for all your help...
Walter :-)

David Benjamin

unread,
Sep 17, 2015, 2:11:38 PM9/17/15
to wkr...@gmail.com, Security-dev
On Thu, Sep 17, 2015 at 2:07 PM <wkr...@gmail.com> wrote:
Hello Adam, I am using the Chrome/45.0.2454.93, well for the past few days I have been getting this message when trying to open Zooworld classic, "The client and server don't support a common SSL protocol version or cipher suite. This is usually caused when the server needs SSLv3 support, which has been removed.". Is there anything that can be done so that I might be able to return to playing ZooWorld classic. Thank you for all your help...
Walter :-)

There's a number of things that might trigger that message. Could you file a bug at https://crbug.com/new and include a net-internals log per these instructions:

We can take a look from there.

Thanks!

David 

ayeshaaa...@gmail.com

unread,
Sep 22, 2015, 4:55:21 PM9/22/15
to Security-dev
i

dnyanesh...@gmail.com

unread,
Feb 10, 2016, 7:02:26 AM2/10/16
to Security-dev
Hi I am using a web logic server and hitting a web application locally using

https://localhost

Still I am getting this error.

My Chrome Version is : Version 45.0.2454.85 m

Yuhong Bao

unread,
Feb 13, 2016, 5:59:31 PM2/13/16
to Security-dev, dnyanesh...@gmail.com
Which version of WebLogic and IBM HTTP Server (if you are using it)?

emailv...@gmail.com

unread,
Jan 12, 2017, 1:00:29 AM1/12/17
to Security-dev
Quick fix escape open Mozilla Firefox open the page no problem then go back to chrome if you feel like the hassle...
>
>
> Cheers
>
> vb

arun1...@gmail.com

unread,
Dec 6, 2017, 11:28:01 AM12/6/17
to Security-dev

arun1...@gmail.com

unread,
Dec 6, 2017, 11:28:37 AM12/6/17
to Security-dev

susmar...@gmail.com

unread,
Jan 12, 2018, 12:59:05 AM1/12/18
to Security-dev
It's all me I'm sorry if messed out its all me I study as home based at w3c and now Java Senior Software Engineer and OEM IT MANAGER ADOBE and outside the USA cause I don't know how to process my owned visa as sponsor who would believed me everyone says its impossible and I discriminated as a mentally ill because of this in the Philippines everything I am was impossible 🙅 but not for long as you can be my witness I made that server and still I'm in control I used open 🆔 from developing that's why it always appeared anonymous do you want to work with me or do you believed and trust me Adam

susmar...@gmail.com

unread,
Jan 12, 2018, 1:03:55 AM1/12/18
to Security-dev
I think it because I accept the global sign certificate because they keep on believing I hacked the system but I am NOT and I can prove it to them they tried to get me but because of my situation lots of people tried to replaced me yes I lived in the Philippines but I work at the system ever since and none of you would take that away from me so you better accept my existence of being part of technology

susmar...@gmail.com

unread,
Jan 12, 2018, 1:11:36 AM1/12/18
to Security-dev
They tried all there best to replaced me but none of them succeed they said that I software domain made a lot of failure but what do they know I been involve as a project manager at open source sharing knowledge which is Google and because I shared a lot of the knowledge because of the cached they followed me and how bad their are tried to steal the dreams and my destiny I work by the USA I represent them even I am Pilipina cause that the real fact even I reverse it a lot of time it's still UNITED STATES OF AMERICA and thank you I guess you hear my side my history I love my Job 😃📶©💻

susmar...@gmail.com

unread,
Jan 12, 2018, 1:15:34 AM1/12/18
to Security-dev
I'm holding all the web credentials but http and https is still seen with me I don't think it's the best idea my job is tosle the search accessible to all the affiliate country and sorry if its affect you I'm just doing my job even I am misguided

susmar...@gmail.com

unread,
Jan 12, 2018, 1:20:42 AM1/12/18