Closed Bug 387565 Opened 17 years ago Closed 17 years ago

Cannot login to secure site of embedded device

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dbotez, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12

I'm working with an embedded product that uses a secure web interface for configuration/monitoring purposes. 
After updating Firefox from 1.5.0.12 to 2.0.0 and beyond (or after using any of the most recent Mozilla based 
browsers - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2) I can 
no longer login to secure web interface. I am sure that there is no firewall problem to block the browser from 
connecting to the web site. 
I innitially posted a report on the FF support forum and tried what was suggested but without success. SSL2 and SSL3 are enabled.
FF1.5.0.12, IE6 and IE7 work without problems with this device.

I tested with Firefox 2.0.4 for Linux (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4) and 
SeaMonkey 1.1.2 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509]. The behaviour is different in FF 
and SeaMonkey but the end result is the same: cannot login to the site.

In order to login to the web interface of the device the device has to be directly connected to the PC via an Ethernet cable, 
then in the addrees bar I enter the IP adddrees of the device, the device responds sending a page with a for asking user name 
and password which are then sent to teh device via a POST and if valid the device would respond with its main configuartion page.

To create the but I just need to atempt a login to the device.


In FF2.0.4 for Linux I get the following behavior: 
1. start FF 2.0.4
2. clear private data ( all cookies, cache, etc )
3. enter IP adddress of device in the address bar
4. device returns a login page
5. enter user name and password and submit the form
6. device returns again the login page
7. enter again the user name and password and submit the form
8. the browser returns the following error page:
-----------------------------------------------------------------

The connection was reset


The connection to the server was reset while the page was loading.


* The site could be temporarily unavailable or too busy. Try again in a few moments.


* If you are unable to load any pages, check your computer's network connection.


* If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.

Try Again

-----------------------------------------------------------------

9. Then if I wait about 2 minutes or sometimes less and click on Try Again the login is successful.

Using the SeaMonkey 1.1.2 browser in Windows I get a different behavior:
1. start SeaMonkey 1.1.2
2. clear cookies, cache, etc 
3. enter IP adddress of device in the address bar
4. device returns a login page
5. enter user name and password and submit the form
6. device returns again the login page
7. enter again the user name and password and submit the form
8. the browser returns the following error page:

-----------------------------------------------------------------

Connection Interrupted

The document contains no data.

The network link was interrupted while negotiating a connection. Please try again.

Try Again
-----------------------------------------------------------------


In this case no matter how much I wait if I try again the login will not work.

For both browsers I tried to use the about:config to view an modify the parameters that differ from the previous versions that were working with this secure web interface but the new parameters din not make any difference.


Below is a trace from Live HTTP Headers that shows what is happening when login fails in FF 2.0.4 (my comments prefixed with Doru-->) and then when succeeds in FF 1.5.0.12:

Doru--> in order to login enter the IP address of the device in FF address bar

http://192.168.254.236/

GET / HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
----------------------------------------------------------
Doru --> the user is redirected to a secure page

https://192.168.254.236/

GET / HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 Ok
Date: Mon, 09 Jul:58:02 GMT
Expires: Thu, 01 Jan:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 3693
Last-Modified: Mon, 09 Jul:58:02 GMT
Connection: close
----------------------------------------------------------
Doru --> user enters login name and password and FF POSTs them to the device

https://192.168.254.236/

POST / HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://192.168.254.236/
Content-Type: application/x-www-form-urlencoded
Content-Length: 59
username=Admin&password=admin&banner=1&submitbutton=Sign+In

Doru --> the 401 Unauthorized is generated because at this moment the user does not have a right sessionid but has a valid username/password. The HTTP server creates a session id for teh user and sends a cookie and in the header adds the 401 Unauthorized.

HTTP/1.x 401 Unauthorized
Date: Mon, 09 Jul:58:29 GMT
Set-Cookie: SESSIONID=05EA47A4EBD056C49580A118C7CAC7A99EA59A34; path=/;
Expires: Thu, 01 Jan:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 83
Last-Modified: Mon, 09 Jul:58:29 GMT
Connection: close
----------------------------------------------------------
https://192.168.254.236/

