Closed Bug 59321 Opened 24 years ago Closed 22 years ago

TLS intolerant servers: tracking bug

Categories

(NSS :: Libraries, defect, P3)

Product:
NSS
Component:
Libraries
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: lord, Assigned: nelson)

References

Details

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.)
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.


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


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
University)

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 
it.

This server is TLS intolerant:
Domino-Go-Webserver/4.6.2.6

You can see it in action by visiting the Delphion web site and trying to login:
http://www.delphion.com/

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.


Host: eg.dmv.ca.gov
Server: IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev (Unix)

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
The server https://synergy.professional.reutest.com/ 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".
http://www.netcraft.com/sslwhats is reporting the server as 
Netscape-Enterprise/3.6 SP3
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:

v1.3.6.4
http://www6.software.ibm.com/dl/ihs2/ihsv1364-p

v1.3.12.2
http://www6.software.ibm.com/dl/websphere/http-p

The click path from www.ibm.com is:
http://www.ibm.com/  -> Downloads -> Web Application Servers -> More

cheers,
Richard Cardona
Tivoli Systems, a division of IBM
Opinions expressed are solely mine and not an official statement by IBM.
Regarding the server https://synergy.professional.reutest.com/ 
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 
PSM.  

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.
Host: www.debik.com
Server (from netcraft.net): Stronghold/2.2 Apache/1.2.5 FrontPage

See bug 58463 for details.

Host: www.crazyeddieonline.com
Server (from netcraft.net): Stronghold/2.2 Apache/1.2.5

See http://bugscape.netscape.com/show_bug.cgi?id=4923 for more details.
Is this something we can put in the release notes?
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...)

Thank you.  I will forward this on.
Is there a way to make the default for TLS be off?  What would that do?   Just
wondering.
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. :-)



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

1. https://comhome.comdirect.de  (largest German Internet Banking site)

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

2. https://www.db-business-direct.com/ (Deutsche Bank site)

IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev (Unix)
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.
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.
https://www.gwla.com - Stronghold/2.2 Apache/1.2.5 C2NetUS/2004
Depends on: 84078
From comment in Bug 54031: WebLogic 5.1.0 Service Pack 9 04/06/2001
12:48:33 #105983 - 128 bit domestic version


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
https://www.bmo.com 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.

https://www.bmo.com 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.

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.
Raveej: what servers are you running (brand and version number)?  Are any of
them accessable from outside your firewall?

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.
Status: NEW → RESOLVED
Closed: 23 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?
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
QA Contact: sonja.mirtitsch → bishakhabanerjee
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → REMIND
https://webmail.wittenberg.edu/
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
The old 'Lotus-Domino' versions are TLS intolerant: see bug 168800 comment 8
(and 7).

Verified per comment #32
Status: RESOLVED → VERIFIED
Of the sites explicitly mentioned in this bug, only the one accessed by attempting to log in at http://www.delphion.com/ 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 tls@ietf.org:
> 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. https://militarybankonline.bankofamerica.com/efs/servlet/military/login.jsp
> "Server: IBM_HTTP_Server/6.0.2.15 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/6.0.2.33 Apache/2.0.47 (Unix) DAV/2"
> 
> 2. https://www.cdep.ro/
> Server unknown because SSL client auth is required.
> Intolerant of TLS extensions.  Respond with an illegal_parameter alert.
> 
> 3. https://welcome27.co-operativebank.co.uk/CBIBSWeb/start.do
> "Server: IBM_HTTP_Server"
> Intolerant of TLS extensions.  Respond by closing the TCP connection
> without sending TLS alerts.
> 
> 4. https://stud.infostud.uniroma1.it:4445/Sest/Log/Corpo.html
> "Server: OracleAS-Web-Cache-10g/10.1.2.0.2"
> Intolerant of TLS.  Respond with an (SSL 3.0) unexpected_message alert.
> 
> 5. https://www.bankalbilad.com.sa/retail/logon.do
> "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/10.1.2.0.2 Oracle-HTTP-Server"
> Intolerant of TLS extensions.  Respond with an illegal_parameter alert.
> 
> 7. https://www.sbbt.com/personal-home.php
> "Server: IBM_HTTP_Server"
> Intolerant of TLS extensions.  Respond by closing the TCP connection
> without sending TLS alerts.
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
<http://209.85.229.132/search?q=cache:p2rpDmdZS3gJ:www.ibm.com/support/docview.wss%3Frs%3D180%26uid%3Dswg21245791> (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/10.1.2.0.2 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?
The current version of OracleAS appears to be 10.1.3.5.2. I don't know whether it is fixed.

<http://www.mail-archive.com/curl-library@cool.haxx.se/msg02848.html>
mentions that OracleAS version 10.1.3.1.0 is/was still extension-intolerant.

<http://www.oracle.com/technology/products/ias/ohs/htdocs/ohs-10.1.2.0.2-fov_0.pdf>
(note the version number 10.1.2.0.2, 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.