Enhance the SSL/TLS implementation/configuration of HiveManager + HiveOS to become PCI compliant.

  • 2
  • Idea
  • Updated 4 years ago
  • Planned
It would be great if consideration could be given to enhancing HiveManager and HiveOS so that its SSL/TLS implementation/configuration becomes PCI compliant. Presently, it is not.

See the following for reference:

https://www.ssllabs.com/projects/best-practices/

For example:

https://www.ssllabs.com/ssltest/analyze.html?d=ah-demo.aerohive.com

https://www.ssllabs.com/ssltest/analyze.html?d=myhive.aerohive.com

The deficiencies that should be addressed to come in to compliance are:

1) SSL 3.0 is supported and should not be. (Windows clients, for example, via Internet Explorer will fall back to using SSL 3.0 with a retry when a TLS handshake fails, so is subject to protocol downgrade attacks, and they do not support AES-based cipher suites over SSL 3.0. Windows then prefers RC4 over 3DES, so there is a cipher suite downgrade attack to a known weak cipher suite.)

2) Cipher suites using RC4 are offered and should not be. (The BEAST attack is a client vulnerability which is now patched by up-to-date clients. Clients must themselves be patched to perform record splitting against this vulnerability to be PCI compliant. 3DES is available for older clients such as Windows XP to use instead.)

RC4 is considered weak via:
http://www.isg.rhul.ac.uk/tls/RC4biases.pdf

3) Weak DHE_RSA cipher suites are offered and should not be.

4) Secure Client-Initiated Renegotiation is supported, which is DoS vulnerable, and should not be.

5) An RC4-based cipher suite is offered that uses MD5. It should not be offered. (Usurped by point 2.)

6) It appears that an out-of-date SSL/TLS library is being used because it is forward version intolerant in the TLS handshake, up-to-date libraries don't have this issue. This would breach PCI requirements.

It would be great if consideration could also be given to offering PFS (Pefect Forward Secrecy) and a Strict Transport Security HTTP Header to protect against attacks such as sslstrip.

Thanks,

Nick
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes

Posted 5 years ago

  • 2
Photo of Emilio Maldonado

Emilio Maldonado

  • 37 Posts
  • 11 Reply Likes
Hi Nick,
Thanks for reporting this tool, we are aware of the elements required and are taking actions to address them. Stay tuned for an update.

Regards
Emilio
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Quick update: The forward version intolerance at hypothetical version 2.98 appears to actually be a bug in OpenSSL which is present in the current version.
Photo of Edward Nice

Edward Nice

  • 19 Posts
  • 6 Reply Likes
This is a critical issue for us as well. I look forward to a swift response from Aerohive.
Photo of Emilio Maldonado

Emilio Maldonado

  • 37 Posts
  • 11 Reply Likes
Hi Edward,
Our security team is currently assessing this item. The plan is to patch our libraries, server configurations to address the flagged items and any others identified after auditing the servers. Please stay tuned, we'll be communicating once we know the particular release and version number.

Emilio
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
This is an area that I have been interested in for a while, back in late 2010 I researched and looked in to PCI compliance issues re SSL/TLS in the Nessus security scanner in advance of scanners like the one linked above becoming feature complete and available:

Things have significantly moved on from there (e.g. RC4 is no longer considered compliant due to recent research, 3DES is now considered a better compromise choice for legacy clients and was not back then, and TLS 1.1 and 1.2 are now viable and show real benefits against recent attacks). The guidance I wrote back then should now be considered stale and not encompassing enough, covering only configuration and not lifecycle.

I think it is important to maintain some perspective and proportion here therefore; this is not really a tangible risk to Aerohive's customers - it is just a compliance consideration that should be addressed when reasonably possible. The relevant PCI specification itself is not specific here and uses general terms so how that applies to the granular nature of SSL/TLS is open to much debate, it is certainly always a moving goal post.

Cheers,

Nick
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
There is an RFC candidate/draft, proposed by Microsoft, that formally prohibits RC4 based cipher suites:

