Closed Bug 1341375 Opened 7 years ago Closed 7 years ago

FF 52 sends SSL instead of TLS record layer

Categories

(NSS :: Libraries, defect, P3)

Product:
NSS
Component:
Libraries
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1317857

People

(Reporter: hartman1205, Unassigned)

Details

Attachments

(2 files)

Sniffer showing the SSL handshake for the problematic scenario
113.44 KB, image/jpeg
Details
Sniffers for various min_max values on FF 52
71.08 KB, application/x-rar
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

We have a server that supports TLS1.0/1.1/1.2 and restricts SSL. FF 52 beta's tls config is min=1 and max=4 by default. Upon trying to access our server over HTTPS with FF 52, we are getting the below error -

Secure Connection Failed

The connection to xx.xx.xx.xx was interrupted while the page was loading.

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.


Actual results:

Packet captures show Client Hello to be carrying SSL record layer instead of TLS record layer. This happens if the max value is set as 3 or 4. For other values of min-max, Client Hello is properly sent. (min=1 and max=1 [TLSv1], min=1 and max=2 [TLSv1.1], min=2 and max=2[TLSv1.1])
With FF 51.0.1, everything worked just fine.


Expected results:

We should have been able to connect with our server with FF 52. FF 52 should have sent a TLS record layer instead of SSL record as like FF 51.0.1.
Severity: normal → major
OS: Unspecified → All
Priority: -- → P3
Hardware: Unspecified → All
This is conformant with the RFC. S E.2 says:

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

