full-disclosure - abnormal behavior Gmail logon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <42B56C6A683EBA4581C01CB49A914CA708AD2440@MAILFAXSRV.gfimalta.com>
Date: Wed May 31 15:05:30 2006
From: davidfa at gfi.com (David Farinic)
Subject: abnormal behavior Gmail logon

>Servers are supposed to send RST packets when they do that, but not all
>servers do it, and not all clients recognize those RST packets as
>indicating that the document they just downloaded is incomplete

Most of the clients do recognize and most web servers do correctly apply
use of RST and FIN for TCP/IP HTTP connection ending.

Problem is that some (most?)Proxy servers (nontransparent and probably
also transparent)  DO NOT. 

I tested 4 different proxy servers if they pass RST to client's browser
when original web server sent RST. All sent FIN instead of RST :(. (I
Did this test as I found other web apps. problems resulting from this
proxy behavior)

If anybody knows proxy which behaves 'correctly,' pls let me know.

Regards David Farinic 

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Brian
Eaton
Sent: Wednesday, May 31, 2006 2:25 PM
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk; Edward Pearson
Subject: Re: [Full-disclosure] abnormal behavior Gmail logon

On 5/31/06, Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
> On Wed, 31 May 2006 09:23:08 BST, Edward Pearson said:
> > This isn't abnormal or weird, It happens when your internet
connection
> > is fairly slow and its because you sometimes receive incomplete
headers
> > for the page (broken or garbled)
>
> If you have noisy hardware that's mangling data in transit, the
mangling will
> *usually* be detected by the checksums on each IP packet.  The reason
your
> connection gets slow is because if a corruption is detected, the
packet gets
> thrown out, and needs to be retransmitted by the sending system.

It is actually possible that the data sent in the HTTP connection is
getting mangled even though the TCP checksums are correct.  In one
mode of operation, HTTP allows a server to indicate when a document is
complete simply by closing a TCP connection.  If the server gets busy,
it might decide your client is just too slow to be worth dealing with
and close the connection early.  Servers are supposed to send RST
packets when they do that, but not all servers do it, and not all
clients recognize those RST packets as indicating that the document
they just downloaded is incomplete.

Regards,
Brian

This mail was checked for viruses by GFI MailSecurity. 
GFI also develops anti-spam software (GFI MailEssentials), a fax server (GFI FAXmaker), and network security and management software (GFI LANguard) - www.gfi.com