TLS_FALLBACK_SCSV (server-side)

[rob_moss]

The CommonCryptoLib already supports TLS_FALLBACK_SCSV as a client. This prevents susceptibility to attacks on the SSL/TLS client which depend on protocol downgrades.

However, as a server, TLS_FALLBACK_SCSV isn't supported by the CommonCryptoLib. Suppose we have the case where we must provide compatibility with Internet Explorer 6.0 on Windows XP, in an environment where we do not control the user settings, and hence must provide support for SSL 3.0. Whilst IE6 will always be vulnerable to the POODLE attack because by default it will only connect over SSL 3.0, even if our server supports TLS 1.0, 1.1 and 1.2, a MITM attack can always drop any other browser down to SSL 3.0 without support for TLS_FALLBACK_SCSV.

There is a way to mitigate the POODLE attack on SSL 3.0, which is to use record splitting. Also, disabling CBC ciphers over SSL 3.0 will mitigate the vulnerability. Opera have taken the first option and Apple the second. However, record splitting causes compatibility issues due to problems in server-side implementations, and disabling CBC ciphers leaves only RC4 over SSL 3.0, which has also been broken. This leaves many browsers still vulnerable to POODLE, in particular in the mobile space, unless we disable SSL 3.0 on the server side.

Furthermore, there is a TLS 1.0 POODLE exploit affecting servers which fail to check the padding byte requirements. A server demonstrating this vulnerability and not implementing TLS_FALLBACK_SCSV will allow an attacker to roll the browser back from TLS 1.2 or 1.1 to 1.0 in order to use the exploit.

These may not the only attacks that will ever be discovered against older protocols. The draft of TLS 1.3 removes numerous deprecated features from TLS 1.2 which are seen to weaken security, such as compression, renegotiation, non-AEAD ciphers, static RSA and DH key exchange, custom DHE groups, point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers. If and when new attacks against these features are found and TLS 1.2's (and/or earlier) security is weakened, without TLS_FALLBACK_SCSV support, users will be vulnerable.

There is a flip-side to all this. The reason protocol downgrades are possible is because early implementations of TLS 1.0, 1.1 and 1.2 were often broken. The protocol downgrade occurred when a client couldn't initiate a session with the broken server. TLS_FALLBACK_SCSV doesn't convey any version information and as such becomes a "never fall back" signal. This means that a server implementing TLS_FALLBACK_SCSV with a broken TLS 1.2 implementation will lose the ability to serve requests to the majority of clients. That's Microsoft's view of things, which is why neither IE nor IIS implement the flag.

However, given the inherent insecurity of older protocol versions, I'm not sure SAP should be following Microsoft's lead here, but instead should be following Google and Mozilla.

What is the view of the wider community on whether this flag should be implemented? Do the compatibility concerns outweigh the security advantages, or vice versa?

[Former Member · Accepted solution]

Hello Rob,

CommonCryptoLib does not support TLS_FALLBACK_SCSV as a client. Currently, there are no client applications on top of CommonCryptoLib, which would do a downgrade dance. So there is no need to protect against it on the client side. Right, we do not even support TLS_FALLBACK_SCSV on server side. Implementation of RFC 7507 as is, may cause severe interoperability problems and we did not see a straight way out. Upon receipt of TLS_FALLBACK_SCSV, the server has no other chance than to cancel the handshake. TLS_FALLBACK_SCSV gives a server too few information about the client's downgrade dance to take a better decision than to slam the door, crying "you are a downgrade dancer". Now it's up to the client to try an upgrade dance.
Implementation of TLS_FALLBACK_SCSV on server side does not make sense, if no client uses it. Unfortunately, the great downgrade dancers among popular browsers do not support it.
Even if they did, this would not resolve any inter-op problems: There are servers, who slam the door without a whisper upon receipt of a ClientHello.version==TLS1.2 . Or, they are allergic to TLS extensions but omit to send an appropriate alert.
What happens?
1. The client tries TLS1.2 with some extensions,
2. the server gets stuck and swallows the alert,
3. the client sends a new Hello with the SCSV in it, the server answers with an inappropriate_fallback - alert
4. Now, RFC 7507 says, that a client should retry with the highest TLS version it supports.
5. Thus, RFC 7507 advises the Client to return to step 1.

They won't ever come together.

Hope that helps

Kindest regards
André

[Former Member · Accepted solution]

I wrote:

Even if they did, this would not resolve any inter-op problems:

It should be:

Even if they did, this would not resolve all inter-op problems:

Sorry for that.

