Last Comment Bug 59321 - TLS intolerant servers: tracking bug
: TLS intolerant servers: tracking bug
Status: VERIFIED WONTFIX
:
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.0
: All All
: P3 normal with 1 vote (vote)
: Future
Assigned To: Nelson Bolyard (seldom reads bugmail)
: Bishakha Banerjee
Mentors:
Depends on: 84078
Blocks: 168800
  Show dependency treegraph
 
Reported: 2000-11-06 18:54 PST by Bob Lord
Modified: 2009-12-15 20:56 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Bob Lord 2000-11-06 18:54:08 PST
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 Bob Lord 2000-11-06 18:57:56 PST
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 Bob Lord 2000-11-06 19:35:19 PST
We have reports that the Java Web Server 2.0 is TLS intolerant. Don't know what
the symptoms are.

Comment 3 Terry Hayes 2000-12-03 10:17:20 PST
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).
Comment 4 Brian Ryner (not reading) 2000-12-03 11:59:07 PST
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.
Comment 5 Bob Lord 2000-12-18 08:55:03 PST
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/
Comment 6 Bob Lord 2000-12-21 08:43:32 PST
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 Terry Hayes 2001-01-09 10:41:36 PST
Host: eg.dmv.ca.gov
Server: IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev (Unix)
Comment 8 Nelson Bolyard (seldom reads bugmail) 2001-01-12 14:36:46 PST
Since this is not actually a defect in our software, I think this
bug should be resolved as invalid or wontfix.  Any objections?
Comment 9 John Unruh 2001-01-25 08:24:32 PST
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
Comment 10 Terry Hayes 2001-02-08 15:07:51 PST
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.
Comment 11 Nelson Bolyard (seldom reads bugmail) 2001-02-23 13:05:37 PST
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.
Comment 12 Terry Hayes 2001-04-18 22:37:29 PDT
Host: www.debik.com
Server (from netcraft.net): Stronghold/2.2 Apache/1.2.5 FrontPage

See bug 58463 for details.
Comment 13 David P. Drinan 2001-05-21 18:16:40 PDT
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.
Comment 14 lchiang 2001-05-29 14:16:53 PDT
Is this something we can put in the release notes?
Comment 15 Bob Lord 2001-05-31 09:49:49 PDT
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 lchiang 2001-05-31 11:28:09 PDT
Thank you.  I will forward this on.
Comment 17 lchiang 2001-05-31 11:32:47 PDT
Is there a way to make the default for TLS be off?  What would that do?   Just
wondering.
Comment 18 Bob Lord 2001-05-31 11:58:06 PDT
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 Katsuhiko Momoi 2001-05-31 15:44:03 PDT
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)
Comment 20 Nelson Bolyard (seldom reads bugmail) 2001-06-01 12:08:06 PDT
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 Javier Delgadillo 2001-06-01 20:29:15 PDT
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 John Unruh 2001-06-04 09:10:37 PDT
https://www.gwla.com - Stronghold/2.2 Apache/1.2.5 C2NetUS/2004
Comment 23 Bob Clary [:bc:] 2001-07-11 11:40:01 PDT
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 Mirek Hankus 2001-08-03 00:18:02 PDT
Cisco PIX® Device Manager (part of Cisco PIX firewall 6.0) - build in server
Comment 25 Michel Joly de Lotbiniere 2001-08-03 20:42:19 PDT
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.
Comment 26 Rajeev Sharma 2001-08-24 15:18:51 PDT
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 Bob Lord 2001-08-25 23:27:50 PDT
Raveej: what servers are you running (brand and version number)?  Are any of
them accessable from outside your firewall?
Comment 28 Nelson Bolyard (seldom reads bugmail) 2001-08-30 20:24:37 PDT
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.
Comment 29 Christopher Hoess (gone) 2002-04-29 13:00:31 PDT
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?
Comment 30 Nelson Bolyard (seldom reads bugmail) 2002-04-29 13:40:36 PDT
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.
Comment 31 John Unruh 2002-06-25 08:30:20 PDT
https://webmail.wittenberg.edu/
Comment 32 Nelson Bolyard (seldom reads bugmail) 2002-06-25 13:09:18 PDT
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.
Comment 33 John Unruh 2002-09-20 08:59:48 PDT
https://www.bokkilden.no
Comment 34 Serge Gautherie (:sgautherie) 2003-01-07 20:06:47 PST
The old 'Lotus-Domino' versions are TLS intolerant: see bug 168800 comment 8
(and 7).
Comment 35 John Unruh 2003-02-05 14:49:19 PST
Verified per comment #32
Comment 36 Daira Hopwood 2009-11-12 21:39:29 PST
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.)
Comment 37 Nelson Bolyard (seldom reads bugmail) 2009-12-15 09:47:43 PST
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.
Comment 38 Daira Hopwood 2009-12-15 11:46:48 PST
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​.
Comment 39 Nelson Bolyard (seldom reads bugmail) 2009-12-15 18:52:34 PST
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?
Comment 40 Daira Hopwood 2009-12-15 20:56:55 PST
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.

Note You need to log in before you can comment on or make changes to this bug.