TLS intolerant servers: tracking bug



17 years ago
8 years ago


(Reporter: Bob Lord, Assigned: Nelson Bolyard (seldom reads bugmail))


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




17 years ago
I'd like to use this bug report to track specific versions of SSL/TLS servers
which do not handle rollback detection correctly, and what the behavior of the
server is (e.g. does the server immediately close the connection, return an
error, appear to hang, etc.)

Comment 1

17 years ago
bryner reports that the web mail server he uses drops connections immediately
when TLS is turned on in PSM. He reports that the server is called WebMail
v3.6.1, by Infinite Technologies.


Comment 2

17 years ago
We have reports that the Java Web Server 2.0 is TLS intolerant. Don't know what
the symptoms are.

Comment 3

17 years ago
SW Texus U has reported problems in two different servers: (see bug 61785)

  + Webmail by Infinite Technologies (as reported above)
  + OSU/3.2 - DECthreads HTTP server for OpenVMS (by David Jones of Ohio State

Both seem to terminate the connection immediately (N6 simply does not display
the page).
Apparently there is an updated SSL module available from Infinite Technologies 
which fixes the TLS problems.  UIUC installed this and I've had no problems with 

Comment 5

17 years ago
This server is TLS intolerant:

You can see it in action by visiting the Delphion web site and trying to login:

Comment 6

17 years ago
A number of people have asked for more information about the TLS intolerance
bug, or have misunderstood the nature of the bug.  To that end, I've pulled
together some text from one of our SSL engineers to clear the air.

There are some number of web servers in production today which implement a
portion of the SSL 3.0 spec incorrectly.  This error causes
them to reject all connection attempts from clients that are compliant with the
SSL 3.0 _and_ TLS (aka SSL 3.1) specs.  This is the infamous "version rollback"
attack problem.

Since N6 *correctly* implements the TLS spec, N6 users cannot visit sites which
have this problem.

Here is some more detail:
The SSL 3.0 and TLS (aka SSL 3.1) specs both contain a provision (the same
provision) for detecting "version rollback attacks".  It is designed to permit a
server to detect a man-in-the-middle that is altering the SSL client hello
requests as they pass from the client to the server, altering them by changing
the protocol version number to a lower version number.  This feature was kind
of meaningless until TLS (SSL 3.1) came along because there was no version
higher than 3.0 from which to be rolled back.  Now, TLS is here, and products
that have implemented the roll-back detection incorrectly are not
interoperable with TLS/SSL spec-compliant clients.

Comment 7

17 years ago
Server: IBM_HTTP_Server/ Apache/1.3.7-dev (Unix)

Comment 8

17 years ago
Since this is not actually a defect in our software, I think this
bug should be resolved as invalid or wontfix.  Any objections?
OS: other → All
Hardware: PC → All
Target Milestone: --- → Future
Version: 3.2 → 3.0

Comment 9

17 years ago
The server is nelsonb's flavor A - 
"Just flat out cannot and do not negotiate an SSL3 session if the client asks 
for SSL 3.1, ever". is reporting the server as 
Netscape-Enterprise/3.6 SP3

Comment 10

17 years ago
An update from IBM on TLS compatibility in their servers:

In Nov 2000, I posted a message about a TLS handshake incompatibility between 
Netscape 6.0
and IBM HTTP Servers (IHS).  Netscape 6.0 was not handshaking with IHS because 
of a defect
in the IBM SSL libraries.  IBM has since fixed the problem in the latest 
revisions of the
IBM HTTP Server.

Here are the links to the current IBM HTTP Server versions:



The click path from is:  -> Downloads -> Web Application Servers -> More

Richard Cardona
Tivoli Systems, a division of IBM
Opinions expressed are solely mine and not an official statement by IBM.

Comment 11

17 years ago
Regarding the server 
which is running Netscape-Enterprise/3.6 SP3, we have determined
that the Enterprise server is not being used as an https server.
This is NOT an incompatibility between SSL in NES 3.6 SP3 and 

Rather, there is a system that sits between the Internet and that 
NES server.  That box is the SSL server.  It acts like one end of 
an SSL tunnel.  It takes the deciphered http request and sends it
on to the NES server as an ordinary http request, and when it 
receives the ordinary http response from the NES server, it passes
the response back to the browser via the SSL connection.  It is 
that system, not NES, that is incompatible with TLS clients.

Comment 12

17 years ago
Server (from Stronghold/2.2 Apache/1.2.5 FrontPage

See bug 58463 for details.

Comment 13

17 years ago
Server (from Stronghold/2.2 Apache/1.2.5

See for more details.

Comment 14

17 years ago
Is this something we can put in the release notes?

Comment 15

16 years ago
Lisa:  Look at my post from 12/2000.  There's some text there you might want to
reuse for the release notes.  It'll need polish.

The workaround for users is to turn off TLS in the Preferences panel (Privacy
and Security/SSL) and try to connect again.  (They should also complain to the
server administrator...)

Comment 16

16 years ago
Thank you.  I will forward this on.

Comment 17

16 years ago
Is there a way to make the default for TLS be off?  What would that do?   Just

Comment 18

16 years ago
Lisa, TLS is the new version of SSL.  As the most standards compliant browser,
we need to support new standards where they make sense, and TLS makes a great
deal of sense. We don't turn off JS by default just because some web sites don't
write clean JS code. :-)

Comment 19

16 years ago
To add 2 mroe servers/sites exhibiting the same porblems,

1.  (largest German Internet Banking site)

IBM_HTTP_Server/ Apache/1.3.7-dev (Unix) on AIX

2. (Deutsche Bank site)

IBM_HTTP_Server/ Apache/1.3.7-dev (Unix)

Comment 20

16 years ago
Clearly these sites using IBM servers aren't running the latest 
releases of IBM's product.  See the notes above in this bug 
report for the latest info.

Comment 21

16 years ago
I've got a proof of concept patch working in my tree that tries to connect again
if the server closes the connection down during the handshake.  It will need a
little massaging before it can be checked it, but this at least allows us to
leave TLS always on and support sites that incorrectly implement the latest
version of SSL.

Comment 22

16 years ago - Stronghold/2.2 Apache/1.2.5 C2NetUS/2004


16 years ago
Depends on: 84078

Comment 23

16 years ago
From comment in Bug 54031: WebLogic 5.1.0 Service Pack 9 04/06/2001
12:48:33 #105983 - 128 bit domestic version

Comment 24

16 years ago
Cisco PIX® Device Manager (part of Cisco PIX firewall 6.0) - build in server
Earlier this year, I was able to use online banking services at quite successfully with Beonex 0.6 and various nightly
builds in the Mozilla 0.8.* series (128-bit). However, the 0.9.1,2,3 series of
releases no longer work: I am able to negotiate the login, but I immediately get
a page that says my session has expired. No amount of fiddling with the TLS
option has any effect. is Netscape-Enterprise/3.6 SP3. Is this Netscape server also
intolerant, or is there something else at work here? (Maybe BMO just suddenly
decided to not support Mozilla...)

I'll be unable to communnicate on this matter until the end of August; if anyone
has suggestions/questions I will answer them then.

Comment 26

16 years ago
We do have a secure web server and  Netscape 6.0 + versions give a blank page 
when https://localhost:portno is given. Netscape had given the resolution that 
it was fixed in Netscape 6.1 where as it is not. I tried disabling the TLS 
option but the problem still persists.

Comment 27

16 years ago
Raveej: what servers are you running (brand and version number)?  Are any of
them accessable from outside your firewall?

Comment 28

16 years ago
Marking this bug "resolved, remind".
This bug report doesn't actually indicate any change to NSS or PSM is needed.
Rather it simply serves to remind us which servers are TLS intolerant.
Additional info about TLS intolerant servers can continue to be added even
though this bug is resolved.
Last Resolved: 16 years ago
Resolution: --- → REMIND
REMIND is deprecated per bug 35839.  There is a Tracking component in Browser
for bugs of this nature; should there be one for NSS as well?  Is this bug being
actively used?
Resolution: REMIND → ---


16 years ago
QA Contact: sonja.mirtitsch → bishakhabanerjee

Comment 30

16 years ago
This "bug" report does not report a bug in a Netscape product.
Rather it reports other vendors' server products that do not work well
with Netscape browsers due to bugs in those server products.
This bug report serves to remind us of those errant server products.

It is all well and good for the browser to have a policy that it will
no longer allow "remind" resolutions for browser bugs, but that is not 
the policy of NSS.
Last Resolved: 16 years ago16 years ago
Resolution: --- → REMIND

Comment 31

15 years ago
Resolution: REMIND → ---

Comment 32

15 years ago
Apparently, bugs with a resolution of "remind" get reopened whenever 
anyone adds any more comments to them.  Sigh.
So, I am marking this "WONTFIX".  The bug is actually "invalid",
since no erroneous behavior of our browser is being reported here.
Last Resolved: 16 years ago15 years ago
Resolution: --- → WONTFIX

Comment 33

15 years ago
The old 'Lotus-Domino' versions are TLS intolerant: see bug 168800 comment 8
(and 7).
Blocks: 168800

Comment 35

15 years ago
Verified per comment #32

Comment 36

8 years ago
Of the sites explicitly mentioned in this bug, only the one accessed by attempting to log in at appears to still be TLS-intolerant but otherwise working. The others either no longer exist, or have certs that don't match their domain name. So it seems as though it would be quite reasonable to treat TLS intolerance as another reason to show the big-scary-warning about there being something wrong with the security of the connection, and do the SSL3 fallback only when an exception has been registered for that site. That would have the effect of maintaining security against version rollback attacks, and now the renegotiation attack, for all sites that are not on the exceptions list.

Of course, this bug hasn't been updated since 2003, and only mentions a small number of sites. But that cuts both ways -- it's quite possible that there were only ever a small number of sites affected. The fallback policy is definitely in need of reassessment.

(Also see bug 454759.)
Update:  On 2009-12-11 14:09 PST, Wan-Teh Chang wrote to
> The following information was accurate as of yesterday, 2009-12-10.
> All information is public, coming from Google Chrome bug reports.
> I identify the servers by their behavior and by the Server headers
> in the HTTP responses.
> I tested the servers using Mac OS X 10.5 (TLS 1.0 without extensions)
> and Windows Vista (TLS 1.0 with extensions) and inspected the
> handshake messages.  I didn't test TLS 1.1 or 1.2.
> 1.
> "Server: IBM_HTTP_Server/ Apache/2.0.47 (Unix) DAV/2"
> Intolerant of TLS extensions.  Respond by closing the TCP connection
> without sending TLS alerts.
> Update: Today (2009-12-11) this server properly ignores TLS extensions
> and identifies itself as
> "Server: IBM_HTTP_Server/ Apache/2.0.47 (Unix) DAV/2"
> 2.
> Server unknown because SSL client auth is required.
> Intolerant of TLS extensions.  Respond with an illegal_parameter alert.
> 3.
> "Server: IBM_HTTP_Server"
> Intolerant of TLS extensions.  Respond by closing the TCP connection
> without sending TLS alerts.
> 4.
> "Server: OracleAS-Web-Cache-10g/"
> Intolerant of TLS.  Respond with an (SSL 3.0) unexpected_message alert.
> 5.
> "Server: Bab web server"
> Intolerant of TLS.  Respond with an (SSL 3.0) handshake_failure alert.
> 6. Oracle Application Server
> "Server: Oracle-Application-Server-10g/ Oracle-HTTP-Server"
> Intolerant of TLS extensions.  Respond with an illegal_parameter alert.
> 7.
> "Server: IBM_HTTP_Server"
> Intolerant of TLS extensions.  Respond by closing the TCP connection
> without sending TLS alerts.

Comment 38

8 years ago
Note that sites 1, 3 and 7 in the above report are the same Websphere SSL/TLS code base as the Lotus Domino servers that were previously known to be extension/TLS-intolerant. The fix is documented in IBM document reference #1245791
<> (this is a Google cache page; it seems to have disappeared from the IBM site recently).

The report has a modified date of 2006-09-14, i.e. it has been fixed (and backported to previous versions) for 3 years​.
I wish we had more info on that Oracle Application Server
"Server: Oracle-Application-Server-10g/ Oracle-HTTP-Server"

Is this a current version?  Or an old one?  a very old one?  
Are there lots of them in use?  
If so, can we find URLs for more of them?

Comment 40

8 years ago
The current version of OracleAS appears to be I don't know whether it is fixed.

mentions that OracleAS version is/was still extension-intolerant.

(note the version number, and the date August 2005), mentions
"support of the TLS protocol. TLS is the IETF standards version of SSLv3".
So if, as in example 4, a particular server running this code is TLS-intolerant, it cannot be because that version of the code base was SSLv3-only.
You need to log in before you can comment on or make changes to this bug.