On Wed, 06 Dec 2000, owner-curl_at_contactor.se wrote:
> ...
> > Is there a way to ask (lib)curl to send a Client Hello + session_id
> > previously emitted by the Web server, in order to lighten the SSL
> > protocol overhead in subsequent calls (I understand this is what a
> > browser does)?
>
> Browsers do work like that, yes.
>
> > In the answer is no, may I suggest this capability being scheduled for a
> > future release?
>
> The problem here is that the easy interface in libcurl does not permit
> several files being transfered using the same connection. Thus, this is not
> only an issue of implementing persistant connection support but also
> introducing a good way for the client to pass the request to the library
> etc.
>
> Of course I'm all ears if anyone has any suggestion on how to add this.
> ...

According to the SSL 3.0 Specification at
http://home.netscape.com/eng/ssl3/3-SPEC.HTM#7-1 :

"... The client hello message includes a variable length session identifier.
If not empty, the value identifies a session between the same client and
server whose security parameters the client wishes to reuse. The session
identifier may be from an earlier connection, this connection, or another
currently active connection. The second option is useful if the client only
wishes to update the random structures and derived values of a connection,
while the third option makes it possible to establish several simultaneous
independent secure connections without repeating the full handshake protocol.
The actual contents of the SessionID are defined by the server. ..."

In my understanding, this implies a persistent connection isn't needed to take
advantage of the session-id to significantly shorten the handshake protocol.
Libcurl could simply keep track of the last session-id received from the server
(on a per-thread basis, if needed) and provide an interface so that the calling
program (thread) can read its value. On subsequent calls, the calling program
could tell libcurl via a new curl_easy_setopt() option the session-id to try and
reuse, in which case the library would simply skip the handshaking part of the
SSL protocol according to the above specs (web server permitting).
When the original request implies multiple interactions with the (same) web
server, libcurl could default to re-using the first session-id returned, while
keeping the current behaviour if the multiple requests address different web
servers.
I hope not to be oversimplifying here, I am still relatively new to
Linux but I know from previous experience this kind of logic can easily be
programmed e.g. under OS/2.

Massimo
Received on 2000-12-06