André

[rob_moss · Accepted solution]

Hi Andre,

I notice that at least websmp*.sap-ag.de and help.sap.com now support TLS_FALLBACK_SCSV. Does this mean that the interop concerns have been outweighed by the security concerns and that we might expect to see this in CommonCryptoLib any time soon?

Many thanks,

Rob

[Former Member · Accepted solution]

Hi Rob,

As far as CommonCryptoLib is concerned, there is no support for TLS_FALLBACK_SCSV.

There are no new opinions nor perceptions about TLS_FALLBACK_SCSV on our side.

Apparently, the hosts websmp*.sap-ag.de and help.sap.com are run with another TLS-agent. Several SAP systems work with an upstream 3rd party load balancer, which uses a 3rd party TLS engine.

Kindest regards

André

[rob_moss · Accepted solution]

So there's not even a chance that it might be supported via a disabled-by-default profile parameter? As things currently stand, I have to use a third-party reverse proxy (namely Apache) in front of the SAP Web Dispatcher just to pass a standard penetration test, as the security industry disagrees with your stance on interoperability here, and I have to answer to them. I'd rather not have to introduce a whole load of extra potential security flaws by using a piece of software to introduce a single TLS extension but it seems that I have no choice at the moment.

[Former Member · Accepted solution]

Hi Rob,

we will discuss the topic in our team in January again.

As far as I know, the large browser vendors still do not support TLS_FALLBACK_SCSV.

Implementation of TLS_FALLBACK_SCSV on server side will not have any effect, if browsers are not willing to deploy it.

Kindest regards and best wishes for the new year

André

[rob_moss · Accepted solution]

Hi André,

Just to clarify, the major browser vendors' support of TLS_FALLBACK_SCSV is as follows:

Chrome: Since version 33, February 2014.

Firefox: Since version 35 and ESR 31.3, December 2014.

Internet Explorer: No support planned.

Edge: No comment from Microsoft yet.

Safari: No comment from Apple.

Opera: Since version 20, March 2014.

And the major TLS stacks:

NSS: Since version 3.17.1, September 2014.

OpenSSL: Since versions 1.0.1j, 1.0.0o and 0.9.8zc, October 2014.

BoringSSL: Since June 2014 (pre-release).