GET / HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: SESSIONID=05EA47A4EBD056C49580A118C7CAC7A99EA59A34
If-Modified-Since: Mon, 09 Jul:58:02 GMT
Cache-Control: max-age=0

Doru --> The 304 Not Modified is generated by the HTTP server due to the If-Modified-Since not being -1 or if greater then the file's time of last modification an din this case the file was last modified years ago and teh web server return without processing the index.html file that does a redirection to the CGI entry point.

HTTP/1.x 304 Not Modified
Date: Mon, 09 Jul:58:31 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 59
Last-Modified: Fri, 19 Jul:34:02 GMT
Connection: close


Doru--> After this point if I click on the Try Again button the login will succeed.

The correct login sequence is shown below as captured with Firefox 1.5.0.12

http://192.168.254.236/

GET / HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
----------------------------------------------------------
Doru --> browser requests the favicon.ico file --> this is not done in FF2.0.4

http://192.168.254.236/favicon.ico

GET /favicon.ico HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Accept: image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
----------------------------------------------------------
Doru --> the user is redirected to a secure page

https://192.168.254.236/

GET / HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 Ok
Date: Mon, 09 Jul:49:46 GMT
Expires: Thu, 01 Jan:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 3693
Last-Modified: Mon, 09 Jul:49:46 GMT
Connection: close
----------------------------------------------------------
Doru --> browser requests again the favicon.ico file --> this is not done in FF2.0.4

https://192.168.254.236/favicon.ico

GET /favicon.ico HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Accept: image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 Ok
Date: Mon, 09 Jul:49:47 GMT
Expires: Thu, 01 Jan:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 3693
Last-Modified: Mon, 09 Jul:49:47 GMT
Connection: close
----------------------------------------------------------
Doru --> user enters login name and password and FF POSTs them to the device

https://192.168.254.236/

POST / HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://192.168.254.236/
Content-Type: application/x-www-form-urlencoded
Content-Length: 59
username=Admin&password=admin&banner=1&submitbutton=Sign+In

Doru --> As for FF 2.0.4 the 401 Unauthorized is generated because at this moment the user does not have a right sessionid but has a valid username/password. The HTTP server creates a session id for teh user and sends a cookie and in the header adds the 401 Unauthorized.

HTTP/1.x 401 Unauthorized
Date: Mon, 09 Jul:49:51 GMT
Set-Cookie: SESSIONID=20D03CF7F0201F3776BCF18D53E42056231539FF; path=/;
Expires: Thu, 01 Jan:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 83
Last-Modified: Mon, 09 Jul:49:51 GMT
Connection: close
----------------------------------------------------------
https://192.168.254.236/

GET / HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: SESSIONID=20D03CF7F0201F3776BCF18D53E42056231539FF
Pragma: no-cache
Cache-Control: no-cache

Doru --> A new session was created and the index.html file is automatically read and sent to the browser.
The If-Modified-Since: Mon, 09 Jul 2007 ... is no longer present in this case and so the GET is succesful.

HTTP/1.x 200 Ok
Date: Mon, 09 Jul:49:51 GMT
Expires: Thu, 01 Jan:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html; charset=iso-8859-1
Content-Length: 59
Last-Modified: Fri, 19 Jul:34:02 GMT
Connection: close
----------------------------------------------------------
Doru --> Browser is redirected to the CGI entry point.

https://192.168.254.236/cgi-bin/sgateway

GET /cgi-bin/sgateway HTTP/1.1
Host: 192.168.254.236
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: SESSIONID=20D03CF7F0201F3776BCF18D53E42056231539FF

HTTP/1.x 200 OK

From this moment on the browser reads all the HTML code and files used by the home page of the device.





Reproducible: Always

Steps to Reproduce:
1.
2.
3.



I cannot offer an URL at the moment that points to this device but eventually this can be arranged. I can provide full LiveHTTP Headers and Ethereal captures of the sessions plus the internal syslog of the device.
In the end the problem was with the HTTP server of the device that I was using, the cookie expiry date sent by the HTTP server was set in the past (Jan 1, 1970) not in the future, with this fix both Firefox 2.0.4 and SeaMonkey 1.1.2 work fine.

Thanks a lot for all your help,
Doru
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.