Discussion:
Command View EVA with Chrome
(too old to reply)
Shael Richmond
2017-03-13 20:51:40 UTC
Permalink
Raw Message
Just a FYI for you folks out there. If you use Chrome with Command View, it will stop working as of the version 57 update. It can't find the security component.

There is a workaround, you need to add the following registry key:

EnableSha1ForLocalAnchors
Whether SHA-1 signed certificates issued by local trust anchors are allowed
Data type:
Boolean [Windows:REG_DWORD]
Windows registry location:
Software\Policies\Google\Chrome\EnableSha1ForLocalAnchors
Mac/Linux preference name:
EnableSha1ForLocalAnchors
Android restriction name:
EnableSha1ForLocalAnchors
Supported on:
• Google Chrome (Linux, Mac, Windows) since version 54
• Google Chrome OS (Google Chrome OS) since version 54
• Google Chrome (Android) since version 54
Supported features:
Dynamic Policy Refresh: Yes, Per Profile: No
Description:
When this setting is enabled, Google Chrome allows SHA-1 signed certificates as long as they successfully validate and chain to a locally-installed CA certificates.
Note that this policy depends on the operating system certificate verification stack allowing SHA-1 signatures. If an OS update changes the OS handling of SHA-1 certificates, this policy may no longer have effect. Further, this policy is intended as a temporary workaround to give enterprises more time to move away from SHA-1. This policy will be removed on or around January 1st 2019.
If this policy is not set, or it is set to false, then Google Chrome follows the publicly announced SHA-1 deprecation schedule.
Example value:
0x00000000 (Windows), false (Linux), false (Android), <false /> (Mac)

Set the value to 1 and all is good again.

I opened a ticket with HPE just to try and find out what it was doing so I could check with Google, but they weren't much help at all.

Shael Richmond
International Paper
Forster, Michael
2017-03-13 21:28:56 UTC
Permalink
Raw Message
Thank you for sharing.

I updated this morning and will check tomorrow if I'm broken or if I didn't receive the same update.


Michael Forster
Enterprise Storage and IDX Architect | Information Services
Medical College of Wisconsin
O: (414) 955-4967 | ***@mcw.edu


________________________________________
From: Info-vax <info-vax-***@rbnsn.com> on behalf of Shael Richmond via Info-vax <info-***@rbnsn.com>
Sent: Monday, March 13, 2017 3:51:40 PM
To: info-***@rbnsn.com
Cc: Shael Richmond
Subject: [Info-vax] Command View EVA with Chrome

Just a FYI for you folks out there. If you use Chrome with Command View, it will stop working as of the version 57 update. It can't find the security component.

There is a workaround, you need to add the following registry key:

EnableSha1ForLocalAnchors
Whether SHA-1 signed certificates issued by local trust anchors are allowed
Data type:
Boolean [Windows:REG_DWORD]
Windows registry location:
Software\Policies\Google\Chrome\EnableSha1ForLocalAnchors
Mac/Linux preference name:
EnableSha1ForLocalAnchors
Android restriction name:
EnableSha1ForLocalAnchors
Supported on:
• Google Chrome (Linux, Mac, Windows) since version 54
• Google Chrome OS (Google Chrome OS) since version 54
• Google Chrome (Android) since version 54
Supported features:
Dynamic Policy Refresh: Yes, Per Profile: No
Description:
When this setting is enabled, Google Chrome allows SHA-1 signed certificates as long as they successfully validate and chain to a locally-installed CA certificates.
Note that this policy depends on the operating system certificate verification stack allowing SHA-1 signatures. If an OS update changes the OS handling of SHA-1 certificates, this policy may no longer have effect. Further, this policy is intended as a temporary workaround to give enterprises more time to move away from SHA-1. This policy will be removed on or around January 1st 2019.
If this policy is not set, or it is set to false, then Google Chrome follows the publicly announced SHA-1 deprecation schedule.
Example value:
0x00000000 (Windows), false (Linux), false (Android), <false /> (Mac)

Set the value to 1 and all is good again.

I opened a ticket with HPE just to try and find out what it was doing so I could check with Google, but they weren't much help at all.