LibreSSL: Since February 2015 (can't find the version number).

Apple have decided against including TLS_FALLBACK_SCSV support in the App Transport Security rules in iOS 9.0 but have mandated TLS 1.2 support. It's currently expected they will follow suit in Safari, according to those who appear to have insider knowledge, at some point in 2016.

The PCI-DSS 3.1 rules say that SSL 3.0, TLS 1.0 and TLS 1.1 must be disabled by June 30th 2016 for any business taking any form of credit card payment so a lot of old browsers will be killed off and this will probably become a moot point. However, for those of us who can't afford to follow that rule, we need a mechanism to support TLS 1.0 and TLS 1.1 clients that a QSA will be willing to sign off, and I won't be able to get them to do that without TLS_FALLBACK_SCSV support - I've already been told as much. The global market share of browsers without support is around 30%, and with support is around 70%.

Have a great Christmas and best wishes for the New Year and I'm hoping for some good news in 2016!

t

[former_member476865 · Accepted solution]

Just to clarify a few urban myths you cited.

TLS_FALLBACK_SCSV has an extremely limited usefulness and creates certain interop risks (which the folks who invented the stupid idea of a handshake failure could have easily fixed by continuing the handshake successfully and signalling back to the client, but refused to do).

The only "real advantage" of this it to prevent downgrade to SSLv3, and only for applications which perform a known-insecure "Downgrade Dance" -- which are only web browsers.

The same protection can be achieved by disabling SSLv3 entirely, and this is what browsers did.  (Microsoft didn't, but they also do not support TLS_FALLBACK_SCSV), and you can easily disable SSLv3 on the server-side today, if you have a bad feeling about it.

The benefit of TLS_FALLBACK_SCSV for TLSv1.0 and above is sufficiently close to zero, that it is completely irrelevant.

PCI compliance does *NOT* require disabling of TLSv1.0 and TLSv1.1 on the server.  Just the OPPOSITE.  PCI compliance requires that you enable TLSv1.2, and that the server uses TLSv1.2 when it is offered (something which OpenSSL&Apache fails to do by default).  And PCI compliance requires that you _leave_TLSv1.0_and_TLSv1.1_enabled_ on your server, so that PCI-compliant, TLSv1.0-only client will be able to connect!!!

You do not need a risk assessment for your server when leaving TLSv1.0 or TLSv1.1 enabled.  This usage scenario is covered by the risk assessement performed by TLSv1.0-only PCI clients, and will only be used with those clients.

It seems that there are a few clueless/broken PCI-compliance scanners (commercial ones) which erroneously flag the availability of TLSv1.0 and TLSv1.1 in addition to a prefered TLSv1.2 on a server as a compliance issue.  This is clear defect of the scanner and needs to be taken to the vendor/supplier of that scanner.

-Martin

[rob_moss · Accepted solution]

Hi Martin,

That simply isn't true. Although the deadline has changed from June 30th 2016 to June 30th 2018 (just before I made my last post, unbeknownst to me), migrating away from early TLS is still a requirement of PCI-DSS 3.1. Please see:

https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement...

Date Change for Migrating from SSL and Early TLS

https://www.pcisecuritystandards.org/pdfs/15_12_18_SSL_Webinar_Press_Release_FINAL.pdf

The PCI firm we work with have confirmed that they have received clarification on this point from the Council. TLS 1.1 and TLS 1.2 are OK to continue to use. SSL 3.0 and TLS 1.0 are not OK to continue to use unless you have a Risk Mitigation and Migration Plan. Furthermore, if anything flags up with a CVSS score of 4.0 or higher (as SSL 3.0 invariably does) then you can't pass a PCI-DSS assessment, so SSL 3.0 is really gone already.

To make things absolutely clear: TLS 1.0 is not OK any more, and if your organisation processes card payments, you either have to drop it, or have a documented plan to drop it by June 30th 2018. Interop is not a valid excuse to support TLS 1.0 past this date.

[former_member476865 · Accepted solution]

Dear Rob,

I'm sorry, but you seem to be looking at the wrong documents (awfully clueless and misleading documents admittely).  Some of what the clueless documents say is formally provable nonsense,

and it is in contradiction to the actual specification.

The applicable PCI specification is PCU 3.2 (April 2016), what is relevant, and the true (and reasonable) technical requirements about SSL/TLS are described in Appendix A.2 of the PCI 3.2 spec.

Official PCI Security Standards Council Site - Verify PCI Compliance, Download Data Security and Cre...

https://www.pcisecuritystandards.org/document_library

The cryptographic differences between TLSv1.0 and TLSv1.1 are marginal.  The alleged (TLSv1.0 CBC) weakness can only be exploited when the attacker has profound control over a communication endpoint, for "recovering plaintext through repeated guessing".  The alleged weakness can be reliably mitigated by 1/(n-1) record splitting (the well-known BEAST countermeasure) for those scenarios where the weakness is relevant at all (which is _only_ Web-Browsers and SSL-VPNs in combination with disclosing authentication).  When using SSL client cert authentication, the weakness becomes entirely irrelevant (actually irrelevant even for SSLv3).  For programmatic clients, which neither execute arbitrary attacker-supplied active content, not provide a CSRF-vulnerability to that attacker-supplied active content, and not perform any app-level well-known insecure TLS protocol "Downgrade Dance"s (the Web Browser design flaw that is a prerequisite to POODLE), the known weakness are irrelevant.

Quoting PCI DSS 3.2, Appendix A.2

-----------

The SUMMARY(!!) says:

SSL and early TLS should not be used as a security control to meet these requirements. To support entities working to migrate away from SSL/early TLS, the following provisions are included:

• New implementations must not use SSL or early TLS as a security control.
• All service providers must provide a secure service offering by June 30, 2016.
• After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol (an allowance for certain POS POI terminals is described in the last bullet below).
• After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol (an allowance for certain POS POI terminals is described in the last bullet below).
• Prior to June 30, 2018, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
• POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after June 30, 2018.

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

The actual technical requirements:

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

A2.1 Where POS POI terminals (and the SSL/TLS termination points to which they connect) use SSL and/or early TLS, the entity must either:

   * Confirm the devices are not susceptible to any known exploits for those protocols.

Or:

   * Have a formal Risk Mitigation and Migration Plan in place.

A2.3 Additional Requirement for Service Providers Only: All service providers must provide a secure service offering by June 30, 2016.

Note: Prior to June 30, 2016, the service provider must either have a secure protocol option included in their service offering, or have a documented Risk Mitigation and Migration Plan (per A2.2) that includes a target date for provision of a secure protocol option no later than June 30, 2016. After this date, all service providers must offer a secure protocol option for their service.

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

Must offer a secure protocol option for their service means that the service providers must support and prefer TLSv1.2 when offered.   This does *NOT* mean, that they should (or would have to) disable TLSv1.1 or TLSv1.0.

-Martin

[rob_moss · Accepted solution]

Hi Martin,

POS POI terminals are a special case. I have it in writing, sat on my desk as I type this, that "secure protocol option" means that SSL v3.0 and TLS v1.0 must be disabled, and TLS v1.1 and/or TLS v1.2 must be enabled. The photocopied letter is addressed to our PCI partner from the PCI Security Standards Council. I'm afraid I'm going to take the PCI Security Standards Council's word for it on how to interpret the standard written by the PCI Security Standards Council.

Rob

[former_member476865 · Accepted solution]

Hi Rob,

This artificial distinction between TLSv1.0 and TLSv1.1 is formally provable technical nonsense, so I'm going to read it in the fashion that makes sense (in a scientific sense) and is meant by NIST.

-Martin

[rob_moss · Accepted solution]

Hi Martin,

Whether it's "formally provable technical nonsense" or otherwise, and regardless of what you think NIST might have intended to mean (even though they specifically call out TLS v1.0 as being unsuitable and forbidden for intragovernmental communication), if we end up in court following a security breach and loss of cardholder data, our only defense is whether or not we followed the rules set down by the PCI SSC. We will follow the rules as set down by the PCI SSC, and their interpretation of them, as that's the only responsible course of action a business can take.

For this reason, and owing to the absence of (even if it were disabled-by-default) TLS_FALLBACK_SCSV support, we've had to disable TLS v1.0 and have had a few problems with clients not supporting modern TLS versions. Fortunately, they've been quite responsive, with the exception of a certain bank still running Windows NT 3.1 to provide merchant services.

Rob

[former_member200373 · Accepted solution]

And, just to make this thread even more colourful, we plan to support TLS_FALLBACK_SCSV in one of the next releases of CommonCryptoLib.

We´ll keep you in the loop.

-- Stephan

[rob_moss · Accepted solution]

Fantastic news, thanks Stephan!

[former_member476865 · Accepted solution]

Rob,

Which part of the word "secure service option" in the requirements for service providers in the official PCI-DSS 3.2 spec, Requirement A2.3 is unclear to you?

What you allege would need wording such as "secure-only service mandate" -- which clearly is *NOT* what the PCI-DSS spec says.

Btw. this discussion is about the TLS_FALLBACK_SCSV, which is completely irrelevant in the face of PCI-DSS discussions, because it is clearly impermissible for a PCI-DSS compliant client to perform a TLS protocol version downgrade dance at all, so this signaling cipher suite can *NOT* be used (and will never appear) in any PCI-DSS compliant communication.

-Martin

[rob_moss · Accepted solution]

Hi Martin,

I'm not alleging it. The PCI SSC are alleging it. That's not up to me. Feel free to take it up with them if you like:

PCI SSC (@PCISSC) | Twitter

Clients which provide cardholder data to service providers do not themselves need to be PCI-DSS compliant. We know that we have a wide variety of browsers using our services as clients and we need to ensure that the credit card data we capture is transmitted securely and according to the PCI-DSS specifications. It is incumbent on us to make that process as secure as possible. We use HSTS, HPKP, strong cipher suites and protocols and a variety of other methods to make our communication with clients as secure as possible. TLS_FALLBACK_SCSV is another defense we want to use, particularly seeing as our QSA would sign us off for continued use of TLS v1.0 until 2018 if it was there. Remember that every use case is different.

Rob

[Former Member · Accepted solution]

Hello Rob,

Good things come to those who wait…

We proudly announce that server-side support of TLS FALLBACK SCSV is now available with CommonCryptoLib 8.5.2. You find it on the SAP market place. Enjoy.

To enable it, just add the key word TLS_FALLBACK_SCSV to the TLS cipher suite configuration parameter in your server profile. It must not appear in front of the version flags. It must appear before any ECC configuration key word.

Example for AS-ABAP:

Old: ssl/ciphersuites=512:PFS:HIGH::EC_HIGH

New: ssl/ciphersuites=512:PFS:HIGH:TLS_FALLBACK_SCSV::EC_HIGH

If the new key word is missing, any received TLS fallback signal is treated by the server like an unknown cipher suite, i.e. it is just ignored.

To get more help, just play with the command line tool "sapgenpse tlsinfo".

Thank you for your patience

Kindest regards

André Ziermann

[rob_moss · Accepted solution]

Fantastic! Thanks André!