http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01

"RC4 is a stream cipher described in [SCH], which is widely supported,
and often preferred, by TLS servers. However, RC4 has long been
known to have a variety of cryptographic weaknesses, e.g. [PAU],
[MAN], [FLU]. Recent cryptanalysis results [ALF] exploit biases in
the RC4 keystream to recover repeatedly encrypted plaintexts.

These recent results are on the verge of becoming practically
exploitable; currently they require 2^26 sessions or 13x2^30
encryptions. As a result, RC4 can no longer be seen as providing a
sufficient level of security for TLS sessions.

This document requires that TLS ([RFC5246], [RFC4346], [RFC2246])
clients and servers never negotiate the use of RC4 cipher suites."
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Microsoft have posted the following today:

Security Advisory 2868725: Recommendation to disable RC4
http://blogs.technet.com/b/srd/archiv...

Microsoft security advisory: Update for disabling RC4
http://support.microsoft.com/kb/2868725
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Hi Nick,
I saw those announcements from a month ago and earlier this week, and while they are good general advice, we all live in the real world that has other than Microsoft products to deal with.

I was hoping to hold off until we actually completed the work to strengthen Myhive, HiveManager, and HiveOS before announcing we had done so and how, but since there seems to be a number of people following this thread (and your updates keep bumping it to the top ), I will disclose some of the work now.

We are leaving SSL3.0 enabled. According to the Qualys test tool, the only popular combination of OS/browser that will fall back to this is IE6/WinXP, which will use TLS_RSA_WITH_RC4_128_MD5.

We will retain some of the RC4 based ciphers. We will remove the weakest ciphers, but specifically will retain
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA

Client-initiated renegotiation will be retained. Yes, there will still be some exposure to DoS attacks, but we believe we have other measures in place that will mitigate that risk. Even if a DoS attack is successful against Myhive or an on-premises instance of HiveManager, that still won't adversely affect the behavior of the APs, BRs, or switches.

The comment about SSL/TLS libraries and TLS version intolerance is incorrect. Our libraries are patched up to current but purposely report older versions.

We are still vehemently arguing about Forward Secrecy. A final decision has not been made, but I suspect this will not change given the remaining time before our planned release.

Once we have finally finished all the changes and released the software, I will change the tag on this Idea thread from Planned to Implemented.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Mike,

In this real world of which you speak then and keeping it technical:

The issue with SSL 3.0 has been misunderstood, it does not only affect Windows XP and IE6 and the Qualys test tool does not make this assertion:

The problem with leaving it enabled is that all modern browsers in their default configuration on most platforms are subject to protocol downgrade from active attacks. If you block/swallow/eat the TLS handshake(s) from the client, all browsers will presently retry with SSL 3.0. They do this for compatiblity with broken, misconfigured or exceptionally outdated SSL/TLS server deployments.

Furthermore, all SCHANNEL based clients, like Internet Explorer, will not negotiate AES ciphersuites over SSL 3.0, so you then have a downgrade to an RC4 based ciphersuite for which current security advice is to not use. (Attacks against algorithms only get better, never worse.)

TLS 1.0 is a 1999 standard that predates 802.11b.
SSL 3.0 is a standard harking back from 1996, predating 802.11.

Do any clients that you see apart from IE6 (in their default configuration) have a dependency on SSL 3.0?

I would be interested in your rationale for retaining any RC4 - which clients have you seen that need to use it that do not have TLS_RSA_WITH_3DES_EDE_CBC_SHA or TLS_RSA_WITH_AES_128_CBC_SHA available to use as a more secure, preferable alternative? If it is the case that there are no known clients that need RC4, what is the justification for this?

Additionally, if you feel you need to retain an RC4 ciphersuite under TLS, which is plausible, why would you also retain the one that uses MD5 in its HMAC construction? There are surely no clients what-so-ever that implement TLS_RSA_WITH_RC4_128_MD5 but not TLS_RSA_WITH_RC4_128_SHA. I am unsure what the justification might be for this?

