On Nov 24, 6:28 pm, Nelson Bolyard <nonelsons...@nobolyardspam.me>
wrote:
> On 2010-11-24 09:32 PDT, passfree wrote:
>
> > Hi there,
>
> > I am developing a generic SSL pipe XPCOM component which can be used
> > on any Input/Output stream pair. So far it sort of works but I am
> > facing one problem and I am not sure how to deal with it. The problem
> > arrises when a client connects to a server but refuses to continue
> > because of certificate errors. Lets say that we have an input stream
> > from a ServerSocket.
>
> You have a ServerSocket in Firefox? Firefox does not initialize the
> server components of libSSL, because it does not ever expect to behave
> as a server.
>
> > This input stream is wrapped with my SSL pipe
> > component. If the client connects but refuses to continue, due to the
> > SSL certificate is invalid for the current domain name, the code will
> > fail with a crash within ssl3con.c, ssl3_HandleAlert function, on the
> > following line:
>
> > if (level == alert_fatal) {
> > ss->sec.uncache(ss->sec.ci.sid);
>
> > The reason it fails is because ss->sec.uncache is set to null, 0, i.e.
> > nothing there to access.
>
> That's an uninitialized (or incompletely initialized) socket.
> Possibilities include:
> - You've closed the socket, then continued to use it
> - You initialized the socket as a client socket, then used it as a server
> socket without initializing the server components.
> - You initialized one PRSocket, then somehow switched to using another.
> - You added SSL to the socket after the socket was connected, but then
> didn't call SSL_ResetHandshake, or called it with the wrong argument values.
>
> > The question is why is this happening and what I should do to fix the
> > problem. Perhaps I need to init my ssl fd differently?
>
> There's something wrong with the way your code is using libSSL.
> Don't know what though. Could be any one of many things.
>
> > The obvious solution will be to add my own handler on that place but
> > then shouldn't that be handled by NSS? I haven't seen example code
> > which comes down to such hacks.
>
> Right, that would be a hack, and it wouldn't help you. You'd get a little
> farther before you'd run into the next problem due to the socket's
> uninitialized state.
>
> --
> /Nelson Bolyard
Wan-Teh, I hope I could link to libSSL within firefox/xulrunner
itself. Patching libSSL is certainly something I cannot do in this
particular case. Thanks for the advise, I will see if I can work
around this area.
Nelson, I am not using a real socket. I am creating a PRFileDesc layer
which acts like a socket. SSL_ImportFD works on the top of my layer.
The reason I am doing that is because at the end of the day I want to
work with streams, not sockets. The purpose of this component is to
enable client and server SSL on {nsIInput,nsIOutput}streams. Because
the component is generic enough you can essentially find many
different types of uses, including when you want to implement a new
protocol but start the SSL handshake at later stage. Firefox doesn't
expose such mechanisms through XPCOM.
I do not fully understand NSS but I am thinking that since my use is
fairly simplistic, I could avoid using the sec.cache and sec.uncache
functions. I understand that there is initialisation code which
typically can be applied globally, but since you mentioned that
firefox doesn't do that (it is not a server), I need to initialise
these pointers for each fake socket somehow without ending with a
monkeypatch.
Speaking of firefox, I know it is not meant to be used as a server but
it does provide server sockets through nsIServerSocket interface. So,
could these initialisation routines be included in future versions of
FF? If not, is it possible to detect somehow if they have been invoked
and if not, invoke them myself when the component loads?
I am happy to post my implementation. I will be very grateful to hear
what my options are.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
