On Wed, 5 Jun 2002, Thomas Lussnig wrote:
> And Try if openssl/gnutls handle it on used connection (i think yes, if no
> data readable for the moment).
You pass the socket descriptor to OpenSSL. It easy to do that the exact same
way, either after only a connect() or after a connect() with some CONNECT
stuff.
> Second make sure the proxy part do not become broken (don't know if there
> is the scenario SSL-PROXY connection and then SSL-HTTP request). Because
> this would mean that there become the need of an SSL [ SSL [ HTTP ] ]
> stream. And this is definitly much more tricky :-(
The CONNECT request is different from other proxy stuff and could possibly be
written in a separate function.
> >The proxy communication is not available as an RFC but that is the way SSL
> >tunneling thru a proxy works.
This is wrong. RFC2616 includes all details needed. The information was
available before too, in various (now deprecated) documents.
> > After the host is resolved and the proxy figures out that it is a secure
> > site it just acts as a router between the client and the destination
> > server. I need to figure out the starting point of that communication
> > (where the SSL handshake starts).
> If the PROXY -> SSL is not RFC-Normed there come the next question, how
> clients know how to work with it, is it product specific ?
It's standard all right. Proxys pass *everything* through after a CONNECT has
been requested and a positive reply has been returned back. What you send to
the proxy gets sent to the remote server, what you read was sent fromt the
remote server.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
