Re: ncat http proxy server and SSL

[Markus Klinik <markus.klinik () gmx de>]

On Fri, Feb 12, 2010 at 05:37:50PM -0700, David Fifield wrote:
> > As ncat_listen_stream already uses SSL, I'd like to reuse as much of
> > that code as possible. In particular, there is the function "ncat_recv"
> > which dispatches on whether SSL is compiled in and activated. It also
> > does this SSL_pending thing. It does delaying, telnet negotiation and
> > logging too.
> >
> > So, here is the plan:
> >
> > - replace socket_buffer.sd with an fdinfo
> > - make socket_buffer_readline use ncat_recv instead of recv
> > - make handle_connect and do_transaction use ncat_recv and ncat_send
> >   where appropriate
> > - put SSL init / deinit where appropriate
> > - finally, as telnet negotiation doesn't make much sense in proxy mode,
> >   forbid that combination in ncat_listen_mode
> >
> > What do you think, does that sound reasonable?
>
> That sounds reasonable. However, rather than forbidding Telnet
> negotiation at a high level, I would rather see another function
> factored out that does the SSL stuff without the other things that
> ncat_recv does.  (It still probably makes sense to prohibit Telnet
> with the HTTP proxy at a high level, but it should be enforced at a
> low level to ensure the correctness of the HTTP traffic.)
  
I don't understand that. One of the purposes of ncat_recv is to dispatch
between SSL and non-SSL. What is there that can be factored out? Also,
as ncat_recv is a low-level function, it is unaware of the protocol. We
could add a flag for ncat_recv to skip telnet stuff, and set that flag
whenever we call ncat_recv from within HTTP code. But as the program
options are some sort of global status anyway, just forbidding the
combination at program start is enough and keeps the low level
interfaces clean.

We could check in ncat_recv whether SSL and telnet are both enabled, but
is that really forbidden?

Well, here is a patch set which enables SSL support in http-proxy mode.

The CONNECT method works, tested with ssh and proxytunnel.  I couldn't
test whether the other methods (GET,PUT,HEAD) work because I didn't find
an http client that can connect to an SSL encrypted proxy.  Neither
firefox nor wget seem to support SSL encrypted proxies. Is there some
reason? Am I not getting why this might be undesirable or impossible?

As I changed the interface of socket_buffer, I needed to adapt an
unrelated part of the code, too (ncat_connect). I'm not particularly
happy with that because it never makes use of the SSL feature of fdinfo
(it just grabs the socket descriptor from fdinfo when proxy negotiation
is finished), but it works, tested with an http proxy. Couldn't get a
connection to any socks4 proxy, neither with or without my patch.

Markus

Attachment: 0001-ncat_recv-don-t-write-to-pending-if-it-is-NULL.patch
Description:

Attachment: 0002-util-add-fdinfo_init-and-fdinfo_close.patch
Description:

Attachment: 0003-socket_buffer-use-fdinfo-instead-of-plain-socket.patch
Description:

Attachment: 0004-ncat_proxy-SSL-support-for-http-CONNECT-method.patch
Description:

Attachment: 0005-ncat_proxy-SSL-support-for-http-GET-POST-HEAD-method.patch
Description:

Attachment: 0006-ncat_proxy-SSL-support-for-http-auth.patch
Description:

Attachment: 0007-ncat_connect-wrap-proxy-connection-in-fdinfo.patch
Description:

Attachment: 0008-ncat_main-forbid-proxy-server-mode-and-telnet.patch
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/