cURL / Mailing Lists / curl-library / Single Mail


Re: problems connecting to HTTPS server

From: john lask <>
Date: Mon, 05 Nov 2001 09:44:57 +0000

Libcurl ssl/proxy problem
you will find attatched to this memo:
1. changes to files to allow curl to recognise --tlsv1 as an option
2. correction to ssl/proxy problem
3. new makefile for vc6 for libcurl

note that 1/2 code should be tested on linux before release. I have tested
on NT.

Cause of Problem
The cause of the reported problem is this:-

the proxy in question returns the following connection acknowledgement

HTTP/1.0 200 Connection established

Proxy-agent: Not-telling/5.0

now the last few characters of this message in hex are

* 2D 61 67 65 | 6E 74 3A 20 | 4E 6F 74 2D | 74 65 6C 6C [-agent: Not-tell]
* 69 6E 67 2F | 35 2E 30 0D | 0A 0D 0A 00 | [ing/5.0.....]

the error returned from ssl is as follows

>openssl:s3_pkt:ssl3_get_record:version 1603
>curl: (35) SSL: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
The first of the above lines generated from a prinf statement inserted into

The data packet recieved by open ssl was infact
Packet data[90]=
  16 03 01 00 55 01 00 00 51 03 01 3b dd 1e fb 7a ....

i.e. packet is correct

what is seen is that openssl is reading the version offset by one byte.
i.e. instead of reading starting after 16 (the type field) it reads from 16.
this is due to the 00 on the end of the connection acknowledge
- this is left in the buffer for openssl to read
- in Curl_ConnectHTTPProxyTunnel/GetLine we have

  while(GetLine(tunnelsocket, data->state.buffer, conn)) {
    if('\r' == data->state.buffer[0])
      break; /* end of headers */

so the loop reads from the buffer until a \r\n\r\n sequence is found,
anything after that is left in the buffer i.e. for 0D 0A 0D 0A 00 the 00 is

one could argue that this is correct, nethertheless other clients, namely
pavuk, etc
can cope with the above acknowledgement. This is because they do a block
read from the socket buffer, whereas the routine GetLine does a one
character at a time read.

In principle I believe that http-tunnel connect should leave the socket read
buffer clear when it exits. For this reason I have made change #2.

1. Change curl to accept tlsv1 as an option

    " -1/--tlsv1 Force usage of TLSv1 (H)\n"

    {"1", "tlsv1", FALSE},

    case '1':
      /* TLS version 1 */
      config->ssl_version = 1;

ssluse.c: Curl_SSLConnect

  case 1:
    req_method = TLSv1_client_method();

2. Change curl to not break when using openssl+proxy with a broken proxy

sendf.c - added function:

* Curl_readFlush
* --------------
* clear/flushes the input buffer
* reads the number of bytes in the filedescriptor (socket) buffer
* reads the buffer until the number of bytes read >= number of bytes

sendf.h - added definition:

CURLcode Curl_readFlush(struct connectdata *conn, int sockfd,
                   ssize_t *n);

setup.h - added
#define sioctl ioctlsocket

#define sioctl ioctl
the second definition has not been tested as it is unix specific!

http.c added:
  Curl_readFlush(conn, tunnelsocket, &nread);

3. New makefile for curlib

This new makefile makes a number of improvements on the old specifically a
lot more
options - it will do the following builds

sage: nmake -f makefile.vc6 CFG=<config> <target>
here <config> is one of:
elease - release static library
elease-dll - release dll
elease-ssl - release static library with ssl
elease-ssl-dll - release dll library with ssl
ebug - debug static library
ebug-dll - debug dll
ebug-ssl - debug static library with ssl
ebug-ssl-dll - debug dll library with ssl
target> can be left blank in which case all is assumed
akefile.vc6(159) : fatal error U1050: please choose a valid configuration ""

furthemore unlike the old makefile - it will only compile those files that
have changed
previouse makefile would recompile the whole lot every time!

Get your FREE download of MSN Explorer at

Received on 2001-11-05