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 → 23 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: 23 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.