Shael Richmond
International Paper
IanD
2017-03-19 18:50:11 UTC
Permalink
Raw Message
Post by Shael Richmond
Just a FYI for you folks out there. If you use Chrome with Command View, it will stop working as of the version 57 update. It can't find the security component.
EnableSha1ForLocalAnchors
Whether SHA-1 signed certificates issued by local trust anchors are allowed
Boolean [Windows:REG_DWORD]
Software\Policies\Google\Chrome\EnableSha1ForLocalAnchors
EnableSha1ForLocalAnchors
EnableSha1ForLocalAnchors
• Google Chrome (Linux, Mac, Windows) since version 54
• Google Chrome OS (Google Chrome OS) since version 54
• Google Chrome (Android) since version 54
Dynamic Policy Refresh: Yes, Per Profile: No
When this setting is enabled, Google Chrome allows SHA-1 signed certificates as long as they successfully validate and chain to a locally-installed CA certificates.
Note that this policy depends on the operating system certificate verification stack allowing SHA-1 signatures. If an OS update changes the OS handling of SHA-1 certificates, this policy may no longer have effect. Further, this policy is intended as a temporary workaround to give enterprises more time to move away from SHA-1. This policy will be removed on or around January 1st 2019.
If this policy is not set, or it is set to false, then Google Chrome follows the publicly announced SHA-1 deprecation schedule.
0x00000000 (Windows), false (Linux), false (Android), <false /> (Mac)
Set the value to 1 and all is good again.
I opened a ticket with HPE just to try and find out what it was doing so I could check with Google, but they weren't much help at all.
Shael Richmond
International Paper
Thanks for this, I am sure I will get bitten by this one - really appreciate the heads up!
IanD
2017-03-19 18:53:13 UTC
Permalink
Raw Message
Post by Shael Richmond
Just a FYI for you folks out there. If you use Chrome with Command View, it will stop working as of the version 57 update. It can't find the security component.
EnableSha1ForLocalAnchors
Whether SHA-1 signed certificates issued by local trust anchors are allowed
Boolean [Windows:REG_DWORD]
Software\Policies\Google\Chrome\EnableSha1ForLocalAnchors
EnableSha1ForLocalAnchors
EnableSha1ForLocalAnchors
• Google Chrome (Linux, Mac, Windows) since version 54
• Google Chrome OS (Google Chrome OS) since version 54
• Google Chrome (Android) since version 54
Dynamic Policy Refresh: Yes, Per Profile: No
When this setting is enabled, Google Chrome allows SHA-1 signed certificates as long as they successfully validate and chain to a locally-installed CA certificates.
Note that this policy depends on the operating system certificate verification stack allowing SHA-1 signatures. If an OS update changes the OS handling of SHA-1 certificates, this policy may no longer have effect. Further, this policy is intended as a temporary workaround to give enterprises more time to move away from SHA-1. This policy will be removed on or around January 1st 2019.
If this policy is not set, or it is set to false, then Google Chrome follows the publicly announced SHA-1 deprecation schedule.
0x00000000 (Windows), false (Linux), false (Android), <false /> (Mac)
Set the value to 1 and all is good again.
I opened a ticket with HPE just to try and find out what it was doing so I could check with Google, but they weren't much help at all.
Shael Richmond
International Paper
Thanks for this, I am sure I will get bitten by this one - really appreciate the heads up!

Now to beg the security people to update my registry settings *sigh*. Don't ya love locked down environments, NOT
Richard Maher
2017-03-19 22:29:30 UTC
Permalink
Raw Message
Post by IanD
Now to beg the security people to update my registry settings *sigh*.
Don't ya love locked down environments, NOT
You're defending SHA1?
IanD
2017-03-22 18:20:23 UTC
Permalink
Raw Message
Post by Richard Maher
Post by IanD
Now to beg the security people to update my registry settings *sigh*.
Don't ya love locked down environments, NOT
You're defending SHA1?
Not at all, I hardly know him or her or it ;-)

I'm griping about living in a locked down environment with policies pushed out because it appears on someones checklist to implement because they got it off a latest security recommendations that is a one size fits all policy :-)

I can't fix-up my registry because I am a pleb. Yet, Chrome update will be pushed because it isn't the latest and I am a pleb and cannot stop this update. The downside will be that I cannot attach to the SAN storage to fix things should all hell break loose

When adherence to a directive from on high is pushed out to the enterprise without thought or consideration of what it actually may cause at the lower levels in terms of risk to the business, then yes, I do have a gripe

Parallels to government policy pushed out upon the public masses comes to mind

I really don't care if it's SHA-1 meeting it's death or not but I would be very interested in seeing how many actual attacks are perpetrated in our environment or others for that matter that levers the evils of SHA-1 and it's weaknesses

I do understand that security needs to always be moving forward (I'm actually doing a fantastic security course at the moment and really enjoying it (https://www.openlearning.com/courses/sec) but I do wonder, just how much of these security exploits are being worked in the real world versus the cost of implementing them. I know, I know, someone is going to say what is the cost of not...

Would I leave my front door unlocked based on the statistics that it's unlikely I'll get someone coming along testing my door to see if I have indeed locked it, of course not! but have I replaced my old front door lock that is known to fall to the bump key attack, no, I have not, that is an acceptable risk in my opinion and it's about accessing the REAL risk involved, not some theoretical perfect model being pushed upon all and sundry

I'll now return you to your regular programming...
Richard Maher
2017-03-22 22:35:38 UTC
Permalink
Raw Message
Post by IanD
I do understand that security needs to always be moving forward (I'm
actually doing a fantastic security course at the moment and really
enjoying it (https://www.openlearning.com/courses/sec) but I do
wonder, just how much of these security exploits are being worked in
the real world versus the cost of implementing them. I know, I know,
someone is going to say what is the cost of not...
Would I leave my front door unlocked based on the statistics that
it's unlikely I'll get someone coming along testing my door to see if
I have indeed locked it, of course not! but have I replaced my old
front door lock that is known to fall to the bump key attack, no, I
have not, that is an acceptable risk in my opinion and it's about
accessing the REAL risk involved, not some theoretical perfect model
being pushed upon all and sundry
I'll now return you to your regular programming...
Can you not just ask security people to upgrade your certificate with
something stronger?
e***@gmail.com
2017-03-23 00:08:21 UTC
Permalink
Raw Message
Post by Richard Maher
Can you not just ask security people to upgrade your certificate with
something stronger?
I think it was more of a case of trying to get HPE to issue EVA firmware with support for stronger certificates, which would be a little bit harder. It's surely a common problem for stuff like iLOs and switches to have management interfaces which you wouldn't want to expose to even your internal network.

And that's before you get on to the real stupid stuff, like 'requires outdated version of Java'. In a week when 'Critical Telnet vulnerability in Cisco switches' is headline news, one does wonder. Still, no certificate vulnerabilities in Telnet, so that's OK.
Loading...