I'm not sure exactly why we are doing it differently for different versions,
but I'm also not sure we should change it. What does the server do in response?
If you want to provide a URL we can take a look.
Flags: needinfo?(martin.thomson)
(In reply to Eric Rescorla (:ekr) from comment #1)
> This is conformant with the RFC. S E.2 says:
> 
>    TLS clients that wish to negotiate with older servers MAY send any
>    value {03,XX} as the record layer version number.  Typical values
>    would be {03,00}, the lowest version number supported by the client,
>    and the value of ClientHello.client_version.  No single value will
>    guarantee interoperability with all old servers, but this is a
>    complex topic beyond the scope of this document.
> 
> I'm not sure exactly why we are doing it differently for different versions,
> but I'm also not sure we should change it. What does the server do in
> response?
> If you want to provide a URL we can take a look.

Thanks Eric for having a look into this. I guess that we may not able to share the URL as this is not a website as such and it is local to our access. I shall check if it is even possible to make the server available for access.

From the sniffer, we don't see any response from our server for the problematic scenario. But we do see a response from our server when the min/max value is played with as mentioned in the defect notes.

Couple more questions based on the reply-
"TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version"
How does the client know what record layer to send? Will this behavior be independent of the TLS min/max values? 
When our server is configured to accept requests over TLSv1/1.1/1.2 and with FF configured to send min=1 and max=3, why is the client trying to negotiate with SSL record layer?
Why is that the client is able to send a proper TLS record when the min max values are altered?

Thanks!
(In reply to Theophilus from comment #2)
> (In reply to Eric Rescorla (:ekr) from comment #1)
> > This is conformant with the RFC. S E.2 says:
> > 
> >    TLS clients that wish to negotiate with older servers MAY send any
> >    value {03,XX} as the record layer version number.  Typical values
> >    would be {03,00}, the lowest version number supported by the client,
> >    and the value of ClientHello.client_version.  No single value will
> >    guarantee interoperability with all old servers, but this is a
> >    complex topic beyond the scope of this document.
> > 
> > I'm not sure exactly why we are doing it differently for different versions,
> > but I'm also not sure we should change it. What does the server do in
> > response?
> > If you want to provide a URL we can take a look.
> 
> Thanks Eric for having a look into this. I guess that we may not able to
> share the URL as this is not a website as such and it is local to our
> access. I shall check if it is even possible to make the server available
> for access.
> 
> From the sniffer, we don't see any response from our server for the
> problematic scenario. 

Can you provide a little more detail here. Is it sending a TCP RST? A FIN?


> But we do see a response from our server when the
> min/max value is played with as mentioned in the defect notes.
> 
> Couple more questions based on the reply-
> "TLS clients that wish to negotiate with older servers MAY send any
>    value {03,XX} as the record layer version number.  Typical values
>    would be {03,00}, the lowest version number supported by the client,
>    and the value of ClientHello.client_version"
> How does the client know what record layer to send? Will this behavior be
> independent of the TLS min/max values? 

This isn't in the spec, so the client can do either.


> When our server is configured to accept requests over TLSv1/1.1/1.2 and with
> FF configured to send min=1 and max=3, why is the client trying to negotiate
> with SSL record layer?

It's not. There are interop problems with basically any record layer value
you send, because the documents weren't clear and a lot of servers are broken
so it's trying to compensate for that.


> Why is that the client is able to send a proper TLS record when the min max
> values are altered?

As I said, the client is conforming with the specification here in both cases,
but I'm not sure why it's behaving differently. I can look into that, but it
would be good to understand how your server is behaving.

> 
> Thanks!
I can't reproduce this.

Here's Firefox Beta talking to netcat on my local machine

00000000  16 03 01 02  00 01 00 01  FC 03 03 80  C7 62 FB 96  .............b..
Can you please provide more information about the exact configuration you are running
Flags: needinfo?(martin.thomson) → needinfo?(hartman1205)
(In reply to Eric Rescorla (:ekr) from comment #6)
> Can you please provide more information about the exact configuration you
> are running
Hi Eric,
Can you please specify what configurations you are interested in?
Our server is deployed with Tomcat 6 and JRE 1.7 running on RHEL 6. We are using NSS(nss-3.16.1-4.el6_5.x86_64) and JSS for the SSL implementation.
Further, when SSL record layer is not negotiated by the server, why isn't the client attempting to negotiate with the next available protocol? - as it is in the interest of the client to send the Hello protocol.

I'm as well checking with my managers if we can have a meeting so that you can have a han don our server.
k(In reply to Theophilus from comment #7)
> (In reply to Eric Rescorla (:ekr) from comment #6)
> > Can you please provide more information about the exact configuration you
> > are running
> Hi Eric,
> Can you please specify what configurations you are interested in?
> Our server is deployed with Tomcat 6 and JRE 1.7 running on RHEL 6. We are
> using NSS(nss-3.16.1-4.el6_5.x86_64) and JSS for the SSL implementation.
> Further, when SSL record layer is not negotiated by the server, why isn't
> the client attempting to negotiate with the next available protocol? - as it
> is in the interest of the client to send the Hello protocol.
> 
> I'm as well checking with my managers if we can have a meeting so that you
> can have a han don our server.

Sorry, my question is about the client instance. As I said, I can't reproduce
this with my own copy of Firefox. I no longer need access to your server.

The reason that the client would send a lower version is historical: the
specification says that the ClientHello.version field (in the handshake)
is your highest one but it isn't very clear about the record layer. As
a consequence, some servers choke on one version (e.g., a new one) or
another. For this reason, clients have to do a certain amount of backward
compat and one way to do that is to use a lower version number in the
record version, hence the section of the spec I indicated. However, in
my tests, Firefox 52 offers 0301 (TLS 1.0), so I'm unable to reproduce your
behavior, which I do not believe is intended.
(In reply to Eric Rescorla (:ekr) from comment #8)
> k(In reply to Theophilus from comment #7)
> > (In reply to Eric Rescorla (:ekr) from comment #6)
> > > Can you please provide more information about the exact configuration you
> > > are running
> > Hi Eric,
> > Can you please specify what configurations you are interested in?
> > Our server is deployed with Tomcat 6 and JRE 1.7 running on RHEL 6. We are
> > using NSS(nss-3.16.1-4.el6_5.x86_64) and JSS for the SSL implementation.
> > Further, when SSL record layer is not negotiated by the server, why isn't
> > the client attempting to negotiate with the next available protocol? - as it
> > is in the interest of the client to send the Hello protocol.
> > 
> > I'm as well checking with my managers if we can have a meeting so that you
> > can have a han don our server.
> 
> Sorry, my question is about the client instance. As I said, I can't reproduce
> this with my own copy of Firefox. I no longer need access to your server.
> 
> The reason that the client would send a lower version is historical: the
> specification says that the ClientHello.version field (in the handshake)
> is your highest one but it isn't very clear about the record layer. As
> a consequence, some servers choke on one version (e.g., a new one) or
> another. For this reason, clients have to do a certain amount of backward
> compat and one way to do that is to use a lower version number in the
> record version, hence the section of the spec I indicated. However, in
> my tests, Firefox 52 offers 0301 (TLS 1.0), so I'm unable to reproduce your
> behavior, which I do not believe is intended.

Thanks for patiently clarifying on the queries. We tried with MAC OS, Windows 7 and Windows 2008 R2. That said, do we still assume backward compatibility is a factor here?
Downloaded at - https://download-installer.cdn.mozilla.net/pub/firefox/releases/52.0b8/win32/en-US/Firefox%20Setup%20Stub%2052.0b8.exe
I shall upload the sniffer for various min max values on FF 52 against our server. Kindly let me know if that has any clue of what is going wrong.

But sorry to mention it again - the same server works perfectly good with FF 51.0.1 on the above mentioned clients without any issues. So we suspect some change that is introduced in this version of FF 52 is misbehaving, at least with our servers!
(In reply to Theophilus from comment #9)
> (In reply to Eric Rescorla (:ekr) from comment #8)
> > k(In reply to Theophilus from comment #7)
> > > (In reply to Eric Rescorla (:ekr) from comment #6)
> > > > Can you please provide more information about the exact configuration you
> > > > are running
> > > Hi Eric,
> > > Can you please specify what configurations you are interested in?
> > > Our server is deployed with Tomcat 6 and JRE 1.7 running on RHEL 6. We are
> > > using NSS(nss-3.16.1-4.el6_5.x86_64) and JSS for the SSL implementation.
> > > Further, when SSL record layer is not negotiated by the server, why isn't
> > > the client attempting to negotiate with the next available protocol? - as it
> > > is in the interest of the client to send the Hello protocol.
> > > 
> > > I'm as well checking with my managers if we can have a meeting so that you
> > > can have a han don our server.
> > 
> > Sorry, my question is about the client instance. As I said, I can't reproduce
> > this with my own copy of Firefox. I no longer need access to your server.
> > 
> > The reason that the client would send a lower version is historical: the
> > specification says that the ClientHello.version field (in the handshake)
> > is your highest one but it isn't very clear about the record layer. As
> > a consequence, some servers choke on one version (e.g., a new one) or
> > another. For this reason, clients have to do a certain amount of backward
> > compat and one way to do that is to use a lower version number in the
> > record version, hence the section of the spec I indicated. However, in
> > my tests, Firefox 52 offers 0301 (TLS 1.0), so I'm unable to reproduce your
> > behavior, which I do not believe is intended.
> 
> Thanks for patiently clarifying on the queries. We tried with MAC OS,
> Windows 7 and Windows 2008 R2. That said, do we still assume backward
> compatibility is a factor here?

I don't understand your question here. As I said, I can't reproduce the behavior
you are reporting, by which I mean I can't get Firefox to emit the ClientHello
you are saying it does.




> But sorry to mention it again - the same server works perfectly good with FF
> 51.0.1 on the above mentioned clients without any issues. So we suspect some
> change that is introduced in this version of FF 52 is misbehaving, at least
> with our servers!

Let's separate out a bunch of issues. First, if your server is a TLS 1.2 server
and it aborts on a ClientHello with record version 03 00, it is noncomforming:

   Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed).  Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.

However, as I said, my reading of the code is that Firefox in both 51 and 52
is intended to send 03 01 as the record version, and it's not clear to me
why it's not doing that for you, because I can't reproduce it. So, the first
order of business is to find out why.

Matt, can you try and see if it does?
Flags: needinfo?(mwobensmith)
To provide additional info and a short background to Matt - 
We tried enabling SSL3 on our server and hard_coded the range to use 30 as min and 33 as max.
SSLSocket.setSSLVersionRangeDefault(org.mozilla.jss.ssl.SSLSocket.SSLProtocolVariant.STREAM, range);
Still no signs of success. From the sniffer (attached yesterday), we see it sends SSL record layer and mentions the supported to be TLS1.0 and TLSv1.2, even with today's change as well.
It did justify your point of "client code intended to send 1.0", but it is sending within a SSL record layer.
The openSSL client as well gives an output when SSL3 is enabled on the server

~]#  openssl s_client -connect 10.56.61.129:443 -ssl3
SSL handshake has read 1265 bytes and written 250 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : ECDHE-RSA-AES128-SHA
    Session-ID: 63E76498C36DBA9E3A34CED081490EE13864B0E1523C87B856C4B6D41883B904
    Session-ID-ctx:
    Master-Key: 147FBFACA0C83978DD55CB18364682B2D57CCBED7F6DD862F847D56C8F11E7D4D63072D01E30296962605E50B1E18D52
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1487857149
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)

With FF 51.0.1, when FF is configured with min=3 and max=3, it sends 1.2 packet. But with FF52, it sends only SSL. With min=1,max=1, FF 52 sends TLS1.0. With min=2,max=2, FF 52 sends TLSv1.1. So, issue is seen only when numbers are 3,4.
JC, because FF52 is so close, we need to diagnose this aggressively. Can you please have someone follow up?
Flags: needinfo?(jjones)
(In reply to Theophilus from comment #10)
> Created attachment 8839997 [details]
> Sniffers for various min_max values on FF 52

So I took a look at these and the min=3/max=3 file shows a ClientHello with record version 0x0301=TLS 1.0. All other captures in the .rar archive show the same. Am I missing something here?

Also, I checked the ClientHello record version we're sending with FF 51 + 52 and they're always 0x0301. I can't reproduce this either.
(In reply to Tim Taubert [:ttaubert] from comment #14)
> (In reply to Theophilus from comment #10)
> > Created attachment 8839997 [details]
> > Sniffers for various min_max values on FF 52
> 
> So I took a look at these and the min=3/max=3 file shows a ClientHello with
> record version 0x0301=TLS 1.0. All other captures in the .rar archive show
> the same. Am I missing something here?
> 
> Also, I checked the ClientHello record version we're sending with FF 51 + 52
> and they're always 0x0301. I can't reproduce this either.

Hi Tim,
Thanks for looking into this. The problem is not about the protocol WITHIN the record layer, but the PROTOCOL OF THE RECORD layer.
Accepted that, within the record layer, we have TLS1.0 and TLS1.2. The issue is, it is being sent over SSL record layer - why? if it is for the support of old servers, why does it send TLS1.0 and 1.2 within?
Further, when the min=1 and max=4 is set on FF 52, client should be sending 0x0304 within the record layer as its maximum supported protocol along with 0x0301. Why does is send 0x0303 as the maximum supported protocol?
Theophilus,

(In reply to Theophilus from comment #15)
> (In reply to Tim Taubert [:ttaubert] from comment #14)
> > (In reply to Theophilus from comment #10)
> > > Created attachment 8839997 [details]
> > > Sniffers for various min_max values on FF 52
> > 
> > So I took a look at these and the min=3/max=3 file shows a ClientHello with
> > record version 0x0301=TLS 1.0. All other captures in the .rar archive show
> > the same. Am I missing something here?
> > 
> > Also, I checked the ClientHello record version we're sending with FF 51 + 52
> > and they're always 0x0301. I can't reproduce this either.
> 
> Hi Tim,
> Thanks for looking into this. The problem is not about the protocol WITHIN
> the record layer, but the PROTOCOL OF THE RECORD layer.

I believe that this is what Tim checked. Tim?


> Accepted that, within the record layer, we have TLS1.0 and TLS1.2. The issue
> is, it is being sent over SSL record layer - why? if it is for the support
> of old servers, why does it send TLS1.0 and 1.2 within?

> Further, when the min=1 and max=4 is set on FF 52, client should be sending
> 0x0304 within the record layer as its maximum supported protocol along with
> 0x0301. Why does is send 0x0303 as the maximum supported protocol?

Theophilus: as I explained in c1 there is no such requirement to send the maximum
version in the record layer, and that leads to interop failures. Sending either
0301 (our lowest supported version) and 0300 (SSLv3) are both explicitly endorsed
by RFC 5246:


   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

In addition TLS 1.3 explicitly REQUIRES you to send 0301 in the record
layer. https://tlswg.github.io/tls13-spec/#rfc.section.5.1. So as far as
I can tell, we are conformant with the specification.
Hi Eric,
I believe that I did not make it clear enough. I do agree on the RFC part as well the behavior of FF in compliance with it. 
When 1.0 and 1.2 are sent within the record layer, the question is why does it have to send it over SSL layer having no means to connect over SSL? Tried setting min max as 0 still sends SSL record layer with TLS1.0 and 1.2 within. In my opinion, it does make sense if it sends SSL3 within the SSL record layer and that leaves to the question if FF 52 will support SSL3.
Again my point is, we are not saying that the client is not sending TLS1.0 but why does it choose the SSL record layer instead of TLS record layer.
If for any of the min-max values FF sends the same SSL record layer, then it could not be an issue with FF52. But we are able to achieve and communicate by tweaking the tls settings.

And one more test is that, if I don't set any SSL range in our server (SSLSocket.setSSLVersionRangeDefault(org.mozilla.jss.ssl.SSLSocket.SSLProtocolVariant.STREAM, range)), client perfectly communicates over TLSv1 with min=1 and max=4 in FF. If I set the SSL range in our server code, communication breaks.
I believe we will be able to recreate the issue by having SSL implementation like this.

If we are unable to recreate, your advise on this please? How are we to make the client send TLS record layer?

Thanks! Really appreciate your patience and interest in helping us to understand things better.
It's at least confusing to me what we're all talking about, and wireshark at least doesn't seem to be helpful.

In the package containing the client hello message there are at least versions. The first is in the record layer, which should have 0x0301 (TLS 1.0) in it. During the negotiation there usually is 1 record for each packet (but it's not a requirement). In the client hello message inside that record there is an other version which should have the value 0x0303 (TLS 1.2) in it. (Then there can be other version in the extensions that your tool probably doesn't know about, and they're probably not important here.)

Wireshark will at least show this confusing as a TLS1.2 record layer, while the record layer is 1.0 and the client hello 1.2.

The version in the Client Hello might change depending on the max value. If you change the max to 2, it should change to 0x0302.

There might be settings that affect the record layer version for the initial packet, like the minimum version that's supported. I don't know how NSS behaves there.

So my question is, which versions change?

Would it be possible to show the parsed output of something like wireshark, and say with which settings it was generated?
Oh, I didn't see the attachments. In all the packets the record layer is 0x0301, and the client hello version changes depending on the max version like expected.

The only thing I can see is that you're never able to talk TLS 1.2, but can talk TLS 1.0 and TLS 1.1.
Hi Kurt,
Yes. There can be multiple handshake messages, but should not the client be choosing the maximum to begin with?
The record layer is not 0x0301. If so, why does the capture read it as SSL record layer?

Secure Sockets Layer
    We are referring here -----------------> SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301) <---- You are referring here.
        Length: 512
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 508
            Version: TLS 1.2 (0x0303)

We should have received a TLSv1.2 record layer a slike FF 51.0.1. 

The record layer changes when the min max values are altered. In our case, if max value is 3/4, the record layer always reads SSL with 1.0 and 1.2 within.
Yes. With FF 52 our servers are not been able to talk over TLSv1.2 which is why we wanted to have it clarified with Mozilla, as the same server worked perfectly with FF 51.0.1.
If our servers are unable to read TLS1.2 with FF 52, is it not because of SSL implementation in FF52 which has undergone a change?
If there is a flaw with our server, then it should not be able to communicate over any of the SSL protocols as it can be marked as IT IS NOT ABLE TO READ the request properly with FF52.

Thanks!
BTW, the captures are named as per the min max configuration set on FF 52. And the archive has a capture by the name min3max3 - but unexpectedly, even here the record layer sent is "SSL" with 0x0301 and 0x0303
This line is wireshark being confusing, ignore whatever it says:
    SSL Record Layer: Handshake Protocol: Client Hello 
        Content Type: Handshake (22)

This line is the record layer version:
        Version: TLS 1.0 (0x0301)
        Length: 512
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 508

This line is the client hello version:
            Version: TLS 1.2 (0x0303)

The record layer in all your captures is 0x0301. The client hello version changes with the max setting.
I agree with Kurt here, I can't see a valid reason for why Wireshark would categorize one but not the other as an "SSL record". The record layer format didn't change since SSL3/TLS 1.0, and they're both similar ignoring different record lengths and extensions.
Hi Tim,
If the record layer format hadn't changed between SSL3 and TLS1.0, then for min=1 and max=1 shouldn't have succeeded. Am sorry but I don't think it is correct to say to IGNORE the sniffer data.

Unless there is a change made on FF end, there couldn't be a difference in behavior.
I am not sure why the point of comparison of FF 52 with 51 was not taken.

Even with FF 46, there was a change with "select" option which made our server behave wrongly -
https://www.fxsitecompat.com/en-CA/docs/2016/select-value-is-now-properly-updated-when-non-existent-option-is-programmatically-selected/

Bugzilla - https://bugzilla.mozilla.org/show_bug.cgi?id=1203668

I understand it is completely out of context, but just putting forth my point of "change in SSL implementation" in FF 52 which is breaking our TLS1.2 implementation and the only suspect is TLS1.3 of all other fixes addressed FF 52.

Seeking an advise on how to address this!
We may not be able to suggest our end users to tweak the TLS configuration in their browsers - kindly advise.
(In reply to Theophilus from comment #24)
> If the record layer format hadn't changed between SSL3 and TLS1.0, then for
> min=1 and max=1 shouldn't have succeeded. Am sorry but I don't think it is
> correct to say to IGNORE the sniffer data.

I'm not saying there is no problem, all I was saying is that we maybe shouldn't focus on the record version too much. There surely must be some other change that breaks TLS 1.2+ with your server - it might be a curve or a signature algorithm we're sending in 52 that we didn't send in 51. I don't understand though why your server simply aborts the connection instead of sending anything, not even an alert.
I assume those where all captures with 52? Did someone compare what 51 sends instead?
Here's a diff with 51 on the left and 52 on the right. A ClientHello with min=3/max=3:

https://www.diffchecker.com/sfcCJKCJ
Meantime, I modified the range on our server to use 1.0 and 1.1. I don't see any issues.
So that leaves to the point, as Kurt and Tim mentioned - something to do with TLSv1.2.

And the reason probably why the server closes the connection is due to security policies, we have disabled SSL3 on our servers or at least the server is unable to read the SSL record layer which actually is TLS1.0 as per our discussion here.
The most obvious change that could break things seems to be dropping SHA1 as Signature Hash Algorithm.
I'm confused, and it at least seems to be reordered.
So I think all DSA support got dropped, but there wasn't a DSA cipher to begin with. Which would leave the SCT extension that got added.
Is your server built on NSS. If so, the problem is probably this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1317857
To recap with more detail. The only thing that matters here is the bytes of the handshake. Ignore Wireshark's interpretation. TLS has two version numbers:

- The record version number (bytes 2 and 3)
- The ClientHello.version (assuming I am counting correctly, bytes 10 and 11).

As Kurt and Tim both point out, the record version number is always the bytes 03 01, which is correct per the specification, which is totally clear on this point. Moreover, it's not changing, so it's unlikely to be your problem.

The ClientHello.version depends on how Firefox has been configured, but seems to be behaving correctly as well. The most likely source of the problem is, as Kurt says, one of the extensions that we are offering, because otherwise it probably wouldn't work when you disable TLS 1.2. The prime candidate is signature algorithms, which we know is parsed improperly in some old servers. In any case, Firefox seems to be generating a correct ClientHello, so the problem is presumptively on your end. I advice you to check for bug 1317857, as noted in comment 32. Failing that, please find your server logs which should be reporting what they don't like about our ClientHello and then tell us what they say.
Thanks for the quick turn around!
> Our server is deployed with Tomcat 6 and JRE 1.7 running on RHEL 6. We are
> using NSS(nss-3.16.1-4.el6_5.x86_64) and JSS for the SSL implementation.

So we may have to upgrade to NSS 3.17 at least? Or will Mozilla be considering to support earlier algorithms?
Further, in the bug pointed, they had mentioned that this change to have introduced in FF 50. So, why issue with 52? - Kindly correct me if I had wronged in my understanding.
The server isn't logging any info as the request is not even reaching tomcat I believe.
(In reply to Theophilus from comment #34)
> So we may have to upgrade to NSS 3.17 at least? Or will Mozilla be
> considering to support earlier algorithms?

Yes, upgrading to 3.17.4 or higher is definitely the safest option. There are very few incompatible servers left and yours is unfortunately one of them. We can't take this back so late in the 52 cycle with a breakage that low I'm afraid.

> Further, in the bug pointed, they had mentioned that this change to have
> introduced in FF 50. So, why issue with 52? - Kindly correct me if I had
> wronged in my understanding.

I'm not exactly sure what Martin is referring to. Bug 1195434 definitely landed in 52 and reordered the signature algorithms so that we expose this old bug in NSS 3.16.
> Yes, upgrading to 3.17.4 or higher is definitely the safest option.

Thanq for the details. Any pointers from where we can take the NSS rpms?
That'd depend on what system you're using. There are CentOS and Fedora official rpms linked from RPMFinder [1], or you might want to contact your OS vendor. The NSS project itself doesn't ship RPMs I'm afraid.

[1] https://rpmfind.net/linux/rpm2html/search.php?query=nss
Flags: needinfo?(jjones)
FWIW, unless you have very specialized requirements (like specialized elliptic curves), you should find that you can use very recent NSS versions with no problems.  We take great care to ensure compatibility between releases.  NSS 3.28 is pretty mature now and will be in the next RHEL release.  A secondary benefit will be that you get fewer bugs and access to all of the new cipher suites, which can be a lot faster.
I'll mark this as a duplicate of bug 1317857 for proper tracking. Thank you Theophilus for reporting this to us and being so responsive.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(hartman1205)
Resolution: --- → DUPLICATE
Hello Experts!
We upgraded the NSS libraries to 3.21 and everything is smooth now!
Thanks for all your interest and collaboration in helping us arrive at a resolution and make our end customers happy!!
Special thanks to Eric who initially took efforts to explain the behavior and delegating the queries to the concerned and Tim/Kurt who ended breaking our barrier!

As a feedback- it would be better to notify/document on such changes. Not sure if ReleaseNote can have this info or at least the bug info! (sorry if I had missed to take a deeper look into the bug enclosures)

Thanks!
Flags: needinfo?(mwobensmith)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: