An update on SSLv3 in Chrome.

[Adam Langley]

(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]

Great, Adam!

Congrats for the job.

Regards

Marco

[kobra...@gmail.com]

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

[Adam Langley]

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]

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

[Adam Langley]

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]

>
> 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]

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]

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]

Any guidance on the expected release dates for v39 or v40?

[PhistucK]

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]

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]

I think she simply confused disabling SSLv3 fallback and disabling SSLv3. No deception meant.

[zeev.t...@gmail.com]

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]

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]

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]

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]

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]

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]

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]

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?

[Adam Langley]

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]

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]

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]

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]

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]

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]

It makes sense it still throws error, because it would have not tried the fallback if TLSv1 were working correctly.

☆PhistucK

[David Benjamin]

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]

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]

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]

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]

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]

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]

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]

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]

Siemens - not known for patching their embedded systems (as the Iranians will tell you :-) ) 

[rjd...@gmail.com]

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]

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]

> 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

[kaush...@gmail.com]

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]

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)]

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]

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]

+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]

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]

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]

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]

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]

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]

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]

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:

https://dev.chromium.org/for-testers/providing-network-details

We can take a look from there.

Thanks!

David 

[ayeshaaa...@gmail.com]

i

[dnyanesh...@gmail.com]

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]

Which version of WebLogic and IBM HTTP Server (if you are using it)?

[emailv...@gmail.com]

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]

[arun1...@gmail.com]

[susmar...@gmail.com]

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]

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]

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]

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]

I am the gateway of other affiliates country to USA thru internet connection I tried all my best to control and maintain the situation and keep on going cause I have too if I didn't it will be handed my the wrong hand and we and I doesn't want that to happen until someone didn't see me

[susmar...@gmail.com]

Hi guys

[dontke...@gmail.com]

Don't worry

[deept...@gmail.com]

Hi Adam,

We are testing our application accessing on Chrome Browser with TLS 1.2 disabled. This is a negative test and our application should fail to launch.

I tried disabling TLS 1.2 in below mentioned two different ways. Both didnt work. Can you please help

1. i made on Internet Options > Advanced Security - unchecked TLS 1.2

2. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\SSLVersionMin 

Name        Type        Data

Default    REG_SZ     "tls1.1"

Regards

Deepti

[Ryan Sleevi]

bcc: security-dev@

cc: net-dev@

Neither of those options disable TLS 1.2.

On Tue, Apr 7, 2020 at 2:50 PM <deept...@gmail.com> wrote:

Hi Adam,

We are testing our application accessing on Chrome Browser with TLS 1.2 disabled. This is a negative test and our application should fail to launch.

I tried disabling TLS 1.2 in below mentioned two different ways. Both didnt work. Can you please help

1. i made on Internet Options > Advanced Security - unchecked TLS 1.2

This is not used and has not been used since Chrome 6 (by default) and Chrome 9 (always). This setting has zero effect on Chrome.

 

2. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\SSLVersionMin 

Name        Type        Data

Default    REG_SZ     "tls1.1"

Note, this is the Minimum version supported, not the maximum version supported.

It is important to understand why you're trying to test with TLS 1.2 disabled, especially as support for TLS 1.0 and TLS 1.1 are being phased out.

[deept...@gmail.com]

Thanks so much for reply.

Ok. I was confused initially with SSLVersionMin, but tried SSLVersionMax according to my requirement.

I understand that soon TLS 1.1 and 1.0 are being phased out. But the team wants to assure the negative test as well across all browsers.

And yes, i will call it louder this time about the "Phase-out".

So does this SSLVersionMax? I tried. No luck.

Any other way? Please help.

Regards

Deepti

[Ryan Sleevi]

You are correct that this does not work, by design, with SSLVersionMax. You cannot set the max version lower than TLS 1.2.

Disabling TLS 1.2 is not a feature that is offered, because it's not something that should be done. Disabling TLS 1.0 and TLS 1.1 (by setting the Min to 1.2) is supported, and Disabling TLS 1.3 is supported (for now) in the event there are 1.3 interoperability issues, but in general, controls to disable the "secure" or "stable" version are phased out.