265080 - Https failure? Connection maintained even if dial-up connection broken - for some time.

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Felix Gudio]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

HTTPS Connection maintained even if dial-up connection broken.  User can enter
Https protected account, maintain browser open to any page, disconnect from dial
up access (such as to make a phone call), reconnect to dial up accesss and
continue on using that page - even when the Https implementation should have
caused a time-out or other security message to be presented.  Happens when
Accessing https://usbportal.usbank.com/mail/ which is an employee web mail
viewing page tied by Neoteris to Lotus Notes.  Site is is designed to use
Microsoft JVM but is viewable w/Firefox, etc.  Connection shows that it is 128
bit RC4 encrypted.  Concern is that Https is not functioning in a secure mode
with proper expirations.  May be related to site implementation (designed and
supported for use only with Internet Explorer 5.0+ and Microsoft JVM)  but
unknown at this time.  May be related to bug #225229.

Reproducible: Always
Steps to Reproduce:
1.log on to employee account at https://usbportal.usbank.com/mail/[username]
2.view a web mail page
3.break dial up connection and then reconnect - can continue using https page
but should be prompted to re-login.

Actual Results:  
Able to use https encrypted page - IE does not allow this but prompts to
re-login.  Opera 6 also does not permit access without a re-login.

Expected Results:  
Expired the connection and prompted for a new login.

Using Qute 2.1.3, AdSubtract 2.55, ZoneAlarm 5.1.033.000, Earthlink Task Panel
with Earthlink Accelerator and Java JRE build 1.4.2_05-b04.  Issue has been seen
also in Mozilla 1.7 when not using Earthlink's special connection software and
older JRE.

Comment 1

[Ben Bucksch (:BenB)]

I don't see the problem. You're still the same person and it's still the same
server. The way the internet connection goes is of no concern (that's the point
of HTTPS).

Invalidating any login/cookies when the IP address changes is the job of the server.

INVALID (and disclose) unless more information given.

Comment 2

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

You mention the site uses Java, is the log-in through Java? Java can do it's own
networking stuff and could be the issue. By default IE will use the MS JVM and
Firefox will use the Sun JVM. You can set IE to use Sun's JVM and see if you get
the same behavior. If you do then Java is the culprit, if IE still works the way
you want then we can let Java off the hook.

I assume we're not going to be able to test since we're not employees or
customers of usbank.com

It might be worth checking what the host is doing with http and cookie logging.

See:
http://www.mozilla.org/projects/netlib/cookies/cookie-log.html
http://www.mozilla.org/projects/netlib/http/http-debugging.html

You can do both in the same run, set
  NSPR_LOG_MODULES=nsHttp:5,cookie:4
(I suspect the socket transport and host resolver stuff will just be noise for
this bug so I left those off).

If you do make a log as described don't attach it here unless you carefully
scrub it for any passwords or personal information you don't want to share with
the world. Definitely rule out Java first.