httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Lewis <jle...@silverhawk.net>
Subject Re: debugging ssl packet drop
Date Fri, 17 Oct 2014 16:01:26 GMT
Your first message was delivered less than 24 hours ago - most of us are
not paid by the Apache modules developers list, meaning we are stricly
volunteer, and 24 hours might not be enough time.  I would suggest
patience, especially while asking questions on the fringes of this lists
expertise.  Most people here are module developers, not SSL debuggers or
TCP experts.  I actually thought your original e-mail should have gone to
an openssl mailing list instead of an Apache modules list.

I won't support tracking down something like network errors without access
and a consultation fee - it's an ugly rabbit hole that not many actually
want to go down, especially me.

I will simply suggest using Wireshark at multiple points (e.g. on the same
LAN as the client, and on the same LAN as the server) just to ensure that a
firewall, netscaler, or any other device between the client and the server
isn't your problem.  You claim an error code of 101 (network reset).  Are
you seeing TCP resets in your packet capture (remember, I'm not going to
support or help beyond this - the question is to get you to think about
what you are actually seeing in your packet capture).  Did you decrypt your
SSL-encrypted packet capture just to ensure you are seeing things
properly?  Are you sure you haven't custom-configured timeouts for Apache?
 ipfw/iptables/etc on the server (tcpdump of *nix will help)?

Remember, it sounds like you are asking for help for things on the fringes
of most people's expertise here.  Be patient.

Joe

On Fri, Oct 17, 2014 at 9:22 AM, Pon Umapathy Kailash S <
pon.umapathy@gmail.com> wrote:

> Resending since it doesn't seem to have been delivered.
>
> On Thu, Oct 16, 2014 at 11:26 AM, Pon Umapathy Kailash S
> <pon.umapathy@gmail.com> wrote:
> > Hi,
> >  I am facing the an issue where a SSL packet from IE10 doesn't reach
> > the client processing thread for a particular connection(more details
> > below).  Can you please provide me pointers on where to look/add more
> > debug logs in the code to figure out what's happening? We use mpm
> > worker threads.
> >
> > I have added support for websockets in a customised manner(as required
> > for our application) inside apache. At a high level, it's done as
> > follows:
> >
> > - the initial GET request with 101 code is handled by a handler hook
> > function which computes the required security keys and sends back the
> > response. Also, the socket on which the request came in is not
> > closed(by maintaining a list and patching some parts of the apache
> > code to not close if a socket is present in this list).
> >
> > - the child thread which processes this connection will relinquish the
> > connection after the keep-alive timeout , which is ok since all we
> > need is for the server to send messages to the client, with one
> > exception.
> >
> > - At this point, the socket is recognised as a websocket client which
> > is not yet authenticated(since from browsers we cannot set custom
> > headers with the initial websocket connection request).
> >
> > - Authentication is done by the client sending the cookie as the
> > 1st(and only) message on this connection to the server within the
> > keep-alive timeout period(at which point the cookie is authenticated
> > and the socket is marked as a valid, authenticated subscriber).
> > (* there are other functions/timers to take care of stale, unauth
> > connections etc)
> >
> > This works fine in all browsers with support for websockets with the
> > following exceptions:
> >
> > IE10 over ssl(https/wss) and IE11 over ssl on 32-bit client machines.
> >
> > Doing a packet capture, we could figure out that the initial
> > connection goes through fine and when the cookie is sent from the
> > client, it reaches the server(and there's a tcp ack received at the
> > client for this packet). However, the client processing this
> > connection doesn't seem to receive this packet(this is well within the
> > keep alive interval and the client thread is still actively processing
> > that connection).
> >
> > Can you please let me know at which points in the code flow it might
> > be useful to add debugging info to see where this is getting dropped?
> >
> > Regards,
> > Umapathy
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message