998135 - Work around incompatibility with Cisco products caused by the TLS padding extension

Status: RESOLVED INCOMPLETE

(NSS :: Libraries, defect, P1)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

A test site for this is https://www.wbxmeeting.com. The problem is that the server cannot decode a TLS 1.2 handshake with the 

Wan-Teh Chang wrote in bug 989062 comment 10:
> https://www.wbxmeeting.com cannot decode a TLS 1.2 ClientHello with
> a padding extension produced by NSS. However, it can decode a TLS 1.1
> ClientHello with a padding extension produced by NSS. I have found a
> workaround in NSS, but we should report this bug to the vendor of the
> SSL/TLS library used by https://www.wbxmeeting.com.

Wan-Teh's patch is attached to that bug. It simply reorders the extensions in the TLS handshake. My concern with Wan-Teh's patch is that it has the potential to introduce new incompatibilities if there are other order-dependent servers. However, that simply requires more testing to see if it causes any regressions.

See http://www.ietf.org/mail-archive/web/tls/current/msg12145.html for some alternative suggestions for workarounds. I have a feeling that such workarounds may work well for products that don't send ALPN and which have a short list of cipher suites in the ClientHello (e.g. current versions of Firefox), but they may work poorly for other clients (e.g. current versions of Chrome and probably future versions of Firefox).

It would be good to hear from Wan-Teh more about what he learned about this in his testing.

I am not sure if this can make the NSS 3.16.1 release. I think a fix for this is important for Firefox 30.

Comment 1

[Wan-Teh Chang]

We need guidance from Cisco WebEx about this bug. I attached my patch
just to share my findings about the bug. That patch is not intended for
checkin.

Comment 2

[Eric Rescorla (:ekr)]

I reached out to Cisco

Comment 3

[Cullen Jennings]

This is now Cisco bug CSCuo03023

Comment 4

[Ben Watt]

Cisco has given this a status of terminated, so it looks like this is something that is going to need to be resolved on the Mozilla end. Any progress on fixing this?

Comment 5

[Eric Rescorla (:ekr)]

Cullen, can you elaborate here?

Comment 6

[Cullen Jennings]

I'm trying to find out what is going on with this. I will guess that I will know by the end of week.

Comment 7

[Cullen Jennings]

I still do not understand what is going on here but let me drop a few more bread crumbs that might help.

The server is allegedly running some version of OpenSSL 0.9.8. Evidently the change to OpenSSL in http://cvs.openssl.org/chngview?cn=22567 fixes the problem. I have not dug into making sense of any this yet but if that makes sense to anyone else, please enlighten me.

Comment 8

[Wan-Teh Chang]

Cullen:

The change to OpenSSL in http://cvs.openssl.org/chngview?cn=22567
is a client-side change. So it should not affect server-side
behavior. Also, NSS has the same logic on the client side. See
this code excerpt the ssl3_SendClientHello function in ssl3con.c:

    flags = 0;
    if (!ss->firstHsDone && !IS_DTLS(ss)) {
        flags |= ssl_SEND_FLAG_CAP_RECORD_VERSION;
    }

http://mxr.mozilla.org/nss/ident?i=ssl_SEND_FLAG_CAP_RECORD_VERSION

Comment 9

[Ben Watt]

Any further progress on this? It's still marked as terminated on Cisco's end.

Comment 10

[Cullen Jennings]

Just put a long comment on this topic at 

https://bugzilla.mozilla.org/show_bug.cgi?id=989062#c30

As far as I can tell, Wan-Teh patch would work fine with the at least the bulk of our servers which are OpenSSL based.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Cullen Jennings from bug 989062 comment #34)
> The Cisco side is getting fixed up - I don't have an ETA but the new cisco
> bugs numbers are CSCuq98568 and CSCur02612. I hope to see this in CWMS
> version 2.0 MR5

In that other bug, one of Cisco's customers pointed out that the latest release of Cisco's product does indeed have a bug here. Then Cisco reopened the bug and apparently will fix it in MR5. The release notes for Cisco's Orion product are at: http://www.cisco.com/c/en/us/td/docs/collaboration/CWMS/2_0/Release_Notes.html. Not that MR4 is the latest maintenance release mentioned in that document.

Further, OpenSSL and/or LibreSSL has/have changed their default configurations so that they do not ever send the padding extension unless it is explicitly enabled by the application:
http://opensslrampage.org/post/98583119714/move-the-tls-padding-extension-under-an
http://comments.gmane.org/gmane.comp.encryption.openssl.devel/24906

I do think it is worthwhile to find a workaround for this on the client side of NSS considering that current version of at least one Cisco server product have this bug.

It would be good to hear from Cisco about what exactly works and what the specific issue in the MR4 version of Cisco's server software is, so we know what order to put the ClientHello extensions in. Even knowing the (exact) version of OpenSSL that is being used by that server would be useful.