Cisco have also published guidance stating that RC4 should be avoided:

"Algorithms marked as Avoid do not provide an adequate security level against modern threats and should not be used to protect sensitive information. It is recommended that these algorithms be replaced with stronger algorithms."

http://www.cisco.com/web/about/securi...

Do you actually wish to support IE 6.0 under Windows XP in the 'worst case' where TLS 1.0 support is disabled by default? I would be genuinely surprised if you test with it these days, most people do not. I would have thought it reasonable to expect people to be using at least IE 8.0, or Firefox or Chrome under XP. Windows XP exits all support from Microsoft early next year.

That is largely moot though as you can deploy a policy change via Group Policy to resolve this or tick the checkbox to enable TLS 1.0 for any hypothetical hardcore refuseniks still holding out and rocking on with IE 6.0 while being unable to use much of the modern Web:



(It is implemented by the crypto functionality provided by SCHANNEL, an operating system component, and just needs to be enabled just for IE.)

Perhaps the appropriate compromise would be to have a configuration option to weaken the posture for those that might need it?

Finally, what is client initiated renegotiation used for in Aerohive's use cases? It surely serves no purpose at all: if it is not used at all presently, surely it just exposes you unnecessarily? I agree that this is a more marginal and debatable issue and can also be resolved through implementation specific mitigation. On balance, it should not be seen to affect PCI compliance.

To sum up: An evidence based justification would be fantastic! :)

Cheers,

Nick
Photo of Chris Ellis

Chris Ellis

  • 8 Posts
  • 2 Reply Likes
I fail to see any reason for enabling ciphersuites which are using MD5 based HMAC. I disabled MD5 on servers I've configured for a number of years now.

Mike, you state "We all live in the real world that has other than Microsoft products to deal with." However you also state "We are leaving SSL3.0 enabled. According to the Qualys test tool, the only popular combination of OS/browser that will fall back to this is IE6/WinXP, which will use TLS_RSA_WITH_RC4_128_MD5." these points are contradicatory.

As I understand it, if RC4 was not offered IE6/WinXP would choose SSL_RSA_WITH_3DES_EDE_CBC_SHA. With the only concern being the performance impact of 3DES over RC4. However a sane security baseline should take precedence.

If your reasoning for leaving SSL3.0 enabled is to support WinXP, then come April 2014 when WinXP leaves suppport and can even more so be considered legacy, will SSL3.0 be disabled?

Products should ship with good security baselines and should react to how the security landscape morphs. If there is a need for administrators to reduce security in-favour of compatiblity with legacy devices, this should be a considered and reasoned action by them.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Mike,

Now that 6.1r3 is here, I have retested. Much, much better... :) but...

TLS 1.2 is misconfigured, the protocol is offered yet there are no TLS 1.2 cipher suites offered.

This can and should be corrected by including TLS_RSA_WITH_AES_128_CBC_SHA256.

Perhaps this can be done for 6.1r4?

The SSL labs test currently gives the posture an A- due to the lack of forward secrecy, but due to an error / oversight in the test it is not highlighting the cipher suites issue with TLS 1.2. I have contacted Ivan Ristic who maintains the test asking if he will correct it. This may drop the score to a B.

Edit: The reply to this is:

"Probably. Most such sites are not going to support TLS 1.2 and are going to get a B anyway. At the moment, if you support TLS 1.2 but you use old cipher suites with it, you're going to get an A- (assuming everything else is in order, of course). I think that's likely going to change to a B in the (possibly near) future."

Nick
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Nick,
Baby steps. You are correct that we have not enabled any TLS 1.2 specific cipher suites, but we do successfully and correctly implement TLS 1.2 and establish connections using our supported cipher suites with browsers that support that.

I am personally still working towards getting support for client-side renegotiation removed, and to enable Forward Secrecy.

I cannot make any promises about timeframes, but 6.1r4 is where I am aiming.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Anyway, I think this can perhaps be closed as resolved if you consider the other issues out of scope.