1688614 - Improve SSL_ERROR_INTERNAL_ERROR_ALERT

Status: NEW

(Firefox :: Security, enhancement, P5)

Description

[Emilio Cobos Álvarez [:emilio]]

So, I have a page (https://nogal.usal.es, though the homepage doesn't seem to display this error).

Semi-randomly, some scripts, or the page itself, fails to load. I dug a bit and it seems we're getting SSL_ERROR_INTERNAL_ERROR_ALERT somewhat intermittently.

In Chrome this seems to always work.

Digging a bit more we're hitting this line:

https://searchfox.org/mozilla-central/rev/4dac9993b609fccc87e82682614faf2a44cda306/security/nss/lib/ssl/ssl3con.c#3085

With this stack:

#15 0x00007f0c26363be9 in ssl3_HandleAlert (ss=0x7f0be6d5c000, buf=<optimized out>) at /home/emilio/src/moz/gecko-3/security/nss/lib/ssl/ssl3con.c:3085
#16 ssl3_HandleNonApplicationData (ss=ss@entry=0x7f0be6d5c000, rType=<optimized out>, epoch=<optimized out>, seqNum=<optimized out>, databuf=<optimized out>) at /home/emilio/src/moz/gecko-3/security/nss/lib/ssl/ssl3con.c:13087
#17 0x00007f0c263645fd in ssl3_HandleRecord (ss=ss@entry=0x7f0be6d5c000, cText=cText@entry=0x7f0c05db1560) at /home/emilio/src/moz/gecko-3/security/nss/lib/ssl/ssl3con.c:13388
#18 0x00007f0c2636ee5b in ssl3_GatherCompleteHandshake (ss=ss@entry=0x7f0be6d5c000, flags=<optimized out>, flags@entry=0) at /home/emilio/src/moz/gecko-3/security/nss/lib/ssl/ssl3gthr.c:523
#19 0x00007f0c26376d1e in SSL_ForceHandshake (fd=0x7f0be8c4d2e0) at /home/emilio/src/moz/gecko-3/security/nss/lib/ssl/sslsecur.c:381
#20 0x00007f0c205523da in nsNSSSocketInfo::DriveHandshake() (this=0x7f0be8cd3c00) at /home/emilio/src/moz/gecko-3/security/manager/ssl/nsNSSIOLayer.cpp:320
#21 0x00007f0c1c665925 in mozilla::net::nsHttpConnection::EnsureNPNComplete(nsresult&, unsigned int&) (this=this@entry=0x7f0be8cda000, aOut0RTTWriteHandshakeValue=@0x7f0c05db176c: nsresult::NS_OK, aOut0RTTBytesWritten=@0x7f0c05db1768: 0)
    at /home/emilio/src/moz/gecko-3/netwerk/protocol/http/nsHttpConnection.cpp:544
#22 0x00007f0c1c6666d6 in mozilla::net::nsHttpConnection::OnSocketWritable() (this=this@entry=0x7f0be8cda000) at /home/emilio/src/moz/gecko-3/netwerk/protocol/http/nsHttpConnection.cpp:1953
#23 0x00007f0c1c667c3f in mozilla::net::nsHttpConnection::OnOutputStreamReady(nsIAsyncOutputStream*) (this=0x7f0be8cda000, out=0x7f0be8cd22d0) at /home/emilio/src/moz/gecko-3/netwerk/protocol/http/nsHttpConnection.cpp:2503
#24 0x00007f0c1c66b37c in non-virtual thunk to mozilla::net::nsHttpConnection::OnOutputStreamReady(nsIAsyncOutputStream*) () at /home/emilio/src/moz/gecko-3/netwerk/protocol/http/nsHttpConnectionMgr.cpp:606
#25 0x00007f0c1c25fa9b in mozilla::net::nsSocketOutputStream::OnSocketReady(nsresult) (this=this@entry=0x7f0be8cd22d0, condition=condition@entry=nsresult::NS_OK) at /home/emilio/src/moz/gecko-3/netwerk/base/nsSocketTransport2.cpp:520
#26 0x00007f0c1c264911 in mozilla::net::nsSocketTransport::OnSocketReady(PRFileDesc*, short) (this=0x7f0be8cd2000, fd=0x7f0be8c4d2e0, outFlags=2) at /home/emilio/src/moz/gecko-3/netwerk/base/nsSocketTransport2.cpp:2305
#27 0x00007f0c1c26b141 in mozilla::net::nsSocketTransportService::DoPollIteration(mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>*) (this=<optimized out>, this@entry=0x7f0c06cbd680, pollDuration=0x7f0c00000001, 
    pollDuration@entry=0x7f0c05db1928) at /home/emilio/src/moz/gecko-3/netwerk/base/nsSocketTransportService2.cpp:1393

Dragana mentioned that this might be a necko or nss issue.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Attachment: Security info, just in case it's relevant.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

One thing I notice is that we seem to send more requests in parallel than Chrome on this page. Maybe the server is barfing on us because of it... Is there any way to reduce the necko parallelism?

Comment 3

[Kershaw Chang [:kershaw]]

Dana, do you probably have an idea about this? Or maybe I should ask someone in NSS team?
Thanks.

Comment 4

[Dana Keeler (she/her) [:keeler]]

I believe that's the code that handles peers sending the TLS alert "internal server error", so it seems like Firefox is triggering a bug in the server. Without more information on or access to the server, I imagine it'll be difficult to figure out from our end.

Comment 5

[Valentin Gosu [:valentin]]

Emilio, can you work with Dana to see why this is happening?
Also, what do the failures look like? It would be nice if a server error is presented as such.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: Error message.

When the error happens on the top level page I see something like this. But when stuff like subresources fail to load there's not an easy way to know what's broken (the error is something like "Failed to load module https://..." or what not).

I contacted the admin of the site. It's apparently some sort of hand-rolled Java-implemented web server, so I asked them whether I could somehow get a repro locally, or some logs of what might be different across browsers.

Comment 7

[Dana Keeler (she/her) [:keeler]]

If we want to change how that page looks, that would be a frontend issue.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

I got some info from the site admin, and this was https://bugs.openjdk.java.net/browse/JDK-8213202, looks like. They updated OpenJDK and I haven't been able to repro since, so this is unlikely to be a Firefox bug after all. Why it only happens with FF, I'm not sure, but being a race condition on the server side it seems the timing on which we fire the network requests